[idea] Preserve native Windows key records through pane input routing

[Pimpmuckl]

idea / problem

On Windows, Herdr receives the full native information for each physical key, but reduces it to a cross-platform key and modifiers before sending it through the rest of the application. When that input eventually reaches a native Windows application through ConPTY, Herdr has to reconstruct the original Windows key from less information than it started with.

That reconstruction is not always accurate. Escape and Shift+Enter have already needed narrow Windows-specific fixes, while, for example, Ctrl+Space can arrive as Ctrl+Shift+2 instead of the physical Space key. These look like separate key bugs, but they share the same underlying cause: Herdr discards the original Windows key information and later tries to guess it again.

The investigation and reproductions are tracked in #1929.

requested change

Keep the original Windows key record alongside Herdr's normal cross-platform interpretation while the key passes through the existing input and keybinding flow.

Herdr would continue using the cross-platform interpretation for its own keybindings. If a keybinding consumes the input, nothing is forwarded. Otherwise, when the destination is a normal Windows ConPTY pane, Herdr can forward the original record instead of reconstructing it. Kitty keyboard, modifyOtherKeys, non-Windows panes, remote Windows-to-Unix input, and input created through the API would continue using the existing behavior.

This should remain one input-routing path, with the native Windows record carried as additional information rather than introducing a separate Windows routing system or adding more key-specific mappings.

This change would only cover physical keys received by the Windows client. The pane send-text Escape behavior from #1929 and Ctrl+Break are separate problems because they enter Herdr through different paths and should be handled separately.

why you want this

Native Windows applications inside Herdr should receive the key the user actually pressed rather than Herdr's best reconstruction of it.

Fixing the point where that information is lost should address this class of ConPTY input problems once, instead of adding another special case whenever a modified key is found to behave differently. It also keeps the change Windows-specific and avoids changing key handling on Linux, macOS, or applications that already negotiate a richer keyboard protocol.

This should also enable a revert of the band-aid input-PRs for windows input wiring which seems like a good nice to have.

[Pimpmuckl]

So I was curious and went ahead and tested the dogfood implementation from Pimpmuckl#7, including a local build with the current ConPTY fallbacks from #1909 for Shift+Enter and Pimpmuckl/herdr#6 for Escape removed.

Results:

• physical Escape works in native Windows Codex without the Escape fallback (good)
• physical Shift+Enter works without the Shift+Enter fallback (also good)
• pane send-keys <pane> esc t e s t arrives as Escape followed by test (also good!)
• pane send-keys <pane> shift+enter produces no key without the Shift+Enter fallback (not good)
• pane send-text <pane> "$([char]27)test" still arrives at a native ReadKey probe as Alt+T, E, S, T; in Codex this produced est on each attempt (also not good)

This suggests a clearer boundary:

• physical input should use the original native Windows record
• pane send-keys is semantic key injection and should preserve the requested key where possible; Shift+Enter still needs its targeted Win32 fallback because legacy VT cannot represent it faithfully
• pane send-text is a raw byte stream rather than key injection, so the Escape-plus-text behavior from Escape can still consume the following key in native Windows panes #1929 remains a separate problem

This leaves a fairly clean shape for the implementation: Native-record transport handles physical Windows input, while targeted fallbacks remain available for semantic input created through pane send-keys when legacy VT cannot represent the requested key.

The Escape-specific ConPTY reconstruction should therefore become redundant as well as similar class of issues that might pop up in the future.

The Shift+Enter fallback and the Kitty keyboard / modifyOtherKeys negotiation added in #1909 should remain, as should 2a20e90, which distinguishes physical Escape from raw VT framing using its scan code. This would leave pane send-text and Ctrl+Break for separate fixes.

[ogulcancelik]

fixed via #2142 now i think?

[Pimpmuckl]

Yep. Physical Windows input is finished. I tried a few more edge cases and had codex go nuts on trying to break it, seems fine.

Now the remaining scope question for you just comes down to how well pane send-keys should be supported:

Escape and Shift+Enter work after the earlier patches and #2142, but if every combination should be supported then there might need to be a follow up with a general name-key-to-windows-record PR.

Given that Windows is still in preview, I'd say we're good. Thanks for all your effort!