Bug Report: Unable to Create New Conversations in Codex Desktop (thread/start Timeout)

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

• #29416
• #29376
• #29421
• #29784
• #29169

Powered by Codex Action

Same here. Disabled plugins, mcps, logged out, logged in again, removed projects and readded, still can't start any threads from codex desktop. Completely breaks the entire app, why has this not been hotfixed yet? It should be a P1 fire kind of thing if people can't even start a thread. This began with one of the automatic updates yesterday.

I can reproduce the same timeout, but in my case the root cause was an unreachable MCP server configured with a LAN-only endpoint. Replacing it with a reachable Tailscale MagicDNS endpoint immediately resolved the issue. See #31359 for details.

Additional Windows evidence: a timed-out thread/start becomes a persistent ghost conversation

I reproduced the same 30-second timeout on Windows and traced the downstream state. This adds a lifecycle consequence not covered in the original report: when the late thread/start response arrives, Desktop still captures its conversation route even though the request promise has already been discarded. The sidebar then contains a conversation that has no database row or rollout and can never be resumed or archived.

Environment

• Windows 25H2, build 26200.8655, AMD64
• Codex Windows package: 26.623.19656.0
• Desktop client version recorded in app-server logs: 26.623.141536
• Several optional MCP servers were configured; some were slow or unavailable during startup

Exact sequence

Three attempts showed the same pattern:

thread/start renderer timeout: 30000 ms
late app-server response:       50237 ms
late app-server response:       42737 ms
late app-server response:       44066 ms

For the third attempt:

08:07:49.087 mcp_request_timeout method=thread/start timeoutMs=30000
08:08:03.093 response_routed method=thread/start durationMs=44066
08:08:03.104 No promise for request ID
08:08:03.197 webview captured browser-use session route
08:08:03.198 browser-session-registry captured session route

The captured conversation ID was 019f40c4-5f0a-7412-90c0-18a689dee3b5. Desktop displayed it as a New chat sidebar entry. Opening it then failed repeatedly with:

no rollout found for thread id 019f40c4-5f0a-7412-90c0-18a689dee3b5

Local-state validation

After the failure:

• state_5.sqlite: zero rows for the conversation ID
• sessions and archived_sessions: no rollout file for the ID
• session_index.jsonl: no entry for the ID
• thread/read: thread ... is not materialized yet; includeTurns is unavailable before first user message
• archive API: No Codex thread found for threadId ...
• restart cleared the in-memory route, but there was no original prompt/rollout to recover

This appears to explain one source of the stale ghost conversations reported in #29868. The MCP startup blocking is also consistent with #29376 and #31359.

Workaround confirmed

I disabled MCP entries that exposed no tools, set enabled MCP servers to required = false, and bounded startup_timeout_sec to 3 seconds. A controlled thread/start check then completed in 8.27 seconds instead of crossing the Desktop 30-second limit.

Suggested lifecycle fixes

1. Do not let optional MCP initialization block core thread creation.
2. Cancel the app-server request when the renderer times out, or explicitly discard the late result.
3. Never register/capture a conversation route after its originating thread/start request has timed out.
4. Make creation atomic: do not expose the conversation ID until a durable rollout exists, or materialize it before returning.
5. Allow stale sidebar/recent entries with no rollout to be removed even when normal archive fails.
6. Expose or align the Desktop request timeout with the MCP initialization/retry budget.

The primary bug is not only that startup exceeds 30 seconds; it is that the late successful response mutates renderer/sidebar state after the failed request, leaving an unrepairable UI entry.

I had the same issue caused by an MCP Server located on the home netwrok. While on the go, i could not initiate any new chat. I could solve it by editing ~/.codex/config.toml

[mcp_servers.YOUR_SERVER]
url = "http://192.168.x.x/mcp"
enabled = true
required = false
startup_timeout_sec = 1
tool_timeout_sec = 30

Read the documentation here : https://developers.openai.com/codex/mcp#:~:text=required%20(optional)%3A%20Set%20true%20to%20make%20startup%20fail%20if%20this%20enabled%20server%20can%E2%80%99t%20initialize.

The doc marks this param as optional, but if not defined, seems to act as required = true.

Windows reproduction and scheduled-start extension (privacy-safe)

Environment:

• Windows 11
• Codex Desktop AppX 26.727.6591.0
• bundled/current CLI 0.146.0
• codex doctor --summary --no-color: 16 ok, 1 idle, 2 notes, 1 warning, 0 failures

Observed on 2026-08-02 UTC:

• Two explicit operator-initiated New Chat actions each produced exactly one UUID, but their distinct thread/start calls took 9,561 ms and 22,305 ms. These were intentional separate actions, not duplicate/replay evidence.
• A controlled no-op New Chat materialized once and completed without a turn error in 35,609 ms.
• A temporary supported scheduled automation then failed to materialize any UUID-backed task. The scheduler logged Timed out waiting for MCP response to thread/start at 05:27:49.584Z and again at 05:28:49.510Z. The automation was deleted at 05:29:54.009Z so no recurrence remained active.
• In the same window, mcpServerStatus/list crossed the 30-second client timeout. One response returned after 104,038 ms, followed by No promise for request ID; another readiness response showed the same late-response lifecycle.
• The explicit-start request IDs were f4c1fa09-4919-47c3-84b8-7f0dbbc2c097 and 3f63b9ff-11ad-4b80-a2cc-6f7f1336125b.

Boundaries checked:

• Fresh OAuth-store waits resolved below 60 seconds; no fresh OAuth lock-timeout failure occurred.
• A malformed local plugin registration was repaired through supported plugin remove/add, but scheduled thread/start still failed.
• The local logging SQLite database passes PRAGMA quick_check; fragmentation is being handled only at a guarded offline boundary and is not presented as causal proof.
• Existing synthetic pending:<uuid> sidebar/global-state residue is tracked as a separate downstream hydration/recovery defect.

This Windows trace closely matches the timeout -> late response -> missing promise lifecycle in this issue and adds a scheduled-start reproduction on the current Desktop package. No prompt payloads, database files, credentials, OAuth stores, or full logs are attached.

macOS scheduled-vs-manual control: same task and app process

I can reproduce the same timeout lifecycle specifically with a standalone scheduled task, while Run now succeeds for the same task on the same Mac and app-server process.

Environment

• macOS 26, upgraded from macOS 15 shortly before the failures began
• ChatGPT Desktop 26.818.41509
• bundled Codex app-server/CLI 0.149.0-alpha.4.1
• standalone daily scheduled task using a local project
• Mac confirmed in full wake at the failed trigger time
• ChatGPT Desktop had remained running
• no other scheduled tasks were active

Failed scheduled run

On 2026-08-23 UTC:

~18:01:52  scheduled thread/start requested
 18:02:22  Desktop timed out after 30000 ms
 18:02:49  app-server response arrived about 57.7 seconds after the request
             -> response had no remaining promise / became orphaned

The run was then automatically archived and shown with a red failure indicator. No rollout/session with a first turn was created, and the task prompt, shell bridge, worker, and target commands were never reached.

Other app-server requests in the same failure window completed normally in approximately 1–35 ms; only thread/start stalled.

Successful manual control

At approximately 23:00:55 UTC, I clicked Run now for the same scheduled task:

• same Desktop version
• same running app-server process
• same task, prompt, project, and packaged thread/start path
• the new-thread route was registered within approximately 170 ms
• the complete task then ran successfully
• its fixed worker completed both target commands with exit code 0

This rules out the downstream script/worker as the cause of this scheduled failure.

The behavior has occurred across Desktop releases 26.814.41407, 26.818.31338, and 26.818.41509. A scheduled run also succeeded once on 26.818.32112, and manual runs have succeeded on versions where scheduled runs failed, so the app version alone does not appear sufficient to trigger it.

Possible clue, not confirmed

Immediately before the late thread/start response in the latest failed run, macOS unified logging recorded three entries like:

FSEventsPurgeEventsForDeviceUpToEventId ... failed: 5

They occurred only a few milliseconds before the orphan response. This may indicate a workspace/file-watcher initialization delay, but I could not confirm the same FSEvents entry in every older failure, so this is only a hypothesis.

The useful distinction here is that scheduled and manual execution use the same packaged thread/start path. The observed difference is response latency at the time of the trigger: approximately 57.7 seconds for the failed scheduled start versus approximately 170 ms for the successful manual start.

Could thread/start be waiting synchronously for workspace, skills, MCP, or FSEvents watcher initialization? Independently of the underlying delay, handling a late successful response without leaving an automatically archived/orphan run would make this failure recoverable.

Follow-up: bundled local stdio MCP startup is on the critical path

Further read-only tracing narrowed the scheduled-start delay to the per-thread MCP initialization window.

• The only enabled local MCP server was the bundled node_repl stdio server.
• Its configured startup_timeout_sec was 120 seconds, while Desktop abandons thread/start after 30 seconds.
• On a failed scheduled start, a new per-thread node_repl process was created at the same instant as thread/start. The successful app-server response arrived late, after Desktop had discarded the request.
• On a successful manual Run now control, another per-thread node_repl process was created at the trigger and the thread route completed immediately.
• The failed-run helper eventually reached the same idle process/file-descriptor state as the successful-run helper, indicating intermittent slow initialization rather than a permanently dead executable.
• The late conversation route had no durable row in state_5.sqlite and no rollout, matching the ghost/orphan lifecycle reported in the Windows evidence above.

The current main implementation still uses McpStartupPolicy::Eager for root sessions in codex-rs/core/src/session/mcp_runtime.rs, and install_initial_mcp_runtime(...).await completes before thread startup returns. The general lazy-start proposal in #22901 was closed without merge.

The delay is not currently reproducible on demand: 20 fresh node_repl initialize/list-tools/kernel cycles completed in 254-300 ms, and 20 cycles including the bundled Codex sandbox path completed in 230-245 ms, all without failure. This supports an intermittent startup/context issue rather than a consistently broken helper.

A controlled A/B is now active: only this optional server's startup timeout was changed from 120 seconds to 3 seconds. The server remains enabled and is not marked required. No scheduled-task, worker, or downstream command configuration was changed. I will report whether the next scheduled trigger materializes a durable thread within the Desktop's 30-second window.

Regardless of the underlying intermittent delay, the product-level defect remains the timeout mismatch: an optional MCP startup can outlive the Desktop request, and the late successful response can still publish an orphan conversation route.

Correction: Desktop hard-codes the bundled helper timeout per thread

The previously described 3-second config.toml A/B did not survive a full Desktop restart.

After restart:

• the global node_repl entry was restored exactly to its previous contents;
• its file modification time fell inside the startup bundled_plugins_reconcile window;
• effective startup_timeout_sec was again 120 seconds.

Inspection of the packaged Desktop implementation explains why. Its Browser Use thread configuration constructs this per-thread override for the bundled helper:

mcp_servers.node_repl = {
  args: [],
  command: <bundled node_repl>,
  env: <managed environment>,
  startup_timeout_sec: 120
}

So editing the managed global timeout is not a durable workaround; Desktop re-synchronizes it and also supplies 120 seconds in the per-thread configuration.

The corrected A/B uses a trusted, project-scoped config for only the affected local project:

[mcp_servers.node_repl]
enabled = false

This is intentionally narrower than disabling the helper globally. Codex config tables merge recursively, and the Desktop per-thread override does not set enabled, so the project-level false survives the upper 120-second table overlay. Effective-config checks confirm:

• inside the affected project: enabled=false
• outside that project: enabled=true
• with a simulated upper mcp_servers.node_repl={startup_timeout_sec=120} override: enabled=false remains effective

The scheduled task does not use Browser/Computer Use tools, so this isolates whether eager startup of the bundled optional helper is the component crossing the 30-second Desktop limit. The next scheduled result will be reported separately.