Activate selected executor plugin MCPs in app-server

[jif-oai]

Why

#27870 teaches the MCP extension how to discover stdio MCP servers declared by a selected executor plugin, but app-server does not yet install that contributor or initialize its per-thread state. As a result, thread/start.selectedCapabilityRoots can select the plugin while its MCP servers remain inactive.

This PR closes that app-server wiring gap:

thread/start(selectedCapabilityRoots)
    -> initialize the thread's selected-plugin MCP snapshot
    -> read the selected plugin's .mcp.json through its environment
    -> start declared stdio servers in that environment
    -> expose their tools only on the selected thread

What changed

• Install the selected-executor-plugin MCP contributor in app-server using the existing shared EnvironmentManager.
• Initialize its frozen thread snapshot when thread/start includes selected capability roots.
• Document that selected plugin stdio MCPs are activated in their owning environment.
• Add an app-server E2E covering the complete selection-to-tool-call path.

The E2E verifies that:

• the selected MCP process receives an executor-only environment value, proving the tool runs through the selected environment;
• the MCP tool is advertised to the model and can be called;
• a normal MCP config reload does not discard the thread's frozen selected-plugin registration;
• another thread without the selected root does not see the MCP server.

Scope

• Existing sessions without selectedCapabilityRoots are unchanged.
• Only stdio MCP declarations are activated. HTTP declarations remain inactive.
• This does not change selected-root persistence across resume/fork or add hosted-plugin behavior.

Verification

• Focused app-server E2E: selected_executor_plugin_exposes_its_stdio_mcp_only_to_that_thread

Stack

Stacked on #27870.

[chatgpt-codex-connector]

💡 Codex Review

codex/codex-rs/ext/mcp/Cargo.toml

Line 17 in 06dc0ab

codex-core-plugins = { workspace = true }

Update Bazel lockfile after dependency changes

Because this change adds Rust deps in Cargo.toml/Cargo.lock but leaves MODULE.bazel.lock untouched, Bazel lock checking can fail with drift. Please run just bazel-lock-update/just bazel-lock-check and include the lockfile update as required by guidance.

ℹ️ 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: 2d65890279

ℹ️ 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".

[chatgpt-codex-connector]

Build sibling binaries for the new E2E under Cargo

On a clean non-Bazel just test -p codex-app-server run, this app-server integration test will not have CARGO_BIN_EXE_codex or CARGO_BIN_EXE_test_stdio_server because those binaries belong to sibling workspace packages, while the new extra_binaries_non_windows wiring only covers Bazel. That makes cargo_bin("codex")? fail before the test exercises the feature unless the developer already happened to build codex; please make these binaries available in the Cargo/nextest path as well or avoid resolving them from this test.

Useful? React with 👍 / 👎.