iTerm2: Ctrl+C exit can intermittently leave terminal stuck in CSI-u mode and print `9;5:3u`
What version of Codex CLI is running?
codex-cli 0.125.0
What subscription do you have?
_No response_
Which model were you using?
_No response_
What platform is your computer?
macOS 26.4.1 / Darwin 25.4.0 arm64
What terminal emulator and version are you using (if applicable)?
iTerm2 3.6.10
Relevant environment:
SHELL=/bin/zsh
TERM=xterm-256color
TERM_PROGRAM=iTerm.app
TERM_PROGRAM_VERSION=3.6.10
What issue are you seeing?
When running Codex CLI in iTerm2 on macOS, pressing Ctrl+C to exit Codex can intermittently leave the parent terminal input state corrupted. I have not found a stable reproduction pattern yet, and it does not happen on every Ctrl+C exit. However, the failure has occurred after exiting Codex with Ctrl+C.
After Codex exits, the shell can receive or display a raw CSI-u style keyboard sequence such as:
9;5:3u
This looks like Codex enables enhanced keyboard reporting / CSI-u / modifyOtherKeys style input, but does not always fully restore the terminal state on the Ctrl+C exit path. After Codex exits, the parent shell should be back in normal text input mode instead of still emitting raw enhanced-keyboard fragments.
This appears related in shape to #16517, but the environment and trigger are different:
- terminal emulator: iTerm2, not Ghostty
- trigger observed so far: local
Ctrl+Cexit from Codex, not an abnormal SSH disconnect - reproducibility: intermittent; I do not yet know the exact timing or state needed to trigger it
- observed raw fragment:
9;5:3u
What steps can reproduce the bug?
I do not currently have a fully deterministic reproduction sequence. The observed trigger path is:
- Open iTerm2 on macOS.
- Start
codex. - While the Codex TUI is active, press
Ctrl+Cto exit. - Return to the same iTerm2 tab/window's shell.
- Continue typing or pressing keys.
Observed intermittent result:
the shell can receive or display raw CSI-u style text such as:
9;5:3u
What is the expected behavior?
Codex should restore the terminal keyboard/input state on Ctrl+C / SIGINT exit paths, including disabling or popping any enhanced keyboard / CSI-u / modifyOtherKeys modes it enabled.
After Codex exits, the parent shell should immediately behave normally, without requiring the user to run reset, stty sane, or manual terminal control sequences.
Additional information
A possible manual recovery command is:
printf '\033[<u\033[>4;0m' && stty sane && reset
The fact that this kind of reset helps suggests the issue may be related to keyboard enhancement flags / CSI-u / modifyOtherKeys state not being reliably restored.
Suggested area to inspect: the Codex TUI cleanup path for SIGINT, early return, panic, task cancellation, and any other abnormal or semi-abnormal exits. In particular, please check whether keyboard enhancement flags are always restored symmetrically with the setup path.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I'm not able to repro the problem. You mentioned it was intermittent. What are you typically doing in the CLI when the problem occurs? Or does it not seem to be correlated to any particular TUI state?
I wasn't able to repro the problem, bug I've introduced a speculative fix. This will be included in the next release.