›_ Codex Issues
Codex Issues / #27924

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

Open 💬 2 comments Opened Jun 12, 2026 by youxiaohou

Environment

  • Codex Windows app: 26.609.3341.0
  • Codex CLI: 0.133.0
  • OS: Microsoft Windows NT 10.0.26200.0
  • PowerShell: 7.6.2

Summary

In the Codex Windows app, starting a new conversation and focusing the composer causes a consistent freeze of about 2 seconds when typing alphabetic input. Numeric-only input is accepted immediately with no visible lag.

Reproduction steps

  1. Open the Codex Windows app.
  2. Start a new conversation.
  3. Click/focus the message composer.
  4. Type alphabetic characters such as abcabcabc.
  5. Observe that the UI/input freezes for about 2 seconds before typing is accepted.
  6. Repeat with numeric-only input such as 123456789.
  7. Observe that numeric-only input has no lag.

Notes

  • Reproduces even in an empty/no-project new conversation.
  • Reproduces when typing English letters as well.
  • Numeric-only input does not reproduce the freeze.
  • Local project scanning seems unlikely because it also happens without a project.
  • Windows Defender, OneDrive, and indexing of newly created directories are not active factors in this environment.

Expected behavior

Alphabetic input in the composer should be accepted immediately, with the same responsiveness as numeric input.

Actual behavior

Alphabetic input causes an approximately 2-second freeze before input appears or can continue.

View original on GitHub ↗

2 Comments

furkancak1r · 2 months ago

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.

dragonknightk · 2 months ago

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.