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

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.