PR approval for 'Transport Closed' bug for MCP servers

Open 💬 3 comments Opened Jul 26, 2026 by welf

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

0.125.0

What subscription do you have?

ChatGPT Pro 20x

Which model were you using?

all

What platform is your computer?

This bug is reproducible on all platforms

What terminal emulator and version are you using (if applicable)?

This bug is reproducible in all terminals

Codex doctor report

What issue are you seeing?

I investigated the https://github.com/openai/codex/issues/16899 issue and have a tested fix ready.

TLDR

Root cause: RmcpClient retains a closed RunningService in ClientState::Ready, so subsequent operations reuse the dead transport indefinitely. Fresh Codex processes work because they construct a new client and transport.

The proposed fix recreates and initializes the transport behind the existing recovery semaphore, shares one recovery across concurrent callers, never replays an interrupted tool call, preserves HTTP 404 retry behavior, and tracks replacement stdio processes for cleanup.

Validation: all 119 codex-rmcp-client tests pass, including new preclosed, concurrent recovery, no-replay, and process-cleanup regressions.

Tested commit: https://github.com/welf/codex/commit/bba585c393a0de5e96448707b06248a729aa2cef

Would a Codex maintainer be willing to invite a PR for this approach?

Here is the full PR description:

Fixes #16899

Root cause

RmcpClient stores a successfully initialized service in ClientState::Ready. When the RMCP service task or underlying
transport closes, the stored state is not changed. Normal operations retrieve that Ready service without checking
whether it is still alive.

The RMCP dependency returns rmcp::service::ServiceError::TransportClosed, whose display text is Transport closed.
Codex returns that error but leaves the same closed service cached.

Prepared tool calls and resource clients retain the same Arc<RmcpClient>. Since transport closure does not mark the
MCP runtime dirty, the ordinary per-step dirty check does not rebuild the connection. Every subsequent operation
therefore calls the same closed service.

A new Codex process constructs a new McpRuntime, McpConnectionSet, ManagedClient, and RmcpClient, which explains
why fresh codex exec processes continue to work.

What

Recover an MCP client when its current transport has closed instead of leaving a long-lived Codex session permanently
attached to a dead RunningService.

Recreate and initialize the transport before the next operation when closure is already observable.
Serialize concurrent recovery attempts so callers share one replacement connection.
Recover eagerly after an in-flight operation reports TransportClosed, but return the original error and never replay

the operation.

Track the active stdio process alongside the active service so shutdown cleans up a replacement server too.
Preserve the existing streamable HTTP 404 session-expiry behavior and its single operation retry.

Why

A persistent CLI session kept the original closed MCP service after a stdio server or transport exited. Every later tool
call therefore failed with Transport closed, while a fresh codex exec worked because it constructed a new client and
transport.

How

The client now uses its retained transport recipe and initialization context to rebuild the service behind the existing
recovery semaphore. Recovery atomically installs the replacement service, OAuth persistor, and stdio process handle.
Callers that arrive concurrently reuse a healthy replacement installed by the first recovery attempt.

Regression coverage verifies pre-closed recovery, single recovery under concurrency, no replay after an in-flight
tool-call closure, replacement stdio cleanup, and unchanged HTTP 404 retry semantics. The new recovery regressions were
confirmed to fail before the implementation.

Validation

just test -p codex-rmcp-client — 119 passed, 5 skipped
just argument-comment-lint -p codex-rmcp-client
just fix -p codex-rmcp-client
just fmt

Issue: https://github.com/openai/codex/issues/16899

What steps can reproduce the bug?

See implemented tests

What is the expected behavior?

After Transport Closed error MCP servers should continue to work

Additional information

_No response_

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#16899

Powered by Codex Action

welf · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate. * CLI session loses stdio MCP connections after initial successful calls; fresh codex exec still works #16899

It is the the fix of the mentioned bug, not the duplicated bug report.

AccessNexaaly · 20 days ago

Independent confirmation and source-level validation (2026-08-07):

I reproduced the same failure in a long-lived codex-cli 0.147.0 session: a stdio MCP tool call began returning Transport closed, while the child server process remained alive. A freshly spawned MCP client successfully initialized against the same server and listed its tools, which isolates the failure to the cached Codex-side connection lifecycle.

I checked both rust-v0.147.0 and current main at 8e4b10446eed7bafb39d8a469f9be25a41f4864f. The missing trigger is still present:

Session::prepare_mcp_call refreshes only when the MCP runtime is already marked dirty, then captures the cached binding.
Observing transport closure does not mark that runtime dirty.
McpServerConnection::reusable_client already rejects an initialized client whose is_closed() is true during reconciliation, so reconciliation itself correctly replaces the dead connection once something triggers it.

As a narrow proof of the diagnosis, I locally exposed the selected server's closed state, marked the runtime dirty before dispatch when closed, refreshed it, and extended reconciliation_replaces_closed_connections to assert healthy -> closed -> replacement -> healthy. Validation:

just fmt
just test -p codex-mcp reconciliation_replaces_closed_connections
  PASS codex-mcp connection_manager::tests::reconciliation_replaces_closed_connections
cargo check -p codex-core

This independently supports the root cause and recovery invariant in this approval request. The lower-level recovery patch proposed by @welf is the stronger production solution: it coordinates concurrent recovery, avoids replaying requests whose delivery is ambiguous, and handles replacement stdio process cleanup. Please treat this comment as supporting evidence for reviewing/approving that patch, not as a duplicate bug report.