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:
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+C exit 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+C to 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:
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.
What version of Codex CLI is running?
codex-cli 0.125.0What 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.10Relevant environment:
What issue are you seeing?
When running Codex CLI in iTerm2 on macOS, pressing
Ctrl+Cto 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 everyCtrl+Cexit. However, the failure has occurred after exiting Codex withCtrl+C.After Codex exits, the shell can receive or display a raw CSI-u style keyboard sequence such as:
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+Cexit 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:
Ctrl+Cexit from Codex, not an abnormal SSH disconnect9;5:3uWhat steps can reproduce the bug?
I do not currently have a fully deterministic reproduction sequence. The observed trigger path is:
codex.Ctrl+Cto exit.Observed intermittent result:
the shell can receive or display raw CSI-u style text such as:
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:
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.