[BUG] macOS CMD+Left from iTerm renders as 0x1 in chat input, but Ctrl+A (same byte) works
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
- iTerm2
- et
- tmux
- claude
- Type "hello world"
- CMD+Left/Right
- 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_
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗