›_ Codex Issues
Codex Issues / #16517

Ghostty: raw `...u` escape-sequence fragments inserted into shell after abnormal SSH disconnect during Codex session

Open 💬 2 comments Opened Apr 2, 2026 by Aadithya-J
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.118.0

What subscription do you have?

Plus

Which model were you using?

_No response_

What platform is your computer?

Darwin 25.2.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

ghostty

What issue are you seeing?

After an abnormal SSH disconnect during an active Codex session in Ghostty, subsequent keypresses are inserted into the shell as raw ...u escape-sequence fragments instead of normal text input.

Example fragments I saw include:

  • 9;5u
  • 1:3u
  • 4;1:3u

This seems specific to Codex in my setup. I have not seen the same behavior with other similar terminal coding sessions in the same Ghostty environment.

The terminal returns to normal immediately if I copy paste and run :

printf '\033[<u\033[>4;0m' && stty sane && reset

What steps can reproduce the bug?

  1. Open Ghostty on macOS.
  2. SSH into a remote machine.
  3. Start an active Codex session on the remote host.
  4. Let the SSH connection break abnormally, for example due to network interruption / timeout / broken pipe while Codex is still running.
  5. Return to the local shell in the same Ghostty tab/window.
  6. Start typing normally.

Observed result:
keypresses are inserted as raw ...u fragments instead of normal text.

Recovery:
copy paste and run

printf '\033[<u\033[>4;0m' && stty sane && reset

What is the expected behavior?

Codex should restore terminal keyboard/input state on abnormal exit or disconnect so that the parent shell remains in a normal text-input mode.

After the SSH/Codex session breaks, typing in the local shell should continue to work normally without requiring a manual terminal reset.

Additional information

  • Terminal emulator: Ghostty
  • Shell: zsh
  • Connection type: SSH to remote host
  • Remote host : Linux 6.14.0-34-generic x86_64 x86_64
  • The disconnect was not a clean exit from Codex; it happened after connection loss / timeout
  • I have only observed this with Codex, not with other similar tools in the same Ghostty setup
  • The fact that printf '\033[<u\033[>4;0m' && stty sane && reset fixes it suggests terminal keyboard/input mode cleanup is being skipped on abnormal disconnect
  • This may be related to enhanced keyboard reporting / CSI-u style input state being left enabled

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 4 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #15083

Powered by Codex Action

Songze1019 · 1 month ago

I investigated this against current main.

PR #19625 added stronger keyboard-reporting cleanup for normal TUI exit, panic handling, and other shutdown paths. However, it cannot fully address this issue when the SSH transport disappears abruptly.

On a TCP reset, timeout, or broken pipe, the remote Codex process can no longer send ESC[<u or other cleanup sequences to the local terminal. Therefore, adding more exit handlers cannot make this failure mode reliable.

The existing environment variable provides a useful confirmation:

CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT=1 codex

With keyboard enhancement disabled, an abnormal SSH disconnect cannot leave the local terminal in CSI-u mode.

A possible upstream policy would be:

  • disable keyboard enhancement by default for true SSH sessions (SSH_TTY / SSH_CONNECTION);
  • preserve current behavior for local sessions;
  • allow users to opt back in explicitly with CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT=0;
  • add unit coverage for SSH detection and environment-variable precedence.

The tradeoff is that modified-key features such as Shift+Enter may be less capable over SSH, so I would like maintainer feedback on whether this policy matches the intended UX.

I am happy to prepare the implementation and tests if the team agrees with this approach and invites a pull request.