[Windows][26.818.2872.0] Codex Desktop crashes during tool execution; app-server restarts and resumes thread

Open 💬 3 comments Opened Aug 21, 2026 by renan-cesare
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Codex Desktop on Windows 11 repeatedly crashes during real coding/tool execution and shows the “ChatGPT stopped unexpectedly” recovery screen.

The failure is reproducible during project inspection / command execution. The same local project remains usable through Codex CLI on the same machine.

I inspected the local Codex log database read-only. In one captured failure, the active app-server process stopped appearing without a recorded fatal error, a new app-server process started ~37 seconds later, and the existing thread was successfully resumed with parse errors: 0.

After resume, the log also contains:

codex_features: unknown feature key in config: thread_tools

I do not know whether that warning is causal; I am including it because it appears in the recovery sequence and similar feature-version skew has been reported before.

Environment

  • Platform: Windows 11 x64
  • Codex Desktop package: OpenAI.Codex 26.818.2872.0
  • Standalone Codex CLI: codex-cli 0.149.0
  • CLI works on the same machine/project while Desktop crashes

Reproduction

  1. Open Codex Desktop on Windows.
  2. Open or resume a coding conversation for a local project.
  3. Start a substantive coding task that requires project inspection and command/tool execution.
  4. During active command/tool execution, Codex Desktop eventually terminates or shows “ChatGPT stopped unexpectedly.”
  5. Restart/reopen Codex Desktop.
  6. The previous conversation can be resumed.

Simple app usage is substantially more stable; the repeated crashes have occurred during real coding/tool execution.

Captured restart timeline

Timezone: -03:00

  • Old app-server process: PID 1320
  • Last observed normal activity from that process: approximately 2026-08-21 00:11:43 -03:00
  • Immediately before disappearing it was still emitting normal events such as:
app-server event: item/commandExecution/outputDelta
  • No fatal/error entry was captured immediately before that process disappeared.
  • New app-server process: PID 14420
  • New process startup: approximately 2026-08-21 00:12:20 -03:00
  • The new process then performed thread/resume.
  • Resume result:
Resumed rollout with 262 items ... parse errors: 0
  • During the resumed initialization, the log contains:
codex_features: unknown feature key in config: thread_tools

There is also a PowerShell shell-snapshot warning:

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

That warning appears benign and is included only for completeness.

Troubleshooting already performed

  • Backed up ~/.codex before changes.
  • Validated the old config.toml syntactically with Python tomllib (CONFIG TOML OK).
  • Disabled the old config and let Codex Desktop regenerate a fresh config.
  • Completed the Windows one-time permission/setup flow.
  • Codex Desktop then launched normally.
  • The crash later recurred during substantive coding/tool execution, so the original config does not appear to fully explain the issue.
  • The recovered thread reports parse errors: 0, so the conversation history itself does not appear corrupted.
  • The local project remains intact and usable through the standalone Codex CLI.

Feedback diagnostics

I submitted in-app feedback from the affected Desktop session with the current session logs included.

Feedback ID:

01a021e9-6309-7480-8115-591694279895

Expected behavior

A tool/command failure or app-server restart should be recoverable without terminating the Desktop app. If an unknown feature key is supplied, it should be ignored or handled gracefully rather than destabilizing the app-server.

Actual behavior

The app-server disappears during active work, a new process starts and successfully resumes the thread, but the Desktop experience is interrupted by the crash/recovery screen.

Possibly related issues

  • #35782 — Windows app-server disconnect/recovery causing full Desktop termination under concurrent/high-load tasks. This looks behaviorally close, but my reproduction is on a much newer Desktop package (26.818.2872.0) and I did not capture the same EPIPE sequence.
  • #29140 — app-server crashes on tool calls with unknown feature key in config: thread_tools. That issue was closed after reports that the problem appeared fixed in later builds, so this may represent a regression or a different Desktop manifestation.

I can provide additional sanitized excerpts from ~/.codex/logs_2.sqlite if maintainers need them. I am intentionally not attaching the full database/session transcript publicly because it may contain private project/session data.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 6 days ago

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

  • #39029

Powered by Codex Action

JaredTheHammer · 3 days ago

Additional sanitized Windows reproduction from Codex Desktop 26.818.8289.0 with bundled app-server 0.149.0-alpha.4.3.

The desktop showed the generic stopped unexpectedly screen while the app-server exited with 0xFFFFFFFF. The decisive errors were durable thread projection failures such as expected ordinal 9720, got 9719, followed by the same failure on additional threads. Direct inspection of the canonical JSONL showed duplicated ordinal values at turn boundaries, with the projection cursor stopped on the second copy. The shell also emitted the known unknown feature key in config: thread_tools error during one reconnect.

A backup-first local recovery advanced only the SQLite projection byte offsets past the duplicate metadata records. Raw rollout JSONL, configuration, and conversation content were preserved. SQLite integrity checks passed, the full scan reported zero remaining ordinal mismatches, and the app-server reconnected cleanly after repair.

This supports a Windows regression test for duplicate-ordinal recovery, startup reconciliation of thread_history_*, and a compatible feature handshake that does not send unsupported keys. No private identifiers or transcript content are included here.

renan-cesare · 2 days ago

Thanks for adding this — that’s useful context.

Small update from my side: since moving off the affected 26.818.2872.0 build, I’m currently on 26.818.5229.0 and haven’t reproduced the crash again so far.

I’ve been putting it through fairly heavy real-world use again (long-running tests, lots of command/tool execution, architecture/refactoring work, multiple file changes), and the Desktop app has stayed stable.

I’m not comfortable calling it fixed yet, though. The original failure was intermittent, and your reproduction on the newer 26.818.8289.0 build suggests the underlying condition may still exist or may depend on specific thread state.

I’ll keep the issue open and keep testing under normal heavy workloads. If it happens again, I’ll specifically check for the duplicate-ordinal / projection mismatch pattern you found and add any sanitized evidence here.