Swedish layout: å/ä/ö (and likely other Level 1/3 keys) duplicated when typed inside herdr panes under Windows Terminal Preview

[EroUsr99]

Related: #81, #78 (same general area — herdr re-encoding non-ASCII / modified input through libghostty kitty keyboard protocol state). #81 fixed Shift+Enter LF re-encoding; this report covers a different symptom in the same code path.

Current behavior

Typing å, ä, or ö once in a herdr pane on a Swedish keyboard layout produces two of the character. Symptom shows up in every herdr pane — plain bash, vim, Claude Code — so it's not specific to any inner TUI.

It does not happen:

• In the same Windows Terminal Preview window when SSH'ing into the same host without herdr (plain bash session).
• In stable Windows Terminal with or without herdr (stable WT doesn't speak kitty keyboard protocol, so the path that triggers this isn't exercised).

So the duplication is introduced by herdr's keyboard-protocol re-encoding layer, not by Windows Terminal Preview or the SSH transport.

Expected behavior

One keypress on å/ä/ö produces one character in the pane, same as plain SSH outside herdr.

Reproduction

1. Outer terminal: Windows Terminal Preview 1.25.x on Windows 11.
2. SSH from Windows into a Linux host (Ubuntu 24.04).
3. Run herdr on the remote host (v0.6.0).
4. In any pane (plain bash prompt works), type å once.
5. Observe åå in the buffer. Same for ä, ö. ASCII characters are fine. Shifted Swedish characters (Å/Ä/Ö) also duplicate as far as I've tested.

Likely root cause

This looks like the same class of issue called out in pi-mono#3780: when kitty keyboard protocol is enabled with flag 4 (report alternate keys), some terminals emit two events for Level 1 and Level 3 keys — a CSI-u sequence and the raw character byte. The receiving end then inserts both, producing duplication. Shifted characters (e.g. &, $) don't duplicate because the protocol only sends the CSI-u form for those.

å/ä/ö on a Swedish layout are exactly the Level 1 / Level 3 keys that would hit this path.

Given #81 established that herdr re-encodes inner-pane input through libghostty's kitty keyboard state, the most likely fix location is the same layer — either dedupe Level 1/3 events, or request \x1b[>3u (flags 1+2) instead of \x1b[>7u (flags 1+2+4) when forwarding the protocol request to the inner pane.

Why this matters

Stable Windows Terminal doesn't ship kitty keyboard protocol (added in Preview 1.25, March 2026). Users who need Shift+Enter in Claude Code or other modern TUIs must use Preview. Once on Preview, this bug makes Swedish (and almost certainly other Nordic / accented Latin) layouts unusable inside herdr for prose, file names, branch names, anything non-ASCII.

Environment

• herdr: 0.6.0
• Outer terminal: Windows Terminal Preview 1.25.x on Windows 11
• Inner host: Ubuntu 24.04 LTS
• Keyboard: Swedish layout
• Inner pane apps where reproduced: plain bash, Claude Code CLI, vim

Workaround currently in use

None that preserves Shift+Enter. The trade-off is: stable WT (clean Swedish typing, no Shift+Enter) or Preview WT (Shift+Enter, but duplicated å/ä/ö). Holding on Preview because Shift+Enter is non-negotiable for daily Claude Code work.

Happy to capture an xxd byte trace of a single å keypress reaching the pane if that would help narrow the layer — let me know.

[ogulcancelik]

could you try the same ssh target from wezterm on windows with the same swedish layout?

just run herdr, open a plain shell pane, and type å once. also worth trying windows terminal canary if you can.

if wezterm is clean but windows terminal preview duplicates, then this is almost certainly a wt preview kitty keyboard protocol bug rather than herdr. microsoft already has related international-layout kkp fixes in flight.

[ogulcancelik]

related wt issues/prs i’m looking at:

• [TQ: re-check] Strange behavior on the PT keyboard in Windows 11 microsoft/terminal#20146 — very similar duplicate chars with portuguese layout under wt 1.25 kkp
• Fix various KKP encoding issues microsoft/terminal#20052 — wt pr for kkp international-layout/base-key/altgr fixes, linked by a maintainer from the issue above
• Broken input in fish shell microsoft/terminal#19977 — broader wt preview kkp/input-stack regression around altgr/international layouts

[EroUsr99]

Tested WezTerm on Windows, same SSH target, same Swedish layout, herdr 0.6.0 — å/ä/ö type cleanly, one keypress one character. So a second KKP-speaking client on the same outer host does not reproduce.

That isolates the bug to WT Preview's KKP emission, not herdr. The plain-bash control in my original body was a bad comparison — plain bash doesn't negotiate KKP, so WT Preview's buggy code path never ran there. WezTerm is the fair control, and it's clean.

Skipping WT Canary for now — WezTerm-clean is already enough to exonerate herdr. Happy to run Canary too if you want a third datapoint before forwarding upstream.

Matches microsoft/terminal#20146 (Portuguese layout) closely enough that I think this is the same upstream bug with a second Latin layout. I'll comment over there with the Swedish repro.

Suggest closing or relabeling #239 as tracking microsoft/terminal#20146. Your call.

(Aside: Shift+Enter not working in WezTerm is expected — WezTerm doesn't bind it to the KKP sequence Claude Code wants. Separate config issue, not part of this bug.)

[ogulcancelik]

then i'm closing, windows is hard to support, but happy to see wezterm fixes your problem. i assume its much better terminal overall too :)

[DHowett]

i assume its much better terminal overall too

☹️

[ogulcancelik]

i assume its much better terminal overall too

☹️

would happily accept any windows terminal related prs 🙃 (after this big win key encoding refactor tho #2142)