Ghostty: exiting Codex leaves raw 0;5:3u fragment in zsh input
Open 💬 2 comments Opened Jul 26, 2026 by jay-tau
What version of Codex is running?
codex-cli 0.145.0
Which model were you using?
gpt-5.6-sol max
What platform is your computer?
- CachyOS Linux, x86_64
- Kernel 7.1.4-1-cachyos
- Ghostty 1.3.1-arch2.1
- zsh 5.9.2
What issue are you seeing?
Every time I close the interactive Codex TUI and return to zsh, a raw fragment is inserted at the shell prompt:
0;5:3u
It prefixes whatever I type next. For example:
0;5:3uclaude
This resembles the visible tail of a CSI-u / Kitty enhanced-keyboard event, likely the Ctrl+D key-release encoding. Codex appears to hand the terminal back to zsh before that event is fully consumed or the keyboard mode is restored.
Steps to reproduce
- Open Ghostty with zsh.
- Run codex.
- Exit the Codex TUI.
- Start typing the next shell command.
Expected behavior
The zsh prompt receives no bytes from the Codex session, and the next command can be typed normally.
Actual behavior
The next command is prefixed with 0;5:3u on every exit.
Related reports
- https://github.com/openai/codex/issues/31865
- https://github.com/openai/codex/issues/19553
- https://github.com/openai/codex/issues/16517
The earlier keyboard-reset fix in https://github.com/openai/codex/pull/19625 does not appear to cover this Ghostty/Linux exit path.
2 Comments
also seeing this. I can confirm it does not happen in Terminal.app
I can confirm this issue and add a deterministic trigger plus an A/B result.
Environment:
0.145.0, standalone Linux installation7.1.4-arch1-15.9.20.48.11.3.1-arch2Reproduction:
codexwith keyboard enhancement enabled.Ctrl+Dto exit.``
text
``0;133:3u
A/B confirmation:
With keyboard enhancement disabled, the fragment no longer appears in either terminal.
The observed fragment appears to be the tail of a Kitty keyboard-protocol packet:
Here,
100is the Unicode codepoint ford,133 = 1 + Ctrl(4) + NumLock(128), and event type3is key release.This fits the Codex exit path: Codex handles
Ctrl+DonKeyEventKind::Press, requests exit immediately, and enablesREPORT_EVENT_TYPES. The corresponding release can therefore arrive after the TUI has handed stdin back to the parent shell. Resetting keyboard mode would not remove an event already queued on stdin.PR #35021 already describes this mechanism for iTerm2 and disables event-type reporting there, but retains it for Kitty and other detected terminals. This reproduction indicates that Kitty and Ghostty are affected as well. A terminal-independent exit cleanup that prevents the triggering release event from reaching the parent shell may be preferable to another terminal-specific exception.
Protocol reference: https://sw.kovidgoyal.net/kitty/keyboard-protocol/