shift+enter keybinding doesn't work inside tmux

Summary

The shift+enter → chat:insertNewline keybinding has no effect when Claude Code runs inside tmux, even with the keybinding correctly configured in keybindings.json. The same keybinding works correctly when Claude Code runs directly in Ghostty (and other supported terminals) outside tmux.

Environment

• Terminal: Ghostty (also reproducible with other terminals)
• Multiplexer: tmux 3.6a
• OS: macOS 15
• Claude Code: v2.1.45

Steps to Reproduce

1. Configure ~/.claude/keybindings.json:

``json
{
"bindings": [
{
"context": "Chat",
"bindings": {
"shift+enter": "chat:insertNewline"
}
}
]
}
``

1. Open Claude Code directly in Ghostty (outside tmux) → Shift+Enter inserts a newline ✓
2. Open Claude Code inside a tmux session → Shift+Enter submits the message instead ✗

Root Cause

Claude Code relies on the outer terminal sending extended key sequences natively (e.g. Ghostty is hardcoded as a terminal with native Shift+Enter support). However, when running inside tmux, the outer terminal is no longer visible — Claude Code sees xterm-256color as $TERM and cannot detect Ghostty.

tmux has an extended-keys option that controls whether it forwards kitty keyboard protocol sequences (e.g. \x1b[13;2u for Shift+Enter) to inner panes. With the default extended-keys on mode, tmux only forwards extended keys to panes that explicitly request them by writing the kitty keyboard protocol activation sequence. Claude Code does not write this activation sequence, so tmux never forwards Shift+Enter to it.

The binary was inspected and confirmed:

• No kitty keyboard protocol activation sequence (\x1b[>1u or equivalent) is written on startup
• A CSI-u parser (/^\x1b\[(\d+)(?:;(\d+))?u/) is present and would correctly handle the sequence if it arrived

Workaround

Users can work around this by setting tmux to unconditionally forward extended keys in ~/.tmux.conf:

set -g extended-keys always
set -as terminal-features 'xterm*:extkeys'

This forces tmux to forward \x1b[13;2u to all panes regardless of whether they requested it, bypassing the missing activation step in Claude Code.

Proposed Fix

When Claude Code initialises and $TMUX is set in the environment, it should write the kitty keyboard protocol activation sequence to request extended keys from tmux. This would make Shift+Enter work inside tmux with the standard extended-keys on setting, without requiring users to modify their tmux configuration.

Alternatively, tmux could be added to the list of environments where a fallback key sequence approach is used (similar to how VSCode/Alacritty are handled via /terminal-setup), though the activation-sequence approach would be more seamless.