Is this a reproducible bug?
Current behavior
ctrl+s never reaches a pane application on a native Windows client. Claude Code binds
ctrl+s to stashing the current prompt input; inside a Herdr pane the key does nothing.
The same Claude Code build in the same Windows Terminal, started directly from PowerShell
without Herdr, stashes the input as expected.
With HERDR_WINDOWS_INPUT_TRACE=1, two ctrl+s presses produce only release events and
no press event:
windows input trace: client input events events=[Key { code: Char('s'), modifiers: 2,
kind: Release, repeat_count: 1, generated_text: None, source: WindowsConsole { record:
WindowsKeyRecord { key_down: false, repeat_count: 1, virtual_key_code: 83,
virtual_scan_code: 31, unicode: 19, control_key_state: 40 } } }]
Plain s in the same trace produces both a press and a release. ctrl+shift+s behaves
like ctrl+s. ctrl+g, ctrl+b, ctrl+j and unmodified keys are unaffected.
Expected behavior
ctrl+s reaches the pane application as a key press, like other ctrl+letter chords.
Reproduction
- In Windows Terminal, run
herdr.
- In a pane, run
claude, type a few characters into the prompt, press ctrl+s.
Nothing happens; the input stays in the prompt.
- Run
claude directly in a PowerShell tab in the same terminal, type a few characters,
press ctrl+s. The input is stashed.
Optional, to see it at the input layer: start a client with
$env:HERDR_WINDOWS_INPUT_TRACE="1"; herdr, press ctrl+s twice and ctrl+g once, then
compare the emitted events in herdr-client.log.
Impact
ctrl+s is a shortcut I use constantly to park a half-written prompt, change the model,
and restore the text. It is unusable in every Herdr pane on this machine, so I had to
rebind the action to alt+s in Claude Code.
Environment
- Herdr version:
0.9.0, client and server
- Update channel: stable
- Operating system: Windows 11 Pro N, OS build 10.0.26200
- Terminal: Windows Terminal 1.24.11911.0
- Shell: PowerShell 7
- Keyboard layout: US-International
- Relevant config: none, reproduces with default config
Is this a reproducible bug?
Current behavior
ctrl+snever reaches a pane application on a native Windows client. Claude Code bindsctrl+sto stashing the current prompt input; inside a Herdr pane the key does nothing.The same Claude Code build in the same Windows Terminal, started directly from PowerShell
without Herdr, stashes the input as expected.
With
HERDR_WINDOWS_INPUT_TRACE=1, twoctrl+spresses produce only release events andno press event:
Plain
sin the same trace produces both a press and a release.ctrl+shift+sbehaveslike
ctrl+s.ctrl+g,ctrl+b,ctrl+jand unmodified keys are unaffected.Expected behavior
ctrl+sreaches the pane application as a key press, like otherctrl+letter chords.Reproduction
herdr.claude, type a few characters into the prompt, pressctrl+s.Nothing happens; the input stays in the prompt.
claudedirectly in a PowerShell tab in the same terminal, type a few characters,press
ctrl+s. The input is stashed.Optional, to see it at the input layer: start a client with
$env:HERDR_WINDOWS_INPUT_TRACE="1"; herdr, pressctrl+stwice andctrl+gonce, thencompare the emitted events in
herdr-client.log.Impact
ctrl+sis a shortcut I use constantly to park a half-written prompt, change the model,and restore the text. It is unusable in every Herdr pane on this machine, so I had to
rebind the action to
alt+sin Claude Code.Environment
0.9.0, client and server