Codex MCP Transport Closed After 90 Seconds? Recover Safely

If a long Codex MCP tool call fails with Transport closed and the stack includes aws_lc_0_39_0_jent_entropy_switch_notime_impl, stop retrying inside the same Codex process. Save your task state, exit Codex normally, start a fresh process, and test one short read-only MCP call.

That is the only dependable recovery reported for the current Windows failure. One detailed report against Codex CLI 0.147.0 found that a call lasting 61.7 seconds succeeded, while four calls lasting 91.77 to 106.86 seconds failed with the same signature. After one failure, even lightweight calls could fail immediately. In a controlled retry run, 18 of 18 attempts failed across almost 90 minutes.

This is an open upstream bug report, not a confirmed universal 90-second limit. Treat the duration as a diagnostic clue from one carefully measured environment, not a timeout you should encode into every MCP server.

Match the Exact Failure

Use this guide only when the evidence lines up:

• Codex reports tool call failed followed by Transport closed.

• The stack includes aws_lc_0_39_0_jent_entropy_switch_notime_impl or the same aws-lc-rs jitter-entropy path.

• The first failure follows one MCP call that ran for roughly 90 seconds or longer.

• Later MCP calls fail immediately, including calls to a different configured server.

• The affected environment is Windows and Codex CLI 0.147.0, matching the current report.

Do not group every Transport closed message under this diagnosis. An MCP server that exited, a malformed stdio stream, an OAuth failure, a network disconnect, or a startup problem can produce a transport error without this stack or duration pattern.

What the Current Evidence Establishes

The reporter progressively reduced the reproduction from a multi-provider fan-out to one slow call against one provider. The useful boundary is duration, not concurrency.

This evidence supports three operational conclusions:

1. A full Codex process restart is more reliable than waiting for the transport to recover.

2. Splitting slow MCP work into shorter operations is a reasonable temporary mitigation.

3. The stack symbol is a fingerprint for this report, not proof that jitter entropy is the root cause.

The issue author suspects an internal timeout path, but OpenAI has not confirmed the mechanism or a fixed threshold. Do not present that inference as an upstream diagnosis.

Step 1: Preserve the Task Before Restarting

Do not turn a tool transport failure into lost work.

1. Save any unsent prompt outside the Codex composer.

2. Let local file writes or terminal commands finish if they are still active.

3. Record the failed tool name, start time, elapsed time, and complete sanitized error.

4. In a repository task, check the working tree:

   git status --short

5. Note the current Codex version:

   codex --version

Do not paste secrets, proprietary tool inputs, full session transcripts, or private filesystem paths into a public issue. The error signature, duration, Codex version, operating system, and transport type are the useful parts.

Step 2: Stop Retrying in the Poisoned Process

Once a short canary fails immediately with the same signature, further retries add noise. They can also repeat provider work if the upstream operation completed before Codex lost the result.

Exit the Codex process normally. If you are using a terminal, let the current turn settle and close the CLI. If you are using Codex Desktop, quit the application instead of closing only one conversation.

On Windows, confirm that the affected Codex process has exited before relaunching. Use forced termination only when normal exit is impossible and you have already preserved the task and repository state.

Do not begin by:

• deleting ~/.codex state;

• removing MCP server configuration;

• rotating credentials;

• disabling the sandbox;

• increasing every timeout;

• restarting each MCP server repeatedly.

The current report reproduced the failure even with sandboxing bypassed, and the same servers remained healthy through a separate client. Those facts make destructive state cleanup and sandbox changes poor first responses.

Step 3: Run One Short Read-Only Canary

Start a fresh Codex process, reopen the task, and first verify that the repository state still matches your checkpoint. Then call one small, read-only MCP operation that normally completes well under a minute.

Good canaries include:

• list a small number of resources;

• fetch one known record by ID;

• read one issue's state and title;

• return one integration's metadata.

Avoid a broad search, fan-out, large file transfer, media job, or write during this test. The canary should distinguish process recovery from provider latency and side effects.

Success means the fresh process completes the short call and returns a valid result. If the same short call still fails, stop using this diagnosis as complete. Check whether the MCP server is healthy, whether it starts outside Codex, and whether its logs show an independent crash or protocol error.

Step 4: Keep Slow Work Below the Observed Boundary

Until the issue or release notes confirm a fix, redesign long MCP operations so one tool call does not wait for the entire job.

Prefer these contracts:

• submit a job and return a job ID quickly;

• poll job status with separate bounded read calls;

• split large result sets with cursor pagination;

• process one provider or one batch per call;

• store large output in a declared file or object and return a reference;

• cap upstream work and return partial progress explicitly.

For example, replace one synchronous tool that waits for four model providers with three operations:

1. start_analysis validates input, starts the job, and returns job_id.

2. get_analysis_status returns queued, running, failed, or completed.

3. get_analysis_result returns the completed artifact.

This is also safer for retries. A repeated status read is less likely to duplicate expensive work than repeating one opaque long-running call.

Do not assume that raising a caller timeout fixes this report. The observed failure occurred near the same duration across different tool shapes, and the suspected boundary is inside Codex's MCP path. A larger server timeout can leave the call running longer without changing the failing client path.

Distinguish Three Similar Errors

For the third case, use the separate Codex stream disconnected recovery guide. For a server that actually connects while Codex reports an interrupted startup, use Codex MCP startup interrupted but connected.

Retest Only After a Relevant Change

OpenAI's release list still marked 0.147.0 as the latest stable Codex release when this guide was prepared. Newer 0.148 builds were prereleases, and the tracked issue did not confirm a fix.

When the issue changes state or a stable release documents the transport fix:

1. Preserve a disposable test task.

2. Update through the supported installation path.

3. Confirm the new version with codex --version.

4. Run the short read-only canary.

5. Run one controlled long call against non-sensitive test data.

6. Confirm that a second server still works after the long call.

Do not use production writes or paid generation as the first regression test. A successful fix must preserve the long call's result and keep unrelated MCP servers usable afterward.

Monitor the Upstream Issue With Aident Loadout

Aident Loadout can check the issue without giving your agent permission to modify GitHub.

Start with the canonical setup instruction:

Follow https://aident.ai/SETUP.md

Then ask your agent:

Check Aident Loadout account authentication and Vault status. Search the staging capability catalog for a connected read-only GitHub issue Action, inspect its schema, and preflight a request for openai/codex issue 38230. If the request is valid and free, return only the issue state, updated time, labels, title, and canonical URL. Do not comment, react, edit, close, label, change files, or start OAuth.

Success is measurable: the current issue record is returned, the receipt shows a read-only Action, and GitHub remains unchanged. Set up Aident Loadout and monitor the Codex MCP transport fix.

Sources

• OpenAI Codex issue 38230: long MCP calls crash with the aws-lc-rs transport signature

• Official OpenAI Codex MCP documentation

• Official OpenAI Codex releases

• Official aws-lc-rs repository

Refresh this guide when issue 38230 changes state, OpenAI confirms the failure boundary, or a stable Codex release keeps MCP usable after the controlled long-call test.