2.1.269: all ESC-sequence keys (arrows, Home, End) dead in the composer; single-byte keys unaffected; 2.1.268 is fine

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

On 2.1.269, every key that sends an ESC-prefixed escape sequence is dead in the composer. Every key that sends a single byte still works. Reverting to 2.1.268 restores them completely, with nothing else changed.

Dead on 2.1.269:

| key | sends |
|---|---|
| Left / Right / Up / Down | ESC [ D / C / A / B |
| Home / End | ESC [ H / F |

Still working on 2.1.269:

| key | sends |
|---|---|
| Backspace | 0x7F |
| Ctrl-A / Ctrl-E | 0x01 / 0x05 |
| Ctrl-B / Ctrl-F | 0x02 / 0x06 |
| Ctrl-P / Ctrl-N | 0x10 / 0x0E |
| Ctrl-J, Ctrl-K, Ctrl-U, Ctrl-W, Ctrl-D | single control bytes |

The split is total and has no exceptions in either direction, which is what points at escape-sequence handling rather than at input generally. A dead keyboard, a dead stdin, or a terminal problem would not spare Backspace while taking Left.

The keys fail silently — no character is inserted, nothing is echoed, the cursor simply does not move.

The terminal is sending the sequences correctly

At a shell in the same terminal, cat -v shows the expected bytes:

$ cat -v
^[[D^[[C^[[A^[[B

Standard CSI, unmangled. So the sequences reach the host intact and only Claude Code fails to act on them.

It is the build, not session state

This is the part I would most want a maintainer to note, because it rules out the usual suspects:

• /exit and relaunch with --continue — still dead. So not leaked terminal state, not a stuck mode from an earlier command.
• Reverting the symlink ~/.local/bin/claude to the 2.1.268 binary already on disk, then relaunching in the same terminal tab — arrows, Home and End all work again.
• Re-pointing at 2.1.269 brings the fault back.

Same machine, same terminal, same tab, same profile, same settings file. The only variable is the binary.

Environment

| | |
|---|---|
| Broken | 2.1.269 |
| Working | 2.1.268 |
| OS | macOS, Darwin 24.6.0 (arm64) |
| Install | native, ~/.local/share/claude/versions/ |
| Terminal | AbsoluteTelnet 14.07 over SSH, fixed 141x35 |
| TERM | xterm-256color |
| settings.json | "tui": "fullscreen" |

tui: fullscreen has been set continuously since 2026-07-30 and arrows worked throughout, so it is not the variable — but it is worth stating in case the regression is specific to the fullscreen input path.

There is no ~/.claude/keybindings.json on this machine and no vim mode in use.

Steps to Reproduce

1. Run Claude Code 2.1.269 over SSH in a terminal that sends standard CSI cursor sequences.
2. Type any text into the composer.
3. Press Left, Right, Home or End.

Expected: the cursor moves.
Actual: nothing happens. Ctrl-B / Ctrl-F / Ctrl-A / Ctrl-E do move it, which is the workaround.

What Should Happen?

Cursor keys should move the cursor, as they did in 2.1.268.

Note on the search

I could not find an existing report of this. The nearest neighbors I found are related but distinct, and I do not believe either explains it:

• #88249 — TUI does not restore raw mode after SIGCONT. Ours occurs with no suspend/resume at all, and survives a full restart.
• #91142 — mouse tracking turning the wheel into arrow keys. Ours shows no mouse-report text, and pointer position makes no difference; moving the mouse over the window neither triggers nor relieves it.