Linux/Ghostty: Ctrl+Shift+C reaches pane apps as bare Ctrl+C

[factory-ain3sh]

Is this a reproducible bug?

• I confirm this is a reproducible bug, not a feature request, idea, question, contribution proposal, or direction check.
• I reproduced this bug on the version and environment reported below using the exact steps provided.

Current behavior

Inside a herdr pane, pressing Ctrl+Shift+C reaches the app as plain Ctrl+C. The Shift modifier is lost. The same app running directly in Ghostty (outside herdr) receives Ctrl+Shift+C correctly.

Expected behavior

Ctrl+Shift+C should reach the pane app with the Shift modifier intact, the same as it does in bare Ghostty.

Reproduction

1. On Linux, open Ghostty and start herdr.
2. In a pane, run an app that reports or binds Ctrl+Shift+C (for example Droid, which has a Ctrl+Shift+C shortcut).
3. Press Ctrl+Shift+C. The app gets Ctrl+C.
4. Run the same app directly in Ghostty without herdr and press Ctrl+Shift+C. The app gets Ctrl+Shift+C.

Impact

Apps can't tell Ctrl+Shift+C apart from Ctrl+C. Droid's Ctrl+Shift+C shortcut doesn't work, and the key is treated as an interrupt instead.

Environment

• Herdr version: 0.9.1
• Update channel (stable or preview): stable
• Operating system: CachyOS Linux (kernel 7.2.6)
• Terminal: Ghostty 1.3.1
• Shell, if relevant: zsh
• Relevant config, if any: none

[akbash-bot]

Could you paste a two-line key-byte comparison? This will help distinguish modifier loss from the app not enabling extended keyboard reporting.

Run this once at a shell prompt directly in Ghostty, then once at a shell prompt inside Herdr. After each Press now message, press Ctrl+Shift+C once, then wait eight seconds without typing anything else. Leave text unselected and do not redirect the output.

python3 -c '
import os, select, sys, termios, time, tty
fd = sys.stdin.fileno()
old = termios.tcgetattr(fd)
data = bytearray()
try:
    tty.setraw(fd)
    sys.stdout.write("\x1b[>7uPress now: Ctrl+Shift+C once\r\n")
    sys.stdout.flush()
    end = time.monotonic() + 8
    while time.monotonic() < end:
        if select.select([fd], [], [], max(0, end - time.monotonic()))[0]:
            data.extend(os.read(fd, 1024))
finally:
    sys.stdout.write("\x1b[<u")
    sys.stdout.flush()
    termios.tcsetattr(fd, termios.TCSADRAIN, old)
print("GOT:", data.hex(" ") or "(no bytes)")
'

Paste only the two GOT: lines, marked “outside” and “inside.” Nothing is saved to disk; the output records keys typed during those eight seconds, so avoid typing private text.

[pascalmd]

Measured on herdr 0.9.1, Ghostty 1.3.1 (default config, --config-default-files=false), Pop!_OS 24.04 / COSMIC. Keys were injected via a uinput virtual keyboard (real evdev codes), no text selected. Your probe (CSI >7u):

outside: GOT: 1b 5b 39 39 3a 36 37 3b 31 33 34 75 1b 5b 39 39 3a 36 37 3b 31 33 34 3a 33 75 1b 5b 39 39 3b 31 33 33 75 1b 5b 39 39 3b 31 33 33 3a 33 75
inside:  GOT: 1b 5b 39 39 3a 36 37 3b 36 3a 31 75 1b 5b 39 39 3a 36 37 3b 36 3a 33 75 1b 5b 39 39 3b 35 3a 31 75 1b 5b 39 39 3b 35 3a 33 75

(Ctrl+Shift+C, then Ctrl+C.) With the Kitty protocol enabled, Shift survives (CSI 99:67;6:1u), both locally and with --remote.

The loss happens only when the pane app does not enable the protocol: there bare Ghostty sends CSI 99;6u for Ctrl+Shift+C, while inside herdr the pane receives 03, identical to Ctrl+C. So this likely affects apps without extended keyboard reporting (possibly Droid).

Side note: the key reaches the pane at all because Ghostty's default ctrl+shift+c=copy_to_clipboard:mixed passes it through when Ghostty has no selection, which is always the case when selecting via herdr's mouse handling. keybind = ctrl+shift+c=copy_to_clipboard in Ghostty's config makes it always consume the key.

[kangal-bot]

Implemented on master and queued for the next release. This is not available in a published Herdr release yet.