›_ Codex Issues
Codex Issues / #28704

MCP recovery

Open 💬 2 comments Opened Jun 17, 2026 by nardovibecoding

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:
https://github.com/openai/codex/compare/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?

  1. Configure an MCP stdio server, for example CodeGraph.
  2. Start Codex CLI and call a tool from that MCP server.
  3. Kill or otherwise close the MCP stdio server process/transport.
  4. Call the MCP tool again.
  5. Observe Codex reports Transport closed and 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_

View original on GitHub ↗

2 Comments

Necmttn · 2 months ago

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 · 1 month ago

Here is the fix (awaits PR permission): https://github.com/openai/codex/issues/35486