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

Activity

1. andkondev

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Apr 28, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on Apr 28, 2026
3. github-actions commented on Apr 28, 2026

   

   github-actionsbot

   on Apr 28, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Long Chat = Extreme Unresponsive. #18568
   • Severe App laggyness on a good computer? #18997
   • Desktop performance collapses in profiles with a few very large local conversation histories (typing, scrolling, thread list, random exits) #18693

   Powered by Codex Action
4. etraut-openai

   added

   performance

   on May 3, 2026
5. tjtradesolu-create commented on Jun 5, 2026

   

   tjtradesolu-create

   on Jun 5, 2026

   More actions

   A_fefarence　c_local のCSVのファイル名・列名を日本語にしてください。　
6. yemerablue-ui commented on Jul 20, 2026

   

   yemerablue-ui

   on Jul 20, 2026 – with ChatGPT Codex Connector

   More actions

   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.
7. yemerablue-ui commented on Jul 20, 2026

   

   yemerablue-ui

   on Jul 20, 2026 – with ChatGPT Codex Connector

   More actions

   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.