Need way to hot-load local MCP changes into existing Codex thread

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.422.20832 (2025)

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.4.0 arm64 arm

What issue are you seeing?

Whenever my local MCP server has updates to its tools, the existing Codex UI thread can't access any of the updates, requiring a human to create a new thread in the UI. This is a huge blocker becuase if I'm using Codex to automatically update the MCP surface overnight, every other automation is blocked because existing threads cannot access the updated MCP surface. There needs to be a way to hot-load local MCP changes into existing threads.

What steps can reproduce the bug?

Uploaded thread: 019de35b-8816-72d3-b69b-773269fd8e01

The repro is:

1. Start with a Codex thread that has the local MCP server attached.

In this repo, portfolio_state is built from [tools/prompt_wave_controller.py](/Users/devin.bost/proj/repos/thespaceplace/tools/prompt_wave_controller.py:45) and launched as:
``bash
python3 -u tools/portfolio_state_mcp_server.py serve
``

1. In that existing thread, record what it can see: server version, tool count, and tool names. Current fresh local probe is:

``bash
cd /Users/devin.bost/proj/repos/thespaceplace
python3 tools/probe_local_orchestrator_mcp_servers.py --server portfolio_state --json
`
Right now that reports portfolio_state version 1.31.0 with 107` tools.

1. Update the MCP surface on disk. For example, add a new portfolio_state tool in tools/portfolio_state_mcp_server.py, add it to the controller allowlist in LOCAL_PORTFOLIO_STATE_MCP_TOOL_NAMES, update shape snapshots/changelog, and bump the MCP server version.

1. Fresh-probe the local server in a new process:

``bash
python3 tools/probe_local_orchestrator_mcp_servers.py --server portfolio_state --json
``
This should show the new version/tool count/tool name, because the probe starts a fresh stdio MCP process.

1. Return to the already-open Codex thread and try to call or discover the new tool. The existing thread should still fail to see it or be unable to call it, because its MCP attachment/tool surface was captured before the update. Existing long-lived MCP server processes also do not hot-reload Python module changes.

1. Confirm the mismatch with the repo’s stale-attachment logic: compare the existing thread’s attached observation against the fresh probe. The expected status is attachment_stale_needs_refresh or stop_attachment_stale; the relevant fail-closed guidance is in [tools/kappability_multi_codex_portfolio_supervisor.py](/Users/devin.bost/proj/repos/thespaceplace/tools/kappability_multi_codex_portfolio_supervisor.py:723), and old contracts explicitly say to refresh the Codex MCP attachment before relying on new behavior in [tools/portfolio_state_mcp_server.py](/Users/devin.bost/proj/repos/thespaceplace/tools/portfolio_state_mcp_server.py:139).

The key observation: a fresh local probe can see the updated MCP surface, but an already-created Codex thread cannot. The fix is to start a new Codex thread/session or otherwise refresh the MCP attachment.

What is the expected behavior?

An already-open Codex thread should automatically refresh its attached local MCP surface after the local MCP server/config changes, without requiring a new thread or manual restart.

Concretely:

• After a local MCP tool is added, renamed, removed, or its schema/version changes, the existing thread should detect the changed surface.
• On the next tool-discovery or tool-call opportunity, the thread should use a fresh MCP tools/list result instead of the stale attached snapshot.
• Newly added tools should become discoverable and callable from the existing thread.
• Updated tool schemas/output contracts should be reflected in the thread’s callable metadata.
• Removed tools should disappear or fail with a clear “tool no longer available” error, not linger as stale callable tools.
• MCP identity/freshness checks should report the refreshed version/tool count/source hashes as current.
• Repo trust checks such as get_go_loop_mcp_attachment_freshness should return an aligned/usable state rather than attachment_stale_needs_refresh or stop_attachment_stale.
• If automatic refresh fails, Codex should fail closed with a clear refresh error and recovery hint, not silently keep using stale MCP metadata.

A crisp acceptance-test version:

1. Open Codex thread with portfolio_state attached.
2. Add a new MCP tool locally and update the server allowlist/version.
3. Fresh local probe sees the new tool.
4. Without starting a new Codex thread, ask the existing thread to discover/call that new tool.
5. Expected fixed behavior: the existing thread sees and can call the new tool automatically.

Additional information

_No response_