Codex Windows "not responding" freeze/hang with long chat/thread

Open 💬 4 comments Opened Apr 28, 2026 by andkondev

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.422.30944

What subscription do you have?

Pro 5x

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

In long threads, the Windows app starts to hang/freeze after sending a message and when the final response is done. The longer the thread, the longer the freeze. Initially a few seconds, then a hang for a minute or two. It's a shame since context so it'd be nice to keep threads going.

What steps can reproduce the bug?

Keep chatting back and forth in thread until it's long enough to hang. A day's worth is often enough for me, 50-100 or so messages.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 4 months ago

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

#18568
#18997
#18693

Powered by Codex Action

tjtradesolu-create · 2 months ago

A_fefarence　c_local のCSVのファイル名・列名を日本語にしてください。　

yemerablue-ui · 1 month ago

I reproduced a Windows Desktop hang in a long, trace-heavy thread on Codex Desktop 26.715.4045.0 / ChatGPT 150.0.7871.124. The local thread JSONL was about 2.18 MB.

Using an external 500 ms WM_NULL responsiveness monitor, I observed an approximately 10-second unresponsive / 10-second responsive cycle. During hangs:

exactly one main ChatGPT.exe UI thread was Wait / Suspended;
the other ~55 UI-process threads were not suspended;
the Codex app-server had 0 suspended threads out of ~60–68;
after roughly five seconds, the foreground PID moved from ChatGPT.exe to dwm.exe, consistent with Windows ghosting an unresponsive window;
Windows Error Reporting recorded AppHangTransient for ChatGPT.exe.

In a foreground-control run, Codex was foreground for 47/60 samples, and the hang still occurred for nine consecutive foreground samples before DWM took over. A separate A/B run reproduced the UI suspension with zero Git processes and no .git present, so the periodic UI hang is not explained solely by the separate orphaned-Git-process bug.

WSL_DISTRO_NAME, WSL_INTEROP, and proxy environment variables were empty. The app-server remained active. This appears to be a Desktop UI-thread suspension/long-thread issue rather than disk saturation or a full backend deadlock.

yemerablue-ui · 1 month ago

Additional reproduction data from Windows, this time with a short thread:

Codex package: 26.715.4045.0
Web bundle/release: codex@26.715.31925
The issue reproduced after a full app restart.
It reproduced with only max_turns_in_single_thread=4 and max_items_in_single_turn=9, rather than a 50–100-message thread.
At two consecutive app-state heartbeats (09:42:49 and 09:43:11 JST), telemetry showed:
thread_count_active=1
thread_count_streaming_owner=1
thread_count_streaming_with_active_runtime=0
thread_count_streaming_without_active_runtime=1
inflight_turn_count=0
delta_events_last_30s=0
pending_request_count=0
host_child_git_process_count=0
A separate corrupted local chat-process record was moved aside and regenerated as valid JSON; the related JSON parse errors dropped to zero, but this UI hang still reproduced.
After the hang, Japanese IME conversion could stop working inside the app until restart. Restart restored IME input, but did not prevent the response hang from recurring.

This looks like a UI/thread state reconciliation problem where the app retains a streaming owner without an active runtime or in-flight turn, and it is not limited to long threads or an active Git child process. I can provide a sanitized Sentry scope snapshot if that would help.