Backspace seems to delete more than one character, making prompting harder.

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

• #16716

Powered by Codex Action

It seems to be an issue that only happens on Linux, since I tested it on Mac OS (macOS Tahoe Version 26.3.1 (a)) and it doesn't delete more than one character.

I'm running into this as well but on Mac OS Sequoia 15.3.2. I see it reliably with Codex via kitty but not with Codex via Terminal.

Codex helped me find the following potential Kitty workaround. ctrl+h acts like backspace and deletes the previous character in a terminal line editor. Historically, ctrl+h sends the ^H control code (ASCII backspace), so many unix terminals and shells treat it as “erase one character to the left.”

Add this to ~/.config/kitty/kitty.conf and reload/restart Kitty:

    # Workaround for Codex TUI over-deleting Backspace in kitty.
    # This forces plain Backspace to send 0x08 (^H) in every keyboard mode,
    # avoiding the duplicate delete seen through kitty's default Backspace path.
    # This is global; comment it out if another terminal app expects DEL (0x7f).
    # Remove this once Codex handles kitty's Backspace input correctly.
    map backspace send_text all \x08

This fixed the double-delete behavior for me in Codex.

⚠️ Important caveat: this changes plain Backspace globally in Kitty from DEL (0x7f, ^?) to BS (0x08, ^H). On my system, using only the Kitty remap fixed Codex, but it broke simple canonical-mode terminal input. For example, with cat, pressing Backspace inserted/echoed ^H instead of erasing a character.

To keep the terminal line discipline aligned with the Kitty remap, I also needed to add the following to ~/.bashrc:

if [ "$TERM" = "xterm-kitty" ]; then
  stty erase '^H'
fi

This is only a workaround, not necessarily the underlying Codex fix. It may affect apps that specifically expect Backspace to send DEL (0x7f), so remove these changes once Codex handles Kitty's default Backspace input correctly.

Environment:

• OS: Pop!_OS 24.04 LTS
• Terminal: kitty 0.32.2
• Codex CLI: 0.122.0

I have the same issue on Linux and it works fine on macOS, so it seems to be isolated to linux environments.

Environment:

OS: Ubuntu i3
Codex CLI: codex-cli 0.130.0
Terminal: kitty 0.32.2
TERM: xterm-kitty
Shell: zsh
COLORTERM: truecolor
tmux: no
stty erase: ^?
Backspace raw bytes from terminal: 7f

Additional checks:

• cat/raw byte capture shows one Backspace press sends exactly one DEL byte: 7f.
• stty erase = ^?, matching the byte sent by Kitty.
• Kitty config has no plain Backspace remap; only ctrl+shift+backspace restore_font_size.
• TERM=xterm-256color codex does not fix it.
• The same keyboard and terminal setup works normally in other terminal applications.
• The over-delete behavior appears only in the Codex TUI prompt.

This strongly suggests Codex is receiving a normal single Backspace event and then applying deletion twice internally, or otherwise double-processing that key event in the prompt editor.

Adding another local data point. This looks very similar, but my repro is not Kitty-specific.

Environment:

OS/session: Ubuntu on X11, awesome WM
Terminal: Alacritty 0.13.2
TERM: xterm-256color
Codex CLI: originally observed on 0.130.0; current installed version is 0.132.0
Shell input method context: ibus/libpinyin is present, but this reproduces in normal English input too

Observed behavior:

• In the Codex TUI prompt, pressing Backspace once can delete two characters.
• This is specific to Codex: normal terminal line editing works correctly in the same Alacritty session.
• Running Codex in a GNOME/GNOME Terminal path does not show the issue on the same machine.
• The issue appears under the current awesome + Alacritty path.

Things tried locally:

• codex --no-alt-screen: did not fix it.
• TERM=xterm-256color codex: did not fix it.
• Explicit Alacritty Backspace bindings were tested and then reverted:
• { key = "Back", chars = "\u007f" }
• { key = "Back", chars = "\^H" }
• Those bindings did not stop the double-delete behavior in Codex, which makes this look less like a simple Backspace byte mismatch.
• Current Alacritty config has no custom Backspace binding.

Current workaround:

• Launch Codex through GNOME Terminal from the same working directory. That avoids the over-delete path locally.

My read is that this is probably in the Codex TUI/input handling layer rather than general shell stty erase, Alacritty's ordinary Backspace byte, or the OS keyboard repeat setting, because the same terminal session handles Backspace normally outside Codex.

I found a workaround for this.

In kitty, pressing Backspace once reports both press and release events via the kitty keyboard protocol:

kitten show-key -m kitty

Output:

BACKSPACE PRESS
CSI 127 u
BACKSPACE RELEASE
CSI 127 ; 1 : 3 u

Codex appears to treat both events as delete actions. Setting this hidden env var fixes it for me:

CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT=1 codex

Persistent workaround:

export CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT=1

Tested with Codex CLI 0.135.0, kitty 0.32.2, TERM=xterm-kitty, Ubuntu 24.04 Wayland.

I found a workaround for this.

This workaround also work for me.
Tested with Codex CLI 0.135.0, kitty 0.32.2, TERM=xterm-kitty, Ubuntu 24.04 X11.

Confirmed on Linux Mint 21.3 with kitty and codex-cli 0.137.0. The double-backspace behavior happens only in Codex TUI, not in other AI CLIs I use. tmux is a working workaround here. In my case, what worked was starting plain tmux first and then launching codex inside the tmux session. This avoids the duplicated backspace behavior in kitty.

Additional confirmed workaround on my side: running Codex inside GNU screen also avoids the duplicated Backspace behavior in kitty. I just reproduced it successfully by starting screen first and then launching codex inside the screen session. So far, both tmux and screen act as effective workarounds here.

I did some local investigation into this and found that the behavior appears to come from KeyEventKind::Release events reaching the TUI input path when enhanced keyboard event-type reporting is enabled.

A minimal fix that works locally is to drop release events at the TuiEventStream boundary, while continuing to forward Press and Repeat events unchanged.

Patch branch:
https://github.com/Pectics/codex/tree/fix/tui-ignore-key-release-events

Commit:
https://github.com/Pectics/codex/commit/04995004e9c2192aa3131fd63a5dc27f4bd1f41d

Related reports:

• https://github.com/openai/codex/issues/16716
• https://github.com/openai/codex/issues/18564

Local testing:

• cd codex-rs && just test -p codex-tui tui::event_stream passes.
• cd codex-rs && just fmt passes.
• cd codex-rs && just fix -p codex-tui passes.

I also observed the same class of behavior locally with Alacritty/fcitx, so this does not appear to be only a Kitty-specific issue. That local observation is additional evidence rather than the sole repro.

I cannot open a PR because repository settings currently limit PR creation to collaborators, but I wanted to share the focused patch and test coverage in case it helps with the eventual fix.

I did some local investigation into this and found that the behavior appears to come from KeyEventKind::Release events reaching the TUI input path when enhanced keyboard event-type reporting is enabled. ...

One small clarification on the proposed fix: I don't think this is the same tradeoff as disabling enhanced keyboard reporting entirely.

CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT=1 is a useful workaround, but it is pretty broad. It avoids the duplicate Backspace behavior by turning off the whole enhanced keyboard path. The patch I tested tries to keep the useful part of that path and only drop KeyEventKind::Release before it reaches normal TUI input handling.

That seems like a smaller change to me because Codex's TUI input handling appears to be press/action based right now:

• Press and Repeat would still be forwarded, so normal typing, shortcuts, and held-key repeat should keep working.
• Mouse, paste, focus, resize, and other non-key events would not be touched.
• From a quick search, the existing TUI handlers that care about key kind already seem to treat Press/Repeat as the action-producing cases, not Release.

I definitely don't mean that release events are never useful. They are useful for apps that track held-key state. I just don't see Codex currently using key-up as a separate UI action, and in this case letting it fall through seems to be what turns one Backspace/Enter action into two.

Confirming CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT=1 as a clean workaround on a different environment, and +1 for @Pectics's focused patch as the preferred upstream fix.

Environment

• OS: Linux Mint 21.3 "Virginia" (x86_64, X11)
• Hardware: Intel Core i3-2310M (Sandy Bridge, 2nd gen)
• Terminal: kitty 0.21.2
• Codex CLI: 0.142.0 (previously reproduced on 0.137.0)
• Shell: bash, TERM=xterm-kitty, no multiplexer

Result
Launching Codex directly inside kitty (no tmux/screen) with:

CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT=1 codex

fixes the double-delete behavior — Backspace erases a single character, as expected. Previously reported tmux and screen workarounds (https://github.com/openai/codex/issues/17793#issuecomment-4650715291, https://github.com/openai/codex/issues/17793#issuecomment-4650772591) still hold, but the env var is lighter: it doesn't wrap the whole session, so scrollback and other kitty behaviors stay native.

On @Pectics's patch
The broad env var works because it disables the enhanced keyboard path entirely. @Pectics's fix/tui-ignore-key-release-events (commit 04995004e9c2192aa3131fd63a5dc27f4bd1f41d) is a more targeted fix: it keeps Press/Repeat events and only drops KeyEventKind::Release, which is the actual root cause of the duplicate action. That preserves the useful parts of enhanced keyboard reporting and matches the diagnosis @kovidgoyal gave in kovidgoyal/kitty#10122 ("the bug is in codex. it needs to either not turn on key release events or handle them correctly").

Would be great if the maintainers could review and land that patch (or equivalent) so the env var workaround can eventually be retired. I've persisted the env var as a local alias for now.