Windows app composer freezes about 2s on alphabetic input; numeric input is instant #27924

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

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

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

   performance

   on Jun 12, 2026
2. furkancak1r commented on Jun 17, 2026

   

   furkancak1r

   on Jun 17, 2026

   More actions

   Adding another current Windows data point from #28735:

   • Codex Desktop: 26.611.61753 (released 17 Jun 2026)
   • OS: Windows 11 Pro 10.0.26200 build 26200
   • CPU: 13th Gen Intel(R) Core(TM) i7-1355U
   • Logical processors: 12
   • RAM: 15.7 GB
   • GPU: Intel(R) Iris(R) Xe Graphics, driver 32.0.101.5542
   • Storage: fixed disk, 477 GB

   Observed behavior:

   • Composer typing can lag by about 1-2 seconds.
   • In worse moments it can feel closer to 3-5 seconds.
   • Chat/thread switching also feels janky, and the input lag seems worse around those transitions.

   Personal identifiers, machine name, usernames, serial numbers, and local paths intentionally omitted.

   👍React with 👍1Reacted by xrlim
3. dragonknightk commented on Jun 28, 2026

   

   dragonknightk

   on Jun 28, 2026 – with ChatGPT Codex Connector

   Last edited by dragonknightk

   More actions

   Adding another Windows reproduction case. The behavior here looks very close to the composer freeze described in this issue.

   Environment:

   • Codex Desktop: 26.623.5546.0
   • OS: Windows 10 10.0.19045.0 x64
   • Input method: Weasel/Rime Chinese IME, Weasel 0.17.4
   • Repro scenario: open or start a new Codex session, focus the composer, then quickly type the first word through the Chinese IME

   Observed behavior:

   • During initial typing, the Codex composer or main window visibly stalls for about 1-2 seconds.
   • The same input method is noticeably smoother in other applications.
   • After local Weasel-side optimizations, this stall still repeatedly happens in new Codex sessions.

   I used an external monitor to time keyboard events, visible Codex window updates, Weasel candidate-window changes, process/thread samples, and several key Weasel internal steps.

   Result from one 47.9s run:

   • The monitor recorded 37 visible stalls.
   • In 12 of them, Codex did not visibly update for more than 1000ms after a key press.
   • One representative sample:
     • key: A
     • the Weasel candidate window reacted after about 35.8ms
     • the Codex window visibly changed after about 2114.3ms
     • Codex foreground process CPU peaked at about 7.0% during that segment
     • in the same time window, the measured Weasel internal steps were usually only microseconds to a few milliseconds

   Weasel-side timing summary from the same run:

   • ui.panel.layer_update max: about 21.1ms
   • ui.panel.reposition_window max: about 4.5ms
   • no 1-second Weasel-side stall was observed

   This suggests that the 1-2 second visible delay is more likely in Codex Desktop's own input or UI refresh path, rather than in the IME engine or Weasel candidate-window rendering.