1 files changed, 20 insertions, 5 deletions

diff --git a/config/tmux.conf b/config/tmux.conf
index ceb59e6..9a264bd 100644
--- a/config/tmux.conf
+++ b/config/tmux.conf
@@ -149,11 +149,26 @@ if-shell -b 'test -e ~/.local/share/tmux/color.conf' {
 # swallows Claude Code's desktop notifications and progress updates.
 set -g allow-passthrough on
 
-# Extended key sequences - disabled for Ghostty compatibility
-# Ghostty implements the Kitty keyboard protocol natively, and tmux's extended-keys
-# conflicts with paste operations (causes escape sequences like ^[[27;5;106~ to appear)
-# See: https://github.com/ghostty-org/ghostty/issues/7997
-set -g extended-keys off
+# Modified keys -- Shift+Enter, Ctrl+Enter, Ctrl+J -- reach the apps that ask
+# for them (pi, Neovim, Claude Code) instead of arriving as a plain Enter. All
+# three lines are needed:
+#
+# - extended-keys on: a pane may request xterm modifyOtherKeys. Not `always`,
+#   which forces it on every pane and hands zsh ESC[13;2u for Shift+Enter.
+# - extended-keys-format csi-u: the format pi asks for, and the one it can
+#   decode in the misfire below. tmux 3.5 and later; -q lets 3.4 skip it.
+# - extkeys for Ghostty: tmux asks the outer terminal for modified keys only
+#   when it knows the terminal can send them, and it does not recognise
+#   Ghostty, whose terminfo does not say so either. Without this the two lines
+#   above change nothing there: Shift+Enter still arrives as a bare CR.
+#
+# Panes that ask for nothing, shells included, still get plain bytes, pastes
+# too. One known misfire: in a display-popup tmux re-encodes the newlines of a
+# paste, so an app there that asked for modified keys sees ESC[106;5u in
+# their place. Nothing here opens popups.
+set -g extended-keys on
+set -gq extended-keys-format csi-u
+set -as terminal-features 'xterm-ghostty:extkeys'
 
 # Caps Lock is F20 (hammerspoon). What reaches tmux for it is read as S-F10 and
 # passed on as ESC[21;2~, which Neovim takes for F22 and types out as text. Wispr