[BUG] macOS CMD+Left from iTerm renders as 0x1 in chat input, but Ctrl+A (same byte) works

Resolved 💬 2 comments Opened May 22, 2026 by nlutsenko Closed Jun 22, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Chain: iTerm → Eternal Terminal → tmux 3.5a → Claude Code 2.1.148 on Linux (TERM=tmux-256color).

iTerm Cmd+Left mapped to "Send Hex Code 0x1".
Verified via od -c -An on remote shell: both Cmd+Left and physical Ctrl+A send a single \x01 byte, no other bytes, no escape sequences, no paste markers.

In Claude's chat input, Ctrl+A correctly moves cursor to start of line. Cmd+Left instead renders the literal text 0x1 in the input box. Same byte stream, different behavior — suggests input parser is doing timing- or state-based classification that misfires on the OS-level keystroke path.

Works correctly in CLI Claude running locally on macOS (TERM=xterm, Claude 2.1.145), so the bug only manifests under the tmux+remote chain.

PS. Same exact problem with CMD+Right

What Should Happen?

CMD+Left when sent 0x1/0x5 hex codes should treat those as correct escape sequence.

Error Messages/Logs

Steps to Reproduce

  1. iTerm2
  2. et
  3. tmux
  4. claude
  5. Type "hello world"
  6. CMD+Left/Right
  7. See escape sequence added verbatim (hello world 0x010x05, not actually shifting cursor

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.148

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

_No response_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗