openai / openai/codex

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

Open
#39,964 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app app-server bug windows-os
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

  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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.