Repository navigation
MCP recovery #28704
Description
What version of Codex CLI is running?
codex-cli 0.139.0
What subscription do you have?
ChatGPT Pro
Which model were you using?
gpt-5.5
What platform is your computer?
Darwin 25.3.0 arm64 arm
What terminal emulator and version are you using (if applicable)?
Ghostty 1.3.1 No tmux/screen/zellij.
Codex doctor report
codex doctor --json available. Current PATH codex is /Users/bernard/.local/bin/codex; official install remains /opt/homebrew/bin/codex.What issue are you seeing?
Codex CLI MCP stdio clients can become unavailable after the MCP transport closes.
In my case, CodeGraph MCP repeatedly becomes unavailable. A CodeGraph call fails with:
tool call failed for codegraph/codegraph_context
Caused by:
Transport closed
After this happens, the MCP tool remains unavailable instead of Codex recreating the stdio transport/process and retrying the operation.
I traced this to Codex CLI 0.139.0 MCP stdio recovery behavior. I prepared a small patch branch here:
main...nardovibecoding:mcp-stdio-recovery-after-close-main
The patch:
- treats stdio TransportSend / TransportClosed as recoverable for stdio MCP clients
- recreates the transport/service
- replaces the stored stdio process handle
- terminates the old stdio process
- retries the operation once
Tests passed:
- cargo test -p codex-rmcp-client stdio_transport_close_recovers_and_retries_once -- --nocapture
- cargo test -p codex-rmcp-client --test streamable_http_recovery -- --nocapture
- git diff --check
What steps can reproduce the bug?
- Configure an MCP stdio server, for example CodeGraph.
- Start Codex CLI and call a tool from that MCP server.
- Kill or otherwise close the MCP stdio server process/transport.
- Call the MCP tool again.
- Observe Codex reports
Transport closedand does not reliably recover the stdio MCP client.
What is the expected behavior?
Expected:
Codex should recreate the stdio MCP transport/process and retry once.
Actual:
The MCP tool becomes unavailable after the closed transport.
Additional information
No response
Activity
Necmttn commentedon Jun 22, 2026
I would make the recovery attempt visible in the session log, not only retry internally. A useful record would include MCP server name, transport kind, tool_call_id, old child pid, close/error reason, restart attempt id, new child pid, retry count, and final status.
That gives users the proof they need for the common case: the tool was configured and callable, then the stdio transport died, then Codex either recovered or left the tool unavailable.
Generated with ax - https://github.com/Necmttn/ax
welf commentedon Jul 29, 2026
Here is the fix (awaits PR permission): #35486