Codex App: new task creation times out when configured MCP server is unreachable

Open 💬 3 comments Opened Jul 7, 2026 by ikruglikov

💡 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)?

26.623.141536

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Immediately after updating Codex Desktop to version 26.623.141536, I could no longer create new chats.

Every attempt failed with:

Task creation failed — Timeout
Chat startup failed — Timeout

Existing chats continued to work normally.

After investigating, I found that the issue was caused by an MCP server configured with a LAN-only endpoint.

When working outside my local network, that MCP server became unreachable. As a result, Codex waited for the MCP connection and eventually timed out, preventing any new task from being created.

After replacing the LAN-only MCP endpoint with a reachable Tailscale MagicDNS endpoint and restarting Codex, new chats worked immediately.

Expected behavior:

If an MCP server is unreachable, Codex should mark that MCP as unavailable, display a warning if necessary, and continue creating the task.

Actual behavior:

A single unreachable MCP server prevents all new task creation until timeout.

This behavior appears to have started after updating to version 26.623.141536.

What steps can reproduce the bug?

Feedback ID: no-active-thread-019f3add-322f-7703-b72a-f7c57de75730

What is the expected behavior?

If an MCP server is unreachable, Codex should mark that MCP as unavailable and continue creating the task instead of failing with a timeout.

Additional information

Feedback ID: no-active-thread-019f3add-322f-7703-b72a-f7c57de75730

The issue was resolved by replacing the LAN-only MCP endpoint with a reachable Tailscale MagicDNS endpoint.

This suggests that Codex currently blocks new task creation while waiting for an unreachable MCP server instead of treating it as unavailable.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

#30348
#30399

Powered by Codex Action

josheverett · 1 month ago

Confirmed the same failure class on macOS, with a configured MCP server that was not fully unreachable but was instead backed by a live, unhealthy local process.

A Codex agent had added the local HTTP MCP endpoint as a persistent global entry in ~/.codex/config.toml after being instructed to use it. The user did not realize the agent had made that configuration durable.

Measured behavior while broken:

Desktop thread/start timed out after exactly 30 seconds.
The app-server returned the corresponding response after about 40.1 seconds.
mcpServerStatus/list took about 65.1 seconds.
App-server initialization and account/config/model requests completed normally.

Terminating the unhealthy server immediately restored conversation creation. Removing the persistent MCP entry and relaunching made the fix durable; codex mcp list --json then completed in about 4.6 seconds and no further thread/start timeouts appeared.

This shows that the problem is broader than a completely unreachable endpoint: a half-alive or stalled optional MCP server can also block all new task creation.

The failure began around an app update, but no causal role for the update was established.

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

Showing cached comments. Read the full discussion on GitHub ↗