Ghostty + tmux [extended-keys on] + neovim = broken newlines

[kuzemchik]

Issue Description

Problem

After enabling tmux's extended-keys reporting (used by Neovim 0.11+ and
several TUI agents) with a single line:

set -g extended-keys on

multi-line pastes from Ghostty into Neovim through tmux render newlines as
tmux's modified-key escape sequence for Ctrl+J (e.g. \e[27;5;106~) in
the buffer instead of inserting line breaks.

The behavior requires all three of:

• Ghostty as the outer terminal
• tmux with extended-keys on
• An inner program that opts into tmux's extended-keys reporting at startup.
  Neovim 0.11+ does this automatically; a plain shell or cat running in
  the same tmux session does not, and is not affected.

Replacing any one of the three layers changes the behavior:

Setup	Newline in buffer
Ghostty → tmux → Neovim 0.11	\e[27;5;106~ (encoded Ctrl+J)
iTerm2 → tmux → Neovim 0.11 (same tmux/nvim)	\n line break
Ghostty → Neovim 0.11 (no tmux)	\n line break
Ghostty → tmux → Neovim 0.11, extended-keys off	\n line break

Fix: kuzemchik@469c215

Expected Behavior

Newlines are inserted as new lines

Actual Behavior

Newlines are inserted as escape sequence for Ctrl+J (e.g. \e[27;5;106~)

Reproduction Steps

Repro

Minimal tmux config:

# /tmp/repro-tmux.conf
set -g extended-keys on

Steps:

1. tmux -L repro -f /tmp/repro-tmux.conf
2. Inside it: nvim --clean /tmp/out.txt
3. i, ⌘V a multi-line clipboard (e.g.

1
2
3
4

), Esc, :wq
4. xxd /tmp/out.txt shows the modifier-key escape sequence between content
lines instead of 0a:

00000000: 311b 5b32 373b 353b 3130 367e 321b 5b32  1.[27;5;106~2.[2
00000010: 373b 353b 3130 367e 331b 5b32 373b 353b  7;5;106~3.[27;5;
00000020: 3130 367e 341b 5b32 373b 353b 3130 367e  106~4.[27;5;106~
00000030: 0a                                       .

Investigation

tmux was run with full byte logging (tmux -L repro -vvvv -f …) and the
server log was inspected for the actual paste in both Ghostty and iTerm2,
same nvim / tmux session / paste contents.

Ghostty

After tmux has already entered bracketed-paste state from \033[200~, the
paste content arrives in the next read:

keys are 14 (1\n2\n3\n4\n\033[201~)
…
complete key 1 0x31
complete key \n 0x20000000006a
complete key 2 0x32
complete key \n 0x20000000006a
…
writing key 0x31 (1) to %0
input_key: 1
writing key 0x20000000006a (C-j) to %0
input_key_extended: \033[106;5u
…

(Capture taken with extended-keys-format csi-u. The minimal repro uses
the default xterm format, which produces an equivalent sequence in a
different shape — the rest of the analysis is the same.)

tmux parses each byte inside the bracketed-paste region as a keystroke. The
\n (0x0a) bytes are classified as Ctrl+J (0x20000000006a) and, with
extended-keys on, sent through input_key_extended, which writes the
modified-key escape sequence to the pane. Neovim, in paste-verbatim mode,
inserts whatever it receives between \033[200~ and \033[201~ as literal
text — including the encoded sequence.

iTerm2

The same paste arrives at tmux as:

keys are 20 (\033[200~1\r2\r3\r4\r\033[201~)
…
complete key \r 0xd
…
writing key 0xd (Enter) to %0
input_key: \r

iTerm2 uses \r (CR, 0x0d) as the line separator inside bracketed paste
content, not \n. tmux classifies \r as the named "Enter" key
(0xd, no modifier), so it does not go through input_key_extended and
is written to the pane as a raw \r. Neovim inserts it as a line break.

Ghostty Logs

No response

Ghostty Version

Ghostty 1.3.1

Version
  - version: 1.3.1
  - channel: stable
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .none
  - font engine   : .coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

OS Version Information

macOS 26.4.1 (25E253)

(Linux only) Display Server

None

(Linux only) Desktop Environment/Window Manager

No response

Minimal Ghostty Configuration

# empty config is fine

Additional Relevant Configuration

Versions

26.4.1 (Tahoe)
Ghostty `Ghostty 1.3.1`
tmux `3.5a`
Neovim `0.11.5`.

Minimal tmux config

set -g extended-keys on

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[jdorn-eu]

I'm seeing what I think is the same effect when using UW PICO 5.09 (the standard terminal text editor shipped with modern macOS) inside of tmux 3.6b (installed via Homebrew) on Tahoe 26.5.1, but I'm not able to find a tmux config that doesn't display this behavior.