[Windows][26.818.2872.0] Codex Desktop crashes during tool execution; app-server restarts and resumes thread
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 125k
- Forks
- 19.4k
- PR merge metrics
- PR metrics pending
Description
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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the captured restart sequence and the sanitized data in ~/.codex/logs_2.sqlite, focusing on the disappearing app-server and the subsequent thread/resume. Compare the behavior with issues #35782 and #29140 and the reported thread_tools warning; done means identifying the crash cause and preventing Desktop termination during tool execution while preserving thread recovery.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- backend, desktop
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100