Menu
Use when enabling Shift+Enter and other modified-key combinations inside TUIs running under tmux - forward CSI-u sequences.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Prepare for a /clear: bring all documentation up to date with this session's changes, persist recovery context (memory + handoff), and emit a copy-paste resume prompt so the next session begins the next task with zero context loss. Invoke explicitly as /clear-prep [next-task].
Use when adding or modifying a devcontainer feature in devcontainer.json - fetch its devcontainer-feature.json schema first and verify every option key exists, because features silently drop unknown options.
Use when creating branches, commits, pushes, or PRs with plain git. Branch BEFORE committing — never commit directly onto the default branch. Avoids virtual-branch composition bugs where commits silently depend on other applied branches.
Write a CROSS-SURFACE session handoff to a tracked path and push it, so a session on another surface (web, desktop, or CLI) can continue with zero context loss. Use when ending a session whose work must be picked up on a DIFFERENT machine/surface. For same-machine /clear continuity use /clear-prep instead. Invoke as /handoff [next-task].
Use when running parallel-scientist research - ALWAYS follow with an opus verification stage that re-probes load-bearing claims and surfaces gaps. Skipping the verifier almost shipped a wrong recommendation in session 2026-04-07e.
Use when sharing a single `~/.ssh/config` across macOS + Linux - apply OpenSSH `IgnoreUnknown` to tolerate macOS-only directives (`UseKeychain`, `AddKeysToAgent`) on Linux where they would otherwise be fatal.
| id | workflow-tmux-extended-keys |
| name | tmux-extended-keys |
| description | Use when enabling Shift+Enter and other modified-key combinations inside TUIs running under tmux - forward CSI-u sequences. |
| source | conversation |
| triggers | ["shift+enter tmux","shift enter newline","tmux modifier keys","CSI-u","extended-keys","claude code newline tmux"] |
| quality | high |
Modern terminals (Ghostty, iTerm2, WezTerm, Kitty, Alacritty with csi-u,
recent xterm) can distinguish Enter from Shift+Enter, Ctrl+Shift+Tab
from Tab, etc., by emitting CSI-u sequences like ESC [13;2u. tmux
will NOT forward those sequences by default — both ends of the
tmux-in-terminal pipe must opt in. Setting only extended-keys on
is not enough; you also need terminal-features to tell tmux the
outer terminal can handle the encoding on output.
Inside tmux, any TUI (Claude Code, vim, emacs, nvim, helix) sees
Shift+Enter as a plain \r, identical to Enter. In Claude Code
this means Shift+Enter submits the prompt instead of adding a newline.
/terminal-setup inside Claude Code refuses to run under tmux and
points you to the source terminal — but that's misdirection for
Ghostty/iTerm/WezTerm/Kitty which already support the encoding
natively. The fix is at the tmux layer, not the terminal.
$TMUX set, or tmux display-message '#S' returns a session)/terminal-setup errors with
Terminal setup cannot be run from tmuxEdit tmux config (~/.tmux.conf or ~/.config/tmux/tmux.conf,
or the chezmoi source home/dot_tmux.conf.tmpl). Add near the top with
other terminal-* settings:
# Forward CSI-u extended-key sequences so TUIs like Claude Code,
# vim, emacs can distinguish Shift+Enter, Ctrl+Shift+*, etc.
set -s extended-keys on
set -as terminal-features 'xterm*:extkeys'
Reload without killing the session:
tmux source-file ~/.tmux.conf
Verify both flags are live:
tmux show-options -s extended-keys # → extended-keys on
tmux show-options -g terminal-features # → look for "xterm*:extkeys"
tmux display-message -p 'tmux version: #{version}' # must be 3.2+
Test in the target TUI. In Claude Code: type any prompt, press Shift+Enter — should produce a newline without submitting.
extended-keys is a server-level option
(use -s), while terminal-features is global (use -g / -as).
Mixing them up silently fails.-as is additive, which is why the new xterm*:extkeys entry
coexists with any existing xterm*:clipboard:... line rather than
replacing it.extended-keys,
3.3+ for the extkeys terminal-feature name. Verify with
tmux display-message -p '#{version}'.xterm* matches most modern terminals
because they set TERM=xterm-256color or similar. If your terminal
uses a non-xterm TERM (rare — e.g., screen-256color if you set
it manually), adjust the glob.~/.tmux.conf is chezmoi-managed
(e.g., a dot_tmux.conf source in your dotfiles repo), edit the source
file, not the target — otherwise the next chezmoi
apply wipes the change. Then cp or chezmoi apply to sync, then
tmux source-file to reload./terminal-setup is a red herring inside tmux. Don't exit tmux
to run it if your outer terminal is already in the "native support"
list (Ghostty/iTerm2/WezTerm/Kitty/Warp) — the fix is in tmux itself.Before:
set -g default-terminal "tmux-256color"
set -as terminal-overrides ",*:RGB"
After:
set -g default-terminal "tmux-256color"
set -as terminal-overrides ",*:RGB"
# Extended keys: forward CSI-u sequences so Shift+Enter etc. are
# distinguishable in TUIs like Claude Code / vim / emacs.
set -s extended-keys on
set -as terminal-features 'xterm*:extkeys'
Verify:
$ tmux show-options -s extended-keys
extended-keys on
$ tmux show-options -g terminal-features | grep extkeys
terminal-features[3] xterm*:extkeys
/terminal-setup (refuses inside tmux)feedback_omc_phantom_teammatemode.md — another "looks configured
but isn't wired" gotcha in the same Claude Code + tmux stackman tmux → search extended-keys, terminal-features