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

  1. Open Ghostty with zsh.
  2. Run codex.
  3. Exit the Codex TUI.
  4. 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

The earlier keyboard-reset fix in https://github.com/openai/codex/pull/19625 does not appear to cover this Ghostty/Linux exit path.

View original on GitHub ↗

2 Comments

galonsky · 1 month ago

also seeing this. I can confirm it does not happen in Terminal.app

keith-cainex · 1 month ago

I can confirm this issue and add a deterministic trigger plus an A/B result.

Environment:

  • Codex CLI 0.145.0, standalone Linux installation
  • Arch Linux, kernel 7.1.4-arch1-1
  • zsh 5.9.2
  • Kitty 0.48.1
  • Ghostty 1.3.1-arch2
  • No tmux/screen/zellij involved

Reproduction:

  1. Start codex with keyboard enhancement enabled.
  2. With the composer empty, press Ctrl+D to exit.
  3. After returning to zsh, the prompt contains:

``text
0;133:3u
``

  1. This reproduces in both Kitty and Ghostty.

A/B confirmation:

CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT=1 codex

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:

ESC [ 100;133:3u

Here, 100 is the Unicode codepoint for d, 133 = 1 + Ctrl(4) + NumLock(128), and event type 3 is key release.

This fits the Codex exit path: Codex handles Ctrl+D on KeyEventKind::Press, requests exit immediately, and enables REPORT_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/