3 Commits

• Remove async-trait from extension contributors (#27383)

  ## Why
  
  Extension contributors are registered behind `dyn Trait` objects, so
  native `async fn`/RPITIT methods would make these traits
  non-object-safe. Spell out the boxed, `Send` future contract directly so
  `extension-api` no longer needs `async-trait` while retaining the
  existing runtime model.
  
  ## What changed
  
  - add a shared `ExtensionFuture` alias and use it for asynchronous
  contributor methods
  - migrate production and test implementations to return `Box::pin(async
  move { ... })`
  - remove `async-trait` dependencies where they are no longer used,
  keeping it dev-only where unrelated test executors still require it
  
  ## Behavior
  
  No behavior change is intended. Contributor futures remain boxed,
  `Send`, dynamically dispatched, and lazily executed; cancellation and
  callback ordering stay unchanged.
  
  ## Testing
  
  - `just test -p codex-extension-api` (11 passed)
  - affected extension crates (64 passed)
  - targeted `codex-core` contributor tests (14 passed)
  - `just fmt`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  
  A broad local `codex-core` run compiled successfully but encountered
  unrelated sandbox and missing test-binary fixture failures; CI will run
  the full checks.

  jif · 2026-06-10 14:31:09 +02:00
  d2f6d23c6c
• Use plugin-service MCP as the hosted plugin runtime (#27198)

  ## Stack
  
  - Base: #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. #27184 resolves filesystem-backed skills through the executor that
  owns a selected root.
  2. #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.

  jif · 2026-06-10 12:54:21 +02:00
  9cd11e9e62
• Route hosted Apps MCP through extensions (#27191)

  ## Stack
  
  - Base: #27184
  - This PR is the second vertical and should be reviewed against
  `jif/external-plugins-1`, not `main`.
  
  ## Why
  
  CCA is moving toward a split runtime where the orchestrator may have no
  filesystem or executor, but it still needs to activate remotely hosted
  plugin components. HTTP MCP servers are the simplest complete example:
  they need configuration and host authentication, but they do not need an
  executor process.
  
  The Apps MCP endpoint is currently synthesized by a special-purpose
  loader inside the MCP runtime. That works locally, but it leaves hosted
  MCP activation outside the extension model being established in #27184.
  It also makes the Apps path a poor foundation for plugins whose skills,
  MCP servers, connectors, and hooks may come from different sources or
  execute in different places.
  
  This PR moves that one behavior behind an extension-owned contribution
  while preserving the existing local fallback. It deliberately does not
  introduce a generic plugin activation framework.
  
  ## What changed
  
  ### MCP extension contribution
  
  `codex-extension-api` gains an ordered `McpServerContributor` contract.
  A contributor returns typed `Set` or `Remove` overlays for MCP server
  configuration; later contributors win for the names they own.
  
  The contract stays at the existing MCP configuration boundary.
  Extensions do not create a second connection manager or transport
  abstraction.
  
  ### Hosted Apps MCP extension
  
  A new `codex-mcp-extension` contributes the reserved `codex_apps` server
  from the existing Apps feature, ChatGPT base URL, path override, and
  product SKU configuration.
  
  When `apps_mcp_path_override` is enabled for `https://chatgpt.com`, the
  resulting streamable HTTP endpoint is
  `https://chatgpt.com/backend-api/ps/mcp`. The existing ChatGPT-auth gate
  remains authoritative, so this server can run in an orchestrator-only
  process without being exposed for API-key sessions.
  
  ### One resolved runtime view
  
  `McpManager` now distinguishes three views:
  
  - **configured:** config- and plugin-backed servers before extension
  overlays;
  - **runtime:** configured servers plus host-installed extension
  contributions;
  - **effective:** runtime servers after auth gating and compatibility
  built-ins.
  
  App-server installs the hosted MCP extension and uses the runtime view
  for thread startup, refresh, status, threadless resource reads,
  connector discovery, and MCP OAuth lookup. This keeps
  `mcpServer/oauth/login` consistent with the servers exposed by the other
  MCP APIs. The hosted Apps server itself continues to use existing
  ChatGPT host authentication rather than MCP OAuth.
  
  ## Compatibility
  
  Hosts that do not install the MCP extension retain the existing Apps MCP
  synthesis path. This preserves current local-only, CLI, and
  standalone-host behavior while app-server exercises the extension path.
  
  Disabling Apps removes the reserved `codex_apps` entry, and losing
  ChatGPT auth removes it from the effective runtime view. Executor
  availability is not consulted for this HTTP transport.
  
  ## Follow-ups
  
  The next vertical will resolve a manifest-declared stdio MCP server from
  an executor-selected plugin root and execute it in the environment that
  owns that root. Later verticals can add backend-owned skills, connector
  metadata, hooks, durable selection semantics, and incremental local
  convergence without changing the component-specific runtime boundaries
  introduced here.
  
  ## Verification
  
  Focused coverage was added for:
  
  - contributing the hosted Apps MCP at `/backend-api/ps/mcp` without an
  executor;
  - requiring ChatGPT auth in the effective runtime view;
  - removing a reserved configured Apps server when the Apps feature is
  disabled.
  
  `cargo check -p codex-app-server -p codex-mcp-extension -p
  codex-extension-api -p codex-mcp` passed. Tests and Clippy were not run
  locally under the current development instruction; CI provides the full
  validation pass.

  jif · 2026-06-09 22:44:16 +02:00
  4ec3b8eeea