After detaching, any input would be not worked on ssh

[yanjieee]

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

ssh connection

Expected behavior

the input could be working normally.

Reproduction

1. ssh one remote
2. herdr
3. press ctrl+b q for detaching
4. any input would be not work

Impact

Critical!

Environment

• Herdr version: v0.8.0
• Update channel (stable or preview):
• Operating system:
• Terminal:
• Shell, if relevant:
• Relevant config, if any:

[kangal-bot]

hi @yanjieee, thanks for opening this.

this bug report is missing required environment details: update channel, operating system, terminal. please edit the issue and fill in the missing fields.

shell and relevant config are optional, but they help when they affect the bug.

[faekiva]

Analysis written by glm-5.2, I validated that it only did the error when that iterm2 setting was in place but I didn't validate its claims when it comes to specific issue mentions

Reproducing this on v0.8.0 with a clean prefix+q detach (not an abrupt disconnect), iTerm2 over SSH to a Linux host. Captured the teardown bytes via script; posting because this is the missing piece on every prior related issue.

Repro:

1. From iTerm2 on macOS, ssh into a Linux host, run herdr, attach (any session, even empty).
2. prefix+q to detach cleanly.
3. Type anything at the resulting shell prompt.

Result: input is unusable. Visible in the shell as:

33;1:3u7u5u7;1:3u0u5;1:3u0;1:3u6u5u1u6;1:3u6u5;1:3u1;1:3u6;1:3u1u1;1:3u

These appear to be kitty-keyboard-protocol CSI-u sequences with event-type reporting (;1:3u looks like modifier 1, event-type 3 = release). Event-type reporting requires progressive-enhancement flag 4, which suggests something pushed CSI > 7 u (flags 1+2+4 = disambiguate + event-types + alternate keys) and the corresponding CSI < 1 u pop may not have fired on teardown. Not 100% certain on the byte-level decode of every fragment — the leading digits of some sequences appear to have been consumed by zle's escape sequence matching — but the trailing ;1:3u / Nu pattern is consistent across all the leaked input.

Why this is different from the closed dupes:

herdr's own teardown bytes flow fine right up to Run herdr to reattach and the prompt returns cleanly, so the SSH transport is intact. This doesn't appear to fit the plain-ssh limitation described in #1713 / #1332 / #2158, where an abrupt disconnect prevents the remote from emitting cleanup sequences — here the client has the opportunity to pop kitty-kb mode on a clean prefix+q but the post-detach shell suggests it doesn't reach iTerm2.

Worth flagging: #1332 (v0.7.3, Ghostty) reported that clean teardown did restore kitty-kb correctly — "Quitting herdr cleanly restores everything fine; only abrupt drops leave it stuck." So this on v0.8.0 / iTerm2 is either a regression between v0.7.3 and v0.8.0, or terminal-specific behavior on iTerm2's side of the pop-handshake. I haven't bisected to narrow it down.

The SGR-mouse side of #1332's leak was addressed in #939 (v0.7.2). I don't see evidence the kitty-keyboard side was addressed — the v0.7.2 fix added clear_host_mouse_reporting() in src/client/mod.rs::restore_terminal_state(), per the #1713 thread, but there's no analog of that call for the kitty-kb push. The ordering bug MattJColes flagged in #1713 (clear fires before ratatui::restore() leaves the alt screen, and terminals that restore saved private-mode state on LeaveAlternateScreen re-enable mouse tracking after the clear) and the ctrlc = "3" / missing termination feature gap on SIGHUP he identified there would plausibly affect kitty-kb pop ordering too, if the same code path were emitting it — but I'm reasoning by analogy here, I haven't read herdr's source to confirm.

Confirming datapoint: with iTerm2's Settings → Profiles → Keys → "Allow application to change how keys are reported" unchecked, the leak does not reproduce — I captured a clean teardown log with that setting off and the post-detach shell accepts input normally. iTerm2 ignoring the >1u push (so there's nothing to pop) is consistent with the missing-pop theory, though I can't rule out that the setting also changes some related terminal behavior I'm not aware of.

Recovery: reset or printf '\e[<1u\e[?1000l\e[?1003l\e[?1006l\e[?1049l'; stty sane.

Environment:

• Herdr: 0.8.0 (stable)
• OS (client): macOS 15.6.1 (24G90)
• Terminal: iTerm2 3.6.11, TERM=xterm-256color
• OS (server): Linux (NixOS)
• Shell: zsh + starship
• Reproduces 100% of clean prefix+q detaches

Cross-linking #1713 (root-cause analysis of teardown ordering bug), #1332 (initial byte capture, abrupt), #2158 (clean repro, no bytes), #1226 (Windows variant, intermittent).

[yanjieee]

iTerm2's Settings → Profiles → Keys → "Allow application to change how keys are reported" unchecked

It works, the random code had gone, great solution even through I don't know why.

[faekiva]

It is still a bug in the app so it might be worth reopening!

Basically, herdr sends off a signal that's "hey iterm2, it'd be nice if you changed some keybindings" but not the signal that says, "I'm done with the different keybindings, put them back!"

[yanjieee]

It is still a bug in the app so it might be worth reopening!

Basically, herdr sends off a signal that's "hey iterm2, it'd be nice if you changed some keybindings" but not the signal that says, "I'm done with the different keybindings, put them back!"

I'm sure it's ok when the version was v0.7.5 .

[Seth-Peters]

I'm still having this issue with version 0.8.0

[sazlin]

still occurring with brew install herdr, which installs 0.8.0. Not a great first experience for a new user.

[faekiva]

@ogulcancelik can you reopen this?

[sazlin]

The issue is fixed on main HEAD. The project just needs a new release for 'brew'.