›_ Codex Issues
Codex Issues / #22571

MCP transport should recover after remote MCP server restart

Open 💬 5 comments Opened May 13, 2026 by nedlern

Summary

Codex CLI/app-server does not recover native MCP tool access after a configured remote MCP HTTP server is restarted. The session can get stuck with tool calls timing out or failing with Transport closed, even after the remote server is healthy again for fresh MCP clients.

Environment

  • Codex CLI: codex-cli 0.130.0
  • Runtime shape: codex app-server with MCP configured as:
  • command: npx
  • args: ["mcp-remote", "http://127.0.0.1:7777/agents/cvp/mcp/"]
  • Remote MCP server: local HTTP MCP server via mcp-remote
  • OS: macOS

Repro

  1. Start a Codex app-server/session with an MCP server configured through mcp-remote.
  2. Call a native MCP tool successfully.
  3. Restart the remote MCP HTTP server while the Codex session remains open.
  4. Verify the remote MCP HTTP server is healthy for fresh clients:
  • manual MCP initialize POST returns 200
  • tool calls through a fresh MCP HTTP session work
  1. Try calling the same MCP tool from the existing Codex session again.

Observed

After the remote MCP server restart, the existing Codex session's tool calls failed in two phases:

  • Initially: timed out awaiting tools/call after 120s
  • After killing the stale child mcp-remote process for that session: Transport closed

The Codex app-server did not recreate a usable MCP transport for the still-open session. The practical recovery was to restart the whole Codex session/app-server.

Expected

Codex should either:

  • detect the MCP transport failure and respawn/reconnect the configured MCP server transport automatically, or
  • expose a user/operator command/API to reload or restart one MCP server transport for the current session without restarting the whole Codex session.

Why this matters

For local persistent multi-agent workflows, MCP servers can be patched/restarted independently of active Codex sessions. A full session restart loses conversational continuity and forces handoff/recovery procedures even when the remote MCP server itself is healthy again.

Notes

In this incident, a fresh manual MCP client could initialize and call tools against the restarted server, so the remaining failure appeared to be the long-lived Codex-owned MCP transport lifecycle rather than the remote server itself.

View original on GitHub ↗

5 Comments

trungng92 · 3 months ago

I agree that having to restart codex or run /clear is not ideal.

detect the MCP transport failure and respawn/reconnect the configured MCP server transport automatically, or

I prefer this as an option or flag that can be enabled or disabled.

expose a user/operator command/API to reload or restart one MCP server transport for the current session without restarting the whole Codex session.

And definitely this.

If codex auto reconnects, it could potentially hide instability within the mcp server that becomes invisible in long running tasks that would ideally be fixed (e.g. crashing mcp server that restarts every 10 minutes).

Alchuang22-dev · 2 months ago

I want to add one practical agent-safety concern here.

For Codex-style agents, “restart the MCP server/transport” is not just a normal recovery instruction. In many long-running agent sessions, the agent itself cannot safely close and recreate the current Codex session or MCP transport. If the LLM follows a high-risk suggestion such as “restart MCP” and that action causes the MCP transport to close, the agent may lose access to the very MCP server it needs, while also lacking any host-level API to recreate the transport or open a replacement session.

This creates a error deadlock pattern:

  1. A long-running Codex session depends on an MCP server.
  2. The MCP server/tool returns an error or hint suggesting a restart.
  3. The LLM follows that hint and shuts down/restarts the MCP server or kills the stale transport.
  4. Codex marks the MCP transport as closed.
  5. The current agent session can no longer call that MCP server.
  6. The agent also cannot restart the Codex MCP transport from inside the same session.
  7. Recovery now requires manual user intervention, a new session, or a full Codex restart.

So the impact is worse than a transient tool failure: it can permanently interrupt an autonomous task until a human intervenes.

If automatic MCP transport recovery cannot be implemented immediately, Codex should at least make this risk explicit. In particular:

  • Documentation and UI should clearly mark “ask Codex to restart MCP” as a high-risk operation that can interrupt the current task/session.
  • MCP tool error responses should avoid casually suggesting “restart the MCP server/transport” when the current Codex session cannot actually recover from a closed transport.
  • Ideally, Codex should expose a host-level command/API to restart or reload one MCP transport for the current session, or automatically recreate the transport after detecting Transport closed, broken pipe, stale session, or remote restart conditions.

Without such recovery, MCP restart guidance can make the system less recoverable: the agent may obey the instruction and then lose the only channel it had to continue the task.

trungng92 · 2 months ago

A workaround I've been doing is to use sub agents. Sub agents establish a new connection to the MCP server.

So instead of doing long-lived work within a single session, I do work with fresh context in a sub agent (and with refreshed MCP server connections)

Kaexburli · 2 months ago

We are seeing a closely related issue with a remote MCP endpoint behind a stdio bridge.

In our case the remote VM/server becomes available again and logs a real Codex MCP client connection, with the full server-side catalog registered. However the existing Codex thread remains stuck on the stale tool surface discovered earlier, when the bridge was in an offline/stub state.

A fresh Codex session sees the real tools, but the current session does not recover. This matches the need for either automatic MCP transport/catalog recovery or a user/operator command to reconnect/reload one MCP server without restarting the whole session.

andriy-viyatyk · 6 days ago

This also reproduces with a local Windows development server: Persephone's Vite restart stops and starts its MCP server while the Codex session remains open, but the existing session does not regain the tools. I have observed Claude Code recover from the same application/server restart without requiring the chat/session to be restarted, so automatic recovery or a per-server reconnect command would materially improve this workflow.