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

Activity

1. Win1leven

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Jun 27, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   codex-webIssues related to Codex WebIssues related to Codex Web

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   connectivityIssues involving networking or endpoint connectivity problems (disconnections)Issues involving networking or endpoint connectivity problems (disconnections)

   on Jun 27, 2026
3. github-actions commented on Jun 27, 2026

   

   github-actionsbot

   on Jun 27, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • # Bug report: optional MCP server timeout blocks new Codex conversations #29416
   • Desktop: remote MCP startup timeout blocks creating new conversation #29376
   • Unable to create new threads, start conversations, or submit and push changes. #29421
   • Create New Talk always say TimeOut #29784
   • Codex Desktop new conversations spend several minutes at Reconnecting 5/5 before starting normally #29169

   Powered by Codex Action
4. evelant commented on Jun 30, 2026

   

   evelant

   on Jun 30, 2026

   Last edited by evelant

   More actions

   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.
5. ikruglikov commented on Jul 7, 2026

   

   ikruglikov

   on Jul 7, 2026

   More actions

   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.
6. rkoivunen-sw commented on Jul 8, 2026

   

   rkoivunen-sw

   on Jul 8, 2026

   More actions

   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.
7. vluyet commented on Jul 9, 2026

   

   vluyet

   on Jul 9, 2026

   Last edited by vluyet

   More actions

   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.
8. HayThurJack commented on Aug 2, 2026

   

   HayThurJack

   on Aug 2, 2026

   More actions

   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.
9. Jardingris commented on Aug 23, 2026

   

   Jardingris

   on Aug 23, 2026 – with ChatGPT Codex Connector

   More actions

   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.
10. Jardingris commented on Aug 23, 2026

    

    Jardingris

    on Aug 23, 2026 – with ChatGPT Codex Connector

    More actions

    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.
11. Jardingris commented on Aug 24, 2026

    

    Jardingris

    on Aug 24, 2026 – with ChatGPT Codex Connector

    More actions

    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.
12. elliejayliquid commented on Aug 29, 2026

    

    elliejayliquid

    on Aug 29, 2026

    More actions

    Might be related, can't start new conversations using remote on the phone inside a very old trusted project. Keeps saying it's not trusted. After 6 months of working inside it...
13. infoharksb-dotcom commented on Oct 4, 2026

    

    infoharksb-dotcom

    on Oct 4, 2026 – with ChatGPT Codex Connector

    More actions

    Additional Windows reproduction on October 4, 2026 (Sunday): a scheduled local automation failed with the same thread/start timeout followed by a late orphaned response described in this issue.

    Environment:

    • Windows 11 Home, build 26300, x64.
    • Desktop MSIX package at the time of failure: OpenAI.Codex 26.930.3930.0, verified from the failure stack's package path.
    • Scheduled task in a local project.

    The desktop log records the following sequence (UTC):

    2026-10-04T05:02:39.283Z warning [automations] Scheduled run failed errorMessage="Timed out waiting for MCP response to thread/start"
    2026-10-04T05:02:50.745Z warning [AppServerConnection] response_orphaned hasError=false requestId=thread/start:[redacted] transportKind=stdio
    2026-10-04T05:02:50.749Z error [electron-message-handler] No promise for request ID id=thread/start:[redacted]
    

    The original request IDs match across the two later entries. They have been redacted here. The response arrived approximately 11.46 seconds after the scheduled run was reported as failed. The scheduled failure line appears twice with the same timestamp and automation ID; those two lines represent one observed failure, not two independent runs.

    The scheduled business task did not complete through this run. It was completed later from an existing conversation, so the failure had a real operational impact and required manual recovery.

    This is an observed sequence, not a confirmed shared root cause. I have not established whether an optional MCP server caused the delay, or whether every manually created new conversation is affected. I have not verified a permanent fix.

    Could maintainers advise whether this scheduled Windows variant should be tracked here or in a separate issue, and which sanitized diagnostics would help identify why the thread/start response arrived after its waiter had already timed out?

    The excerpt omits automation IDs, request IDs, local paths, business content, and credentials.