MCP transport should recover after remote MCP server restart

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.