Input lag during high disk usage
Resolved 💬 2 comments Opened Jan 9, 2026 by monotykamary Closed Mar 29, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor)
responded on this thread — see the highlighted reply below.
What version of Codex is running?
codex-cli 0.79.0
What subscription do you have?
Pro
Which model were you using?
gpt-5.2-codex xhigh
What platform is your computer?
Darwin 25.1.0 arm64 arm
What issue are you seeing?
Any time I ran pnpm install, or git clone -q; whenever there was high disk usage, I would see considerable input lag. I've reproduced this over a few multiplexers tmux, zellij, and openmux. I've also tested it on just regular Ghostty.
What steps can reproduce the bug?
- Open ghostty or a similar terminal and split a pane/window.
- Run
codexin one pane - Run
git clone -q https://github.com/zellij-org/zellijin another - Try to spam or type in the
codexpane and see the input lag (sometimes ranging between 1-2 seconds before the key renders to the chat input box).
What is the expected behavior?
There should be no lag. Spamming an empty terminal with a pane that is cloning zellij does not incur the same keyboard input lag.
Additional information
_No response_
2 Comments
This bug report hasn't received any upvotes or additional posts in three months. Closing.
Related instrumented macOS CLI report: https://github.com/openai/codex/issues/24527. A controlled high-load window there increased delayed-key frequency and produced hundreds of synchronized slow
Terminal::size()calls across two Codex TUIs. That confirms system load as an amplifier, although it does not by itself establish that disk I/O is the lower-level mechanism reported here.