Skip to content

Codex Desktop on Windows repeatedly restarts while resuming an old thread and enumerating MCP tools #21761

Open
Open
Codex Desktop on Windows repeatedly restarts while resuming an old thread and enumerating MCP tools#21761
Labels
appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingmcpIssues related to the use of model context protocol (MCP) serverswindows-osIssues related to Codex on Windows systems

Description

@jun5896
jun5896
opened on May 8, 2026

Summary

Codex Desktop on Windows repeatedly showed a crash/restart dialog with exit code 3221225786 (0xC000013A) after a sequence involving:

  • enabling/inspecting the /goal feature,
  • resuming an older large rollout thread,
  • parsing a historical thread_name_updated event,
  • and enumerating MCP tool/status data while an Ouroboros MCP server was registered.

The visible "Most recent error" in the crash dialog was usually an incidental WARN, for example Failed to create shell snapshot for powershell, but local logs suggest the more relevant sequence is a thread resume / rollout parse / MCP enumeration path.

Environment

  • OS: Windows 11 Pro
  • Shell: PowerShell
  • Codex Desktop app version in logs: 0.129.0-alpha.15
  • Codex client name in logs: Codex Desktop
  • App server API version in logs: v2
  • Model in the affected session: gpt-5.5
  • MCP servers at the time included: obsidian, codex_apps, node_repl, ouroboros, xcodebuildmcp, cloudflare-api

Observed behavior

Codex Desktop repeatedly displayed:

Codex crashed with:
  (code=3221225786, signal=null)

The "Most recent error" varied and often pointed to WARN-level log entries, including:

Failed to create shell snapshot for powershell: Shell snapshot not supported yet for PowerShell

Other incidental WARN entries included plugin/skill metadata warnings such as:

ignoring interface.icon_small: icon path must not contain '..'
ignoring interface.defaultPrompt: maximum of 3 prompts is supported

Those WARN entries appear to be symptoms/noise rather than the root cause.

Relevant timeline

All times are UTC.

  • 2026-05-08T13:16:17Z: ListToolsRequest appears after Ouroboros MCP registration.
  • 2026-05-08T13:16:19Z: Ouroboros MCP logs codex_cli_runtime.initialized and Registered 25 tools.
  • 2026-05-08T13:18:34Z: User requested Ouroboros to be manual-only.
  • 2026-05-08T13:21:23Z: Local .codex search for goal/goals was run; one search timed out after about 70 seconds.
  • 2026-05-08T13:23:25Z to 13:23:35Z: app-server process restarted several times while mcpServerStatus/list, skills/list, and ListToolsRequest activity appeared.
  • 2026-05-08T13:28:42Z: app-server handled thread/goal/get and thread/resume.
  • 2026-05-08T13:28:42Z: thread/resume started for an old large rollout file:
    • thread id: 019d7d32-be6c-72a0-bafa-25856c359bd2
    • rollout file date: 2026-04-12
    • file size locally was about 1.59 GB
  • 2026-05-08T13:28:44Z: rollout parser logged:
failed to parse rollout line: unknown variant `thread_name_updated`
  • 2026-05-08T13:28:44Z: same resume reported:
Resumed rollout with 46218 items ... parse errors: 1
  • 2026-05-08T13:28:48Z: session init logged a conversation start with 6 MCP servers, including ouroboros.
  • 2026-05-08T13:28:48Z: shell_snapshot WARN appeared. This is what the crash dialog surfaced as "Most recent error".
  • 2026-05-08T13:28:50Z: a new app-server process started and resumed the same thread again.
  • 2026-05-08T13:28:58Z: Ouroboros MCP tool list appeared again (ListToolsResult containing ouroboros_execute_seed, etc.).

Important local evidence

The old rollout file contained exactly the newer/unknown event variant:

{"timestamp":"2026-05-04T12:26:57.512Z","type":"event_msg","payload":{"type":"thread_name_updated","thread_id":"019d7d32-be6c-72a0-bafa-25856c359bd2","thread_name":"CMO Lua script generation"}}

The resume path logged:

failed to parse rollout line: unknown variant `thread_name_updated`

and still continued with:

Resumed rollout with 46218 items ... parse errors: 1

The crash dialog surfaced:

Failed to create shell snapshot for powershell: Shell snapshot not supported yet for PowerShell

but this warning had existed previously and did not appear sufficient to explain the restart loop by itself.

Expected behavior

  • Unknown historical rollout event variants should be ignored or handled compatibly during thread/resume.
  • A parse error in a historical event should not cause a restart loop.
  • Goal checks (thread/goal/get) and thread resume should not unnecessarily wake all registered MCP servers or enumerate tool lists if not required.
  • The crash dialog should distinguish a root-cause error from a last-seen WARN.

Actual behavior

  • Codex Desktop repeatedly restarted or showed crash dialogs with 3221225786.
  • The dialog emphasized incidental WARN lines.
  • The app-server repeatedly resumed the old large thread and initialized sessions with MCP servers present.
  • Registered MCP servers, especially a heavy Ouroboros MCP server, were started/enumerated during this path even when the user did not explicitly call an MCP tool.

Mitigation that stabilized the local setup

The local setup became stable after:

  • removing [mcp_servers.ouroboros] from config.toml,
  • keeping only obsidian in mcp_servers,
  • changing local Ouroboros rules/skills to manual-only,
  • and avoiding automatic Ouroboros MCP registration in Codex Desktop.

After that:

TOML_OK
mcp_servers=obsidian
has_ouroboros_mcp=False

Subsequent monitoring showed no new thread/resume, mcpServerStatus/list, ListToolsRequest, codex_cli_runtime.initialized, or Registered 25 tools events in the checked window.

Hypothesis

This looks like a Codex Desktop stability/compatibility issue around the interaction of:

  1. thread/goal/get / thread/resume,
  2. resuming a very large older rollout containing an event variant not recognized by the current parser,
  3. session initialization after parse errors,
  4. and background MCP status/tool-list enumeration.

The Ouroboros MCP server was likely not executing tools; local logs showed CallToolRequest count as 0 in the relevant analysis. The problem appears to be startup/listing/enumeration, not actual MCP tool execution.

Privacy note

This report intentionally omits account IDs, email addresses, auth headers, local secrets, and full local file contents.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    mcpIssues related to the use of model context protocol (MCP) servers
    app-serverIssues involving app server protocol or interfaces
    on May 8, 2026

  2. github-actions commented on May 8, 2026

    @github-actions
    github-actionsbot
    on May 8, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. banteg commented on May 26, 2026

    @banteg
    banteg
    on May 26, 2026

    not sure if the same root cause, but i got the same error code. this thread started on windows gui codex crashes both gui and tui codex a few seconds into the next message 019e6433-4b1c-70b1-aba5-39840d3ef616
    Image

  4. MisterRound commented on May 30, 2026

    @MisterRound
    MisterRound
    on May 30, 2026 – with ChatGPT Codex Connector

    Adding current-build confirmation from a Windows Desktop + WSL incident on the 26.527 build family.

    This same diagnostic failure still occurs: the fatal UI/log can present the last WARN as the apparent crash cause even when the app-server died while a thread operation was pending.

    Sanitized environment:

    • Windows Store Codex Desktop, package family OpenAI.Codex_26.527.x_x64__2p2nqsd0c76g0
    • Desktop configured to run app-server in WSL
    • Local user/project/thread details redacted

    Observed sequence from Desktop logs:

    app_server_connection.closed code=9 ... transport=stdio
reason="{...\"level\":\"WARN\",\"fields\":{\"message\":\"unknown feature key in config: thread_tools\"},\"target\":\"codex_features\"}"
fatal_error_broadcasted errorMessage="(code=9, signal=null). Most recent error: {...\"level\":\"WARN\"...\"unknown feature key in config: thread_tools\"...}"
Request failed ... method=thread/resume ... error={"code":-32000,"message":"Codex app-server is not available"}
Request failed ... method=thread/goal/get ... error={"code":-32000,"message":"Codex app-server is not available"}
app_server_restart_recovery_failed ... errorMessage="Codex app-server is not available"

    A separate crash window in the same update cycle surfaced plugin icon validation warnings as the "Most recent error":

    ignoring interface.icon_small: icon path with '..' must resolve under plugin assets/
ignoring interface.icon_large: icon path with '..' must resolve under plugin assets/

    Those warnings may be legitimate cleanup bugs, but they were not a reliable RCA for the fatal condition. In this incident, following the surfaced WARNs led triage toward thread_tools config and plugin metadata, while the actual blocking path was app-server unavailability during large-thread resume/goal recovery.

    Related current issues:

    Concrete diagnostic ask: the fatal screen should separate exit code/signal, last ERROR/PANIC if present, last WARNs clearly labeled as non-causal, pending request methods such as thread/resume / thread/goal/get, and whether restart recovery succeeded. A last WARN should not be promoted to "Most recent error" without evidence that it caused process exit.

  5. cedric-albeke commented on Jun 2, 2026

    @cedric-albeke
    cedric-albeke
    on Jun 2, 2026 – with ChatGPT Codex Connector

    Adding a related Windows Desktop observation from the 26.527 build family.

    Environment:

    • Windows 11 Pro
    • Store package: OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0

    Failure pattern:

    • Existing chats repeatedly froze after the update.
    • New chat creation sometimes failed.
    • Restarting only Codex Desktop did not always clear the condition; rebooting Windows helped temporarily.
    • Local process inspection showed extra node_repl.exe processes, each with a child codex.exe app-server --listen stdio://.
    • Separately, the main Desktop process had its normal resources\codex.exe app-server --analytics-default-enabled process.

    The important part: disabling the visible browser plugin config alone was not sufficient. After restart, node_repl still spawned, and the explicit enabled = false I had added under [mcp_servers.node_repl] was removed/ignored.

    Mitigation that stabilized the app:

    • Disable the bundled browser/computer-use plugin.
    • Disable the security-guidance hook plugin to avoid repeated pwsh -> bash -> wsl hook chains.
    • Stop live node_repl.exe and its direct child codex.exe app-server --listen stdio://.
    • Reversibly rename the local node_repl.exe binaries under %LOCALAPPDATA%\OpenAI\Codex\bin.

    After this, Desktop became much more stable and agent task processing became dramatically faster. The tradeoff is that internal browser/computer-use automation is unavailable, but normal chat/task execution continues.

    This may be relevant to app-server restart/recovery diagnostics because the node_repl path can create additional app-server child processes that are easy to confuse with the main Desktop app-server during crash/freeze analysis.

  6. T-Higgins commented on Jun 7, 2026

    @T-Higgins
    T-Higgins
    on Jun 7, 2026

    I am having these issues too. The thread_tools one is the most common one. I have had to stop using the Desktop app completely. I also had to roll back two versions of the VS Code extension too

  7. boombx403-byte commented on Aug 18, 2026

    @boombx403-byte
    boombx403-byte
    on Aug 18, 2026

    Hi @jun5896, regarding the missing tool output / unfinished call state in the transcript, Codex Rescue Alpha5 has bounded tool-correlation diagnostics to detect persisted correlation anomalies and incomplete turn boundaries without assuming non-execution.

    To inspect the rollout locally and safely in read-only mode:

    pip install codex-rescue==0.1.0a5
codex-rescue doctor <path-to-rollout.jsonl>

    No private files need to be uploaded; please sanitize any repository details before sharing diagnostic output.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingmcpIssues related to the use of model context protocol (MCP) serverswindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions