[BUG] Control bytes (0x01, 0x05, 0x15, …) rendered as literal text "0x1" / "0x5" / "0x15" in input buffer when running under tmux -CC

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?

Summary

When Claude Code running in an iTerm2 tmux -CC session, pressing any iTerm2 keybinding that emits a raw control byte (0x01, 0x05, 0x15, etc.) inserts the literal text 0x1 / 0x5 / 0x15 into Claude's input buffer instead of acting as a line-editing command (i.e. ⌘ + ⬅️, ⌘ + ➡️, ⌘ + DELETE, CTRL + K). The same bytes are handled correctly...

• by Claude in bare iTerm2 (no tmux)
• by Claude in plain tmux (no -CC)

The raw bytes arriving at the pty are provably identical across all tmux contexts (see Byte-level evidence below), so iTerm2 and tmux are not modifying the stream. This seems to implicate the defect is in Claude Codewhen Claude detects (or is spawned inside) a tmux -CC session.

What Should Happen?

Expected

• After Cmd+Left: cursor moves to start of abc
• After Cmd+Right: cursor moves to end.
• After Cmd+Backspace: line cleared

Error Messages/Logs

Steps to Reproduce

Reproduction

Setup

# Fresh Default-profile iTerm2 window, verified TMUX=[]
/opt/homebrew/bin/tmux -L probe kill-server 2>/dev/null
/opt/homebrew/bin/tmux -L probe -CC new-session -A -s reproCC
# Inside the -CC session:
claude

Steps

In Claude's input box:

1. Type abc.
2. Press Cmd+Left once.
3. Press Cmd+Right once.
4. Press Cmd+Backspace once.

What I see ❯ abc0x10x50x150xb0x16

| Context | Type abc then Cmd+Left / Cmd+Right / Cmd+Backspace |
|---|---|
| Bare iTerm2 (no tmux), Claude 2.1.114 | ✅ cursor moves to start / to end / word-kill (correct readline behavior) |
| Plain tmux (no -CC), Claude 2.1.114 | ✅ cursor moves to start / to end / word-kill |
| tmux -CC, Claude 2.1.114 | ❌ input buffer becomes 0x1abc0x50x15 — literal hex text insertions |

The bare-iTerm2 case was the one reported in #38974 against 2.1.83. That case appears resolved in 2.1.114. The tmux -CC variant below is not resolved and is new information.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.114

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

Environment

macOS 26 (Darwin 25.4.0)
iTerm2 Build 3.6.9
tmux 3.6a (Homebrew)
Claude Code 2.1.114
Shell: zsh
iTerm2 profile keybindings:
| Key | Action | Value |
|---|---|---|
| Cmd+Left | Send Hex Code | 0x1 |
| Cmd+Right | Send Hex Code | 0x5 |
| Cmd+Backspace | Send Hex Code | 0x15 |

Similar bugs

• #38974 reported the same user-visible symptom (literal 0x15 rendered instead of line-kill) under Claude Code 2.1.83 in bare iTerm2. It was auto-closed as dupe of #38657. #38974 is now locked and cannot be reopened or commented on.

Relative to #38974, this report adds:

1. Still reproducing in 2.1.114
2. Specifically under tmux -CC
3. Byte-level evidence proving the bytes arrive correctly end-to-end (not a terminal-serialization issue).

Byte-level evidence

Captured with this sequence (dd one-shot read, 500 ms inter-byte timeout, raw mode):

stty -icanon -echo min 10 time 5
dd bs=64 count=1 2>/dev/null > /tmp/capkey.bytes
stty sane
xxd /tmp/capkey.bytes
od -c -An < /tmp/capkey.bytes

Results across three terminal contexts (same iTerm2 Default profile, same keybindings):

| Key | Bare iTerm2 (no tmux) | Plain tmux (-L probe new-session) | tmux -CC (-L probe -CC new-session) |
|---|---|---|---|
| Shift+Enter | 1b 0a (2 bytes) | 1b 0a | 1b 0a |
| Cmd+Left | 01 (1 byte) | 01 | 01 |
| Cmd+Right | 05 | 05 | 05 |
| Cmd+Backspace | 15 | 15 | 15 |
| Ctrl+K | 0b | 0b | 0b |
| Ctrl+V | 16 | 16 | 16 |

All identical. The bytes arriving at the pty inside a tmux -CC session are exactly the bytes iTerm2 sends when nothing is in the middle. tmux -CC's control channel is not corrupting these bytes on the stdin/pty path — a dd-based reader inside -CC captures them correctly.