Use plugin-service MCP as the hosted plugin runtime

[jif-oai]

Stack

• Base: Route hosted Apps MCP through extensions #27191
• This PR is the third vertical and should be reviewed against jif/external-plugins-2, not main.

Why

#27191 moves the host-owned Apps MCP registration behind an extension contributor, but deliberately preserves the existing endpoint-selection feature while that contribution contract lands. App-server can therefore resolve the server through extensions, yet the hosted plugin endpoint is still selected through temporary apps_mcp_path_override plumbing.

That is not the long-term plugin model. A plugin can bundle skills, connectors, MCP servers, and hooks, and those components do not all need the same source or execution environment. In particular, an authenticated HTTP MCP server can expose plugin capabilities directly from a backend without an executor or an orchestrator filesystem.

This PR completes that hosted vertical. App-server's MCP extension now owns the aggregate hosted plugin runtime at /ps/mcp. Connector actions continue to arrive as MCP tools, while backend-provided skills arrive as MCP resources and use Codex's existing resource list/read paths. No second backend client, skill filesystem, or generic plugin activation framework is introduced.

The backend route remains the hosted implementation. This change replaces Codex's temporary endpoint-selection mechanism, not the service behind the endpoint.

What changed

Hosted plugin runtime

The MCP extension now contributes codex_apps as the hosted plugin runtime rather than as a configurable Apps endpoint:

• https://chatgpt.com resolves to https://chatgpt.com/backend-api/ps/mcp;
• a bare custom ChatGPT base resolves to /api/codex/ps/mcp;
• the existing product-SKU header and ChatGPT authentication behavior are preserved;
• executor availability is never consulted for this streamable HTTP transport.

The same MCP connection carries both component shapes supported by the hosted endpoint:

• connector actions are discovered and invoked as MCP tools;
• hosted skills are enumerated and read as MCP resources through the existing list_mcp_resources and read_mcp_resource paths.

This keeps component access in the subsystem that already owns the protocol instead of downloading backend skills into an orchestrator filesystem or inventing a parallel hosted-skill client.

Explicit runtime ordering

McpManager now resolves the reserved codex_apps entry in three ordered phases:

1. install the legacy Apps fallback for compatibility;
2. apply ordered extension Set or Remove overlays;
3. apply the final ChatGPT-auth gate without synthesizing the server again.

This ordering is important:

• an ordinary configured or plugin MCP server cannot claim the auth-bearing codex_apps name;
• an extension-contributed hosted runtime wins over the fallback;
• an extension Remove remains authoritative;
• a host without the MCP extension retains the legacy Apps endpoint and current local-only behavior.

The temporary legacy_apps_mcp_loader_enabled coordination flag is no longer needed.

Remove the path override

The apps_mcp_path_override feature and its runtime plumbing are removed, including:

• the feature registry entry and structured feature config;
• Config and McpConfig fields;
• config schema output;
• config-lock materialization;
• URL override handling in codex-mcp.

Existing boolean and structured forms still deserialize as ignored compatibility input. They are omitted from new serialized config, and config-lock comparison normalizes the removed input so older locks remain replayable.

App-server coverage

App-server MCP fixtures now serve the hosted route at /api/codex/ps/mcp. Existing resource-read and tool/elicitation flows therefore exercise the extension-owned endpoint rather than succeeding through the legacy fallback.

The stack also adds the missing codex_chatgpt::connectors re-export for the manager-backed connector helper introduced in #27191.

Compatibility

• App-server installs the extension and uses /ps/mcp for the hosted runtime.
• CLI and other hosts that do not install the extension retain the legacy Apps endpoint.
• Apps disabled or non-ChatGPT authentication removes codex_apps from the effective runtime view.
• Existing local plugins, local skills, executor-selected skills, configured MCP servers, and MCP OAuth behavior are otherwise unchanged.
• Backend plugin enablement remains account/workspace state owned by the hosted endpoint; this PR does not add thread-local backend plugin selection.

Architectural fit

The stack now proves two independent runtime shapes:

1. Load selected executor skills through extensions #27184 resolves filesystem-backed skills through the executor that owns a selected root.
2. Route hosted Apps MCP through extensions #27191 and this PR resolve a backend-hosted HTTP MCP through an extension with no executor.

Together they preserve the intended separation:

• selection identifies a plugin/root when explicit selection is needed;
• each component's owning extension resolves its concrete access mechanism;
• execution stays with the runtime required by that component;
• existing skills, MCP, connector, and hook subsystems remain the downstream consumers.

Planned follow-ups

1. Executor stdio MCP: selecting an executor plugin registers a manifest-declared stdio MCP server and executes it in the environment that owns the plugin.
2. Optional backend selection: only if CCA needs thread-local selection distinct from backend account/workspace enablement, add a concrete backend-owned capability location and surface those selected skills through the skills catalog.
3. Connector metadata and hooks: activate those plugin components through their existing owning subsystems, with executor hooks remaining environment-bound.
4. Propagation and persistence: define explicit resume, fork, subagent, refresh, and environment-removal semantics once selected roots have multiple real consumers.
5. Local convergence: migrate legacy local skill, MCP, connector, and hook paths behind their owning extensions one vertical at a time, then remove duplicate core managers and compatibility plumbing after parity.

Verification

Coverage in this change exercises:

• extension-owned /backend-api/ps/mcp registration without an executor;
• preservation of the legacy endpoint in hosts without the extension;
• extension Set and Remove precedence over the legacy fallback;
• ChatGPT-auth gating for the reserved server;
• hosted MCP resource reads with and without an active thread;
• connector tool invocation and MCP elicitation through the hosted route;
• ignored boolean and structured forms of the removed path override;
• config-lock replay compatibility for the removed feature.

cargo check -p codex-features -p codex-mcp-extension -p codex-app-server passes. Tests and Clippy were not run locally under the current development instruction; CI provides the full validation pass.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2902b0f638

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[jif-oai]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 19a14a0810

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[jif-oai]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. What shall we delve into next?

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".