Low Framerate while typing
Open 💬 4 comments Opened Mar 6, 2026 by Quix1
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
What version of Codex CLI is running?
0.111.0
What subscription do you have?
PLUS
Which model were you using?
all models
What platform is your computer?
windows
What terminal emulator and version are you using (if applicable)?
Powershell / CMD
What issue are you seeing?
Inside CMD and Powershell without Codex opened the framerate when i type something is normal. But when i launch codex and i start prompting the typing gets really laggy and delayed like if i would have 10 frame per second.
What steps can reproduce the bug?
Starting codex via CLI
What is the expected behavior?
It should be like in the normal CMD or Powershell when i run commands. For Example in other CLI tools like Claude etc i dont have this problem.
Additional information
_No response_
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I encountered this as well and turns out it is due to the
disable_paste_burstsetting that's default false.If this is set to true, the typing feels natural. I sent codex to figure it out and this is a workaround to paste things into the TUI without triggering a message sent while things are still pasting in. Windows specific timeout is different to Linux/Mac.
Not really helpful for you specifically OP, but perhaps brief info for the codex guys to think of a way to fix this while retaining the paste functionality.
https://github.com/openai/codex/issues/11678
Related instrumented CLI/TUI typing-lag investigation and implementation:
That investigation confirmed repeated synchronous terminal-size queries and focus-time palette refresh as input blockers, then removed/bounded those paths. Patched traces reduced ordinary key-to-draw p95 to single-digit milliseconds, although separate scheduling delays remain possible under heavy load.
The direct measurements were on macOS, so this is not proof that the same cause explains the Windows behavior here. The terminal-size change is cross-platform and gives maintainers a concrete comparison/retest candidate.