Unable to do anything in codex - timeout or failed to retrieve/archive error message

Open 💬 3 comments Opened Jun 28, 2026 by e-berthold

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

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.623.42026

What subscription do you have?

Enterprise with Cisco

What platform is your computer?

What issue are you seeing?

For the last 3 days I have been unable to use codex. I get a timeout error anytime I try to create a new chat. If I try to archive an old chat I get a "failed to archive" error. And if I try to go back to a previous chat I receive and error saying unable to retrieve.

I have restarted the app, restarted my computer, updated the codex app when a new download was available - none of these things helped. I saw a case similar to this and it talked about a mcp that was blocking new chats. I have no idea how to identify if or which mcp could be causing that but I uninstalled the most recent ones I could think of and restarted my app afterwards. Still no change.

Please help!

What steps can reproduce the bug?

Feedback ID: no-active-thread-019f0c08-7985-79d2-b7c6-d6ddb9a7e005

What is the expected behavior?

The expected behavior is that I can start a new chat, archive old ones, or review old ones with no issues.

Additional information

_No response_

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

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

#30348
#29376
#29784
#29868
#29421

Powered by Codex Action

josheverett · 1 month ago

A concrete diagnostic path for this timeout class:

In one macOS case, the root cause was a persistent MCP entry in ~/.codex/config.toml pointing to a local HTTP server that was still alive but unhealthy. A Codex agent had added the endpoint globally after being instructed to use it, and the user did not realize the change was durable.

The useful signals were:

Desktop logged mcp_request_timeout for thread/start at 30 seconds.
The app-server returned the same request only after about 40 seconds.
mcpServerStatus/list took about 65 seconds.
App-server initialization and account/config/model RPCs were otherwise healthy.

Terminating the unhealthy local server immediately restored new conversations. Removing the MCP entry and relaunching made the fix durable.

For anyone seeing this symptom, inspect:

codex mcp list --json

and ~/.codex/config.toml for configured endpoints that may be unreachable, stalled, or backed by unhealthy local processes. The app should surface the offending MCP server instead of returning only a generic timeout.

_Disclosure: this comment was drafted and posted by ChatGPT on the user's behalf from diagnostics the user reviewed and approved._

adaptiveo · 5 days ago

Related but likely different local cause on Windows (Codex Desktop 26.818.2872.0).

Archiving selected chats fails with:

failed to archive session: thread-store internal error: failed to archive thread: The system cannot find the file specified. (os error 2)

We verified that the affected rollouts were not missing. In state_5.sqlite, affected threads.rollout_path values were stored as:

\\?\C:\Users\<redacted>\.codex\sessions\...

while the rollout files existed at the equivalent normal C:\... paths.

After making a backup, removing only the \\?\ prefix from one affected thread’s row allowed the normal desktop archive action to succeed. The rollout moved to archived_sessions, archived=1 was set, and the task moved from the active list to the archive list.

The condition recurs: currently 11 unarchived threads have this prefix and their source files exist at the corresponding normal paths. This suggests a Windows path-normalization defect in the thread-store archive flow, separate from missing rollout files or MCP timeouts.

I can provide a minimal redacted path/SQLite snapshot if useful.