[Windows][26.818.2872.0] Codex Desktop crashes during tool execution; app-server restarts and resumes thread
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
- Open Codex Desktop on Windows.
- Open or resume a coding conversation for a local project.
- Start a substantive coding task that requires project inspection and command/tool execution.
- During active command/tool execution, Codex Desktop eventually terminates or shows “ChatGPT stopped unexpectedly.”
- Restart/reopen Codex Desktop.
- 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
~/.codexbefore changes. - Validated the old
config.tomlsyntactically with Pythontomllib(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 sameEPIPEsequence. - #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.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Additional sanitized Windows reproduction from Codex Desktop
26.818.8289.0with bundled app-server0.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 asexpected 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 knownunknown feature key in config: thread_toolserror 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.Thanks for adding this — that’s useful context.
Small update from my side: since moving off the affected
26.818.2872.0build, I’m currently on26.818.5229.0and 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.0build 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.