›_ Codex Issues
Codex Issues / #24251

Windows Desktop freezes at turn start and completion, but not during mid-response follow-up input

Open 💬 5 comments Opened May 23, 2026 by Yuimi-chaya
💡 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)?

Codex Desktop 26.519.41501 Package: OpenAI.Codex_26.519.5221.0_x64__2p2nqsd0c76g0 Electron: 42.1.0 Chrome: 148.0.7778.97

What subscription do you have?

No OpenAI account / not signed in

What platform is your computer?

Microsoft Windows NT 10.0.26120.0 x64

What issue are you seeing?

Codex Desktop on Windows repeatedly becomes unresponsive at two specific turn-boundary moments:

  1. Immediately after sending a user message.
  2. Immediately after the LLM finishes its response.

However, if I type an additional follow-up / steering message while the LLM is still responding, that does not trigger the freeze.

This suggests the freeze is probably not caused by streaming text rendering itself, but by turn start / turn finalize work such as local conversation persistence, final render/layout, usage/state accounting, plugin/tool state refresh, session list refresh, or Electron main-process synchronization.

Observed behavior:

  • The app becomes unresponsive for 30 seconds to several minutes.
  • The freeze happens at turn boundaries, not during ordinary streaming.
  • Codex main process becomes Responding=False.
  • Electron GPU process can sustain high CPU for several minutes.
  • CPU hot threads move across logical CPUs, so it does not appear to be a defective CPU core.

What steps can reproduce the bug?

  1. Open Codex Desktop on Windows.
  2. Start or continue a conversation.
  3. Send a normal user message.
  4. Observe that the app may freeze shortly after sending.
  5. Let the assistant complete its response.
  6. Observe that the app may freeze again immediately after the response completes.
  7. During an assistant response, send an additional steering/follow-up message before the assistant completes.
  8. Observe that this mid-response input does not trigger the same freeze.

The important detail is that the freeze happens at send-message and assistant-response-complete boundaries, but not when sending a follow-up while the assistant is already responding.

What is the expected behavior?

Codex Desktop should remain responsive when sending a message and when the assistant response completes.

Turn start and turn completion should not block the Electron main process or cause sustained high CPU usage in the main/GPU processes.

Additional information

Diagnostics collected during reproduction:

  • Process affinity was full: 65535 for Codex processes during reproduction.
  • Process Lasso did not change Codex affinity during reproduction.
  • Clearing GPUCache, DawnWebGPUCache, and DawnGraphiteCache did not resolve the issue.
  • Disabling GPU acceleration via Chromium/Electron startup flags did not resolve the issue.
  • Removing Codex++ as a control variable did not resolve the issue.
  • The issue existed before using WeType/WeChat input method features, so that does not appear to be a necessary condition.

Peak process samples:

  • electron-gpu pid 30364 peak around 550% CPU
  • main pid 28708 peak around 400% CPU, Responding=False
  • renderer pid 30116 peak around 100% CPU
  • affinity 65535 for Codex processes during reproduction

A WPR trace was collected during sustained Electron GPU-process CPU usage:

  • codex-wpr-20260523-215009.etl

The trace is large, so I can provide it through a private upload if useful.

Related local artifacts collected:

  • summary.log
  • process-samples.csv
  • thread-hotspots.csv
  • cpu-core-samples.csv
  • WPR .etl trace

Hypothesis:

This looks like a Codex Desktop / Electron turn-boundary performance issue on Windows, possibly in turn start / turn finalize state persistence, final message hydration or Markdown/layout pass, session list refresh, plugin/tool/browser state refresh, or Electron main-process synchronization with renderer/GPU process.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 3 months ago

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

  • #23229

Powered by Codex Action

anngrrr · 3 months ago

I think my issue may be related to #20805.

I’m seeing the same progressive slowdown/reconnect behavior on Windows Desktop, especially in a long multimodal thread with many image attachments.

YunjianAI · 2 months ago

I can reproduce the same turn-boundary freeze pattern described in this issue.

Environment:

  • Codex Desktop on Windows
  • Codex Desktop version: 26.602.3474.0
  • Package path: OpenAI.Codex_26.602.3474.0_x64__2p2nqsd0c76g0
  • Codex command runner observed locally: 0.137.0-alpha.4
  • Workspace contains long-running / image-heavy / tool-heavy conversations

Observed behavior:

  • The app freezes immediately after submitting a user message.
  • The app freezes again when the assistant response is nearly done or just completed.
  • The middle of the streaming response is usually much smoother.
  • This matches the original report: the freeze is concentrated at turn start and turn finalization, not normal token streaming.

Local session-state evidence:

  • Before cleanup, C:\Users\shany\.codex\sessions had about 271 rollout JSONL files.
  • Total active sessions size was about 1.1 GB.
  • Largest single rollout JSONL was about 408 MB.
  • Several other rollout files were larger than 50 MB.

Workaround tested:

  • I moved the 6 largest rollout JSONL files out of C:\Users\shany\.codex\sessions into a backup folder.
  • Active sessions size dropped to about 333.6 MB.
  • Largest remaining rollout file is now about 48.2 MB.
  • After this, the same turn-start / turn-completion freezes became noticeably lighter.

This suggests that the issue may be amplified by large local rollout/session JSONL files, especially from long conversations, tool output, image/base64 payloads, and accumulated event history.

Expected behavior:

  • Sending a message and finalizing a response should not block the Electron main process.
  • Oversized session files should not degrade the whole Desktop app.
  • It would help if Codex Desktop had bounded retention/truncation for large raw event payloads, or at least a warning/repair/archive flow for oversized rollout JSONL files.

This may be related to the same root-cause family as #25779 and #22004.

ViperTecCorporation · 11 days ago

I can reproduce the same turn-boundary freeze pattern on the current Windows build, with a focused ETW/xperf capture.

Environment

  • Package: OpenAI.Codex_26.810.7004.0_x64__2p2nqsd0c76g0
  • Windows 11 Pro x64, build 26200
  • Intel Core i7-14700HX, 28 logical processors
  • Hybrid Intel + NVIDIA graphics
  • NVIDIA driver updated during testing to 32.0.16.1088
  • Bundled Chromium observed as 151.0.7922.137

Reproduction and symptoms

The freezes are concentrated at the same two boundaries described in this issue:

  1. Immediately after submitting a prompt / starting context analysis.
  2. When reasoning and response completion are finalized.

During the middle of an ordinary response the system is generally smoother. The physical mouse cursor can briefly freeze across Windows, not only inside the Codex window. The Codex window has also failed to restore after minimizing; on one occurrence the process tree had to be force-terminated.

Tests that did not resolve it

  • Force integrated Intel GPU
  • Force dedicated NVIDIA GPU
  • Launch with --disable-gpu
  • Update NVIDIA driver and verify the new driver DLLs were loaded by the ChatGPT GPU process
  • Update WSL
  • Change Windows CPU minimum processor-state / power settings
  • Settings -> Pets -> Wake Pet -> wait until visible -> Tuck Away Pet

This makes GPU selection, simple resource saturation, WSL CPU use, and the currently suggested Pet reset insufficient explanations for this reproduction.

Windows events

Multiple previous occurrences were recorded as AppHangTransient for ChatGPT.exe.

In the current app run there were zero Application Error Event 1000 entries for ChatGPT.exe and zero occurrences of exception 0xc06d007f. Therefore this reproduction does not currently match the separate Work Louder / serialport.node delay-load failure described in #33494.

Focused ETW/xperf capture

A focused 41.621-second capture was taken across a user-observed freeze:

  • Lost events/buffers: 0
  • In a representative final 3.6-second interval containing the freeze, system idle was approximately 89.94%
  • Main ChatGPT.exe: approximately 3.48% of total machine CPU capacity, with approximately 3.41% attributed to chrome.dll
  • ChatGPT GPU process: approximately 1.02%
  • Renderer: approximately 0.36%
  • dwm.exe: approximately 0.54%

Graphics-related DPC/interrupt paths were active, but there was no machine-wide CPU saturation, and WSL activity was low. This is correlation, not a confirmed root cause.

The ETL files are retained locally and are not attached publicly because they may contain local paths and process metadata. Sanitized extracts or a privately shared trace can be provided if a maintainer specifies a safe upload channel.

This indicates that the turn-boundary regression remains reproducible in the 26.810 family and can affect system-wide input even while approximately 90% of total CPU capacity is idle.

YunjianAI · 11 days ago

       您发送给我的信件已经收到，我会及时接收并处理，感谢您对我在工作上的支持和配合。——shanyijin2001--------------------------------------------This is an automatic reply, confirming that your e-mail was received.Thank you