Reuse MCP runtimes when selected availability changes nothing

[jif-oai]

Why

MCP runtime reuse was keyed by every ready selected-capability environment, even when an environment contributed no MCP servers or connectors.

For example:

1. a global stdio MCP is running;
2. a selected remote environment contains only a skill;
3. that environment becomes ready;
4. the MCP and connector projection stays exactly the same;
5. Codex nevertheless rebuilds the MCP manager and restarts the global stdio process.

That restart can interrupt active calls and discard process-local state even though nothing about MCP changed.

What changes

When selected-environment availability changes, Codex now resolves the candidate MCP and connector projection before deciding whether to replace the runtime:

• if the winning MCP servers or their ownership change, rebuild as before;
• if the selected connector snapshot changes, rebuild as before;
• if an enabled MCP is explicitly bound to an environment whose availability changed, rebuild as before;
• otherwise, keep the exact live manager and processes, and update only the availability input remembered by the snapshot.

ready selected environments:  [] -> [skills-env]
resolved MCP servers:          {global_probe} -> {global_probe}
resolved connectors:           {} -> {}
result:                         reuse manager; keep the same process

The comparison uses the resolved winning servers and their sources, so plugin/config ownership remains part of the runtime identity.

Existing stack coverage

The integration PR directly below this one already covers both rebuild boundaries: a selected MCP becomes callable and a selected connector tool becomes model-visible when their environment becomes available. It also verifies that an unchanged selected MCP runtime keeps its process.

This PR does not add another remote-attachment integration scenario for the no-change optimization. environment/add returns before readiness, and app-server does not currently expose a deterministic readiness signal for an environment that contributes only skills. Keeping a fixed-delay test would add flake risk; adding a new readiness API would be outside this fix.

Scope and assumptions

• This does not change skill discovery, World State rendering, or plugin metadata caching.
• This does not add file watching or hot reload behavior.
• This does not change disconnect/reconnect handling.
• Selected environment IDs and their capability contents retain the stack's existing stability assumption.
• Delayed required = true executor MCP behavior remains out of scope.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 40e7b8face

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