[Bug] v2.1.119 REPL ignores all submit keystrokes when stdin is a tmux pane

Bug Description

Starting with Claude Code v2.1.119 on macOS, the REPL silently refuses every submission keystroke when launched inside a tmux pane — Enter, C-m, C-j, CSI-u, kitty keyboard protocol, bracketed paste, and paste-buffer all produce only newlines in the input buffer and never reach the submission handler. The exact same binary, invoked through a plain python3 -c "import pty; pty.spawn(['claude'])", accepts \r and submits normally. The practical impact is that any daemonized automation that drives the Claude REPL through a tmux session (a common pattern for headless /loop scheduling) is completely broken.

To Reproduce

# 1. Spawn Claude inside a detached tmux pane
tmux new-session -d -s claude-debug-test -c "$HOME" "exec claude"

# 2. Wait for REPL warmup
sleep 10

# 3. Send literal text + Enter
tmux send-keys -t claude-debug-test -l "hello"
tmux send-keys -t claude-debug-test Enter

# 4. Observe: prompt stays in input buffer, no submission, no response
tmux capture-pane -t claude-debug-test -p | tail -20

# 5. Positive comparison (same binary, no tmux):
python3 -c "import pty; pty.spawn(['claude'])"
# type "hello" + Enter -> submits normally, Claude responds

Expected vs Actual

• Expected: Claude Code REPL submits input on Enter regardless of outer terminal multiplexer.
• Actual: Enter (and 17 other variants tested) produces only blank newlines in the input buffer; no submission event reaches the input handler.

Experiment Evidence

The failure is tmux-specific, not keystroke-encoding-specific. The table below summarizes 18 submission strategies tested against the exact same claude binary:

| Variant | Result |
|---|---|
| tmux Enter (baseline) | FAIL — newline |
| tmux C-m | FAIL — newline |
| tmux C-j / -H 0a | FAIL — newline |
| tmux -H 0d | FAIL — newline |
| tmux Escape+Enter | FAIL |
| tmux M-Enter / S-Enter | FAIL |
| tmux C-d / C-o / C-g | FAIL |
| tmux double Enter (500ms gap) | FAIL — two newlines |
| tmux bracketed paste \e[200~..\e[201~ + Enter | FAIL |
| tmux \e[13u (CSI-u Enter) | FAIL |
| tmux \e[27;1;13~ (modifyOtherKeys) | FAIL |
| tmux kitty push \e[>31u + Enter + pop | FAIL |
| tmux set-buffer + paste-buffer + Enter | FAIL |
| tmux w/ TERM=xterm-256color + Enter | FAIL |
| tmux w/ TERM=dumb + Enter | FAIL |
| tmux + script -q /dev/null claude + Enter | FAIL |
| tmux w/ -CC client attached + Enter | FAIL |
| python pty.fork() + \r (no tmux) | PASS — Claude responded |

The key diagnostic signal: an outer tmux layer makes the input handler refuse all submissions; a direct PTY of the same binary accepts submissions normally. Every encoding variant that tmux can produce was tried — none reach the handler.

Environment

• Platform: darwin (macOS 26.3.1, build 25D771280a)
• Terminal: tmux 3.6a
• Node: v24.7.0
• Claude Code: 2.1.119 (@anthropic-ai/claude-code@2.1.119)
• Install path: /opt/homebrew/lib/node_modules/@anthropic-ai/claude-code/bin/claude.exe (Homebrew npm global)

Regression Window

• Last known good: before 2026-04-24 17:23 UTC+9 — an earlier version submitted normally in the same tmux environment; historical daemon logs show Scheduled <8-hex> cron registrations up to 17:51.
• First failure: 2026-04-24 18:53 UTC+9 — first daemon-inject-entry.sh FATAL recorded.
• Binary mtime change matches: claude.exe rewritten at 2026-04-24 17:23:54, aligning precisely with the regression window.

Related Issues

• #52724 — [Bug] Config save not triggered on Enter key press (same tmux + 2.1.119 + Enter handling, different screen context)
• #52728 — [Bug] Control+C does not interrupt vim mode editor (same tmux + 2.1.119 + key handling)

Both report Platform: darwin, Terminal: tmux, Version: 2.1.119 — suggesting a shared root cause in v2.1.119's TUI input handler for tmux environments.

Impact

Any automation layered on a tmux-hosted claude REPL is blocked — specifically daemonized /loop scheduling via CronCreate. The only local workarounds are:

1. Downgrade to a pre-2.1.119 version, or
2. Replace the tmux wrapper with a direct pty.fork() spawn (architectural change to every headless deployment).

Ask

Is this an intentional change (e.g., tighter detection of "scripted" input environments to prevent automation abuse) or a regression?

• If intentional: please document the supported interfaces for headless automation so downstream tooling can migrate cleanly.
• If regression: please confirm the offending input-handler change in the v2.1.119 diff and share a timeline for a fix.

Happy to run additional diagnostics (e.g., strace/dtruss input read trace, TTY attribute dumps, or --debug-level logs) if it helps narrow the root cause.