Windows Codex Desktop repeatedly shows “ChatGPT stopped unexpectedly” during active tool turns after WebSocket retries

Summary

Codex Desktop on Windows has recently started repeatedly stopping with:

ChatGPT stopped unexpectedly

This is a new regression for me. I have used Codex Desktop for roughly half a year, including many long-running and tool-heavy tasks, without seeing this behavior before.

The issue is now reproducible even in a completely fresh Codex thread and can occur within only a few minutes.

Local diagnostics suggest that the Codex app-server is being replaced/restarted while an active tool turn is still in progress.

---

Environment

• Platform: Windows x64
• Installed package:

OpenAI.Codex_26.818.8289.0

• Codex Desktop log client version:

26.818.61809

• Codex core/client version observed in logs:

0.149.0

• Model used:

gpt-5.6-terra

• Reasoning effort:

high

Hardware at reproduction time:

• RAM: 31.82 GB total, ~19.8 GB available
• GPU: NVIDIA GeForce RTX 4060 Ti 16 GB
• GPU usage at reproduction: low (~1 GB VRAM used)
• No apparent RAM or VRAM exhaustion

---

Reproduction

Reproduction A — existing thread

1. Run a tool-heavy Codex task.
2. Codex Desktop unexpectedly stops.
3. Restart Codex Desktop.
4. Resume the same thread and ask it to continue.
5. The thread repeatedly reports missing tool results such as:

Custom tool call output is missing for call id: ...

1. Sampling retries occur and the app stops again.

This suggests that a previous app-server restart may leave orphaned tool-call state in the thread.

Reproduction B — completely fresh thread

To rule out corrupted conversation history, I then:

1. Restarted Codex Desktop.
2. Created a completely new thread.
3. Explicitly instructed it not to restore any previous conversation/tool-call history.
4. Used only durable project state from disk.
5. Asked Codex to perform runtime recovery/status validation and continue a small code/test task.
6. Several shell/tool calls completed successfully.
7. Within a few minutes, Codex Desktop again showed:

ChatGPT stopped unexpectedly

Therefore, corrupted history from the old thread is not the sole cause.

---

Important log sequence from the fresh thread

The fresh thread was:

01a038f5-120a-7152-8825-15a80d47426f

Very early in the turn, before heavy execution, the Responses stream started failing:

stream disconnected - retrying sampling request (1/5)...
sampling_error=request timed out

stream disconnected - retrying sampling request (2/5)...
sampling_error=request timed out

stream disconnected - retrying sampling request (3/5)...
sampling_error=request timed out

stream disconnected - retrying sampling request (4/5)...
sampling_error=request timed out

stream disconnected - retrying sampling request (5/5)...
sampling_error=request timed out

Then Codex logged:

falling back to HTTP

The HTTP fallback temporarily worked:

Request completed
method=POST
url=https://chatgpt.com/backend-api/codex/responses
status=200 OK

Codex then successfully continued executing multiple tool calls.

Examples include:

tool call completed
tool_name=exec

It successfully:

• inspected the project;
• executed runtime recover/status/validate;
• read workflow state;
• opened source/test files;
• started a new runtime transaction;
• modified source and test files.

One patch tool call also completed successfully.

Immediately after this, the turn still reported:

model_needs_follow_up=true
needs_follow_up=true

and token usage was far below the context limit:

total_usage_tokens=92102
full_context_window_limit=258400
full_context_window_limit_reached=false

However, the original app-server process then stopped producing normal turn logs.

There was no normal turn completion and no explicit panic/fatal shutdown event.

A new app-server process appeared shortly afterward.

This corresponded to the UI displaying:

ChatGPT stopped unexpectedly

---

Process behavior

During one reproduction, the active Codex app-server process was:

pid 2160

After the unexpected stop, a new app-server process appeared:

pid 3272

The main ChatGPT Desktop processes remained present.

This looks more like an app-server/runtime replacement than a normal Windows application crash.

---

Windows crash diagnostics

I checked Windows Application Error / Windows Error Reporting and local CrashDumps.

There was no corresponding ChatGPT/Codex WER crash event or ChatGPT crash dump at the time of reproduction.

Other unrelated application crashes were present in WER, showing that WER itself was working.

---

Configuration issues already ruled out

During troubleshooting I found and removed an obsolete config entry:

rmcp_client = true

because the current Codex build logged:

unknown feature key in config: rmcp_client

I also temporarily disabled a failing local Unity MCP server that was returning:

HTTP 503 Service Unavailable

After restarting Codex:

• the obsolete rmcp_client warning was gone;
• the repeated Unity MCP HTTP 503 errors were gone;

but the Codex Desktop unexpected-stop problem still reproduced in a fresh thread.

So those issues do not appear to be the primary cause.

---

Other warnings observed

The current build repeatedly logs:

unknown feature key in config: thread_tools

This key is not present in my user config.toml, so it appears to originate from another configuration layer/internal feature configuration.

I also see:

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

These may or may not be related.

---

Expected behavior

A Codex tool turn should remain alive while valid tool calls are running.

Temporary WebSocket failures should either:

1. recover transparently;
2. cleanly fall back to HTTP without restarting the app-server; or
3. surface a recoverable turn error without corrupting tool-call/session state.

The app-server should not be replaced while an active tool turn is in progress.

---

Actual behavior

Observed sequence:

Fresh Codex thread
    ↓
Responses WebSocket disconnects
    ↓
retry 1/5 ... 5/5
    ↓
request timed out
    ↓
fallback to HTTP
    ↓
HTTP succeeds
    ↓
several tool calls succeed
    ↓
active tool turn continues
    ↓
Codex app-server process disappears/is replaced
    ↓
ChatGPT Desktop shows:
“ChatGPT stopped unexpectedly”

If the affected thread is resumed afterward, orphaned tool calls can additionally result in:

Custom tool call output is missing for call id: ...

---

Why this appears to be a recent regression

I have used Codex Desktop for approximately six months.

I previously ran:

• long-running tasks;
• repeated shell/tool calls;
• multi-hour jobs;
• tool-heavy coding workflows;

without seeing this failure mode.

This behavior appeared only recently and is now reproducible several times in the same day, including in a brand-new thread that runs for only a few minutes.

Because of this change in behavior, I suspect a recent Windows Codex Desktop / app-server / Responses transport regression.

---

Additional observations

The first failed thread accumulated missing tool-call outputs after the app-server restart, but the completely fresh thread demonstrates that stale/orphaned conversation history is not required to trigger the underlying unexpected stop.

The project itself also appears healthy:

• runtime validation passes;
• unit tests pass after recovery;
• no memory/GPU exhaustion is observed.

After each Codex Desktop crash, I can independently recover and validate the project state from disk.

---

Impact

This currently makes Codex Desktop unreliable for normal engineering work on Windows.

The failure may happen in under five minutes, so it is not limited to exceptionally long-running tasks.

It is particularly disruptive for agentic/tool-heavy workflows because app-server replacement during a tool turn can leave the conversation with incomplete tool-call state, causing subsequent thread recovery to fail as well.

I can provide additional sanitized local logs, process timelines, or reproduction data if useful.