On Mon, 8 Jul 2024 at 11:58, Damien Miller <djm@xxxxxxxxxxx> wrote: > ssh already restores all TTY flags on exit: This isn't a TTY flag, it's a terminal mode enabled via an escape sequence, there's actually multiple modes involved (CSI u as in the subject), but xterm also supports "modifyOtherKeys" and Vim for example will pick depending what the terminal reports support for. The closest thing which ssh could do would be the code equivalent of "tput rs2", but OpenSSH isn't likely to link to ncurses just for that, and it seems like for most terminals "rs1" is needed to reset the terminal key handling state (but that clears the screen too, which seems undesirable). It's worth pointing out this also reproduces if you kill -9 vim locally (on a recent Vim and a terminal which supports these key handling modes), i.e. an unexpected exit from Vim can trigger it, so SSH losing a connection where Vim can't run its exit handler is just a manifestation of the problem. As mentioned in the Kitty issue, shells should really gain support for input modes. As a workaround it would be possible to put the key reset sequence in the shell prompt or Zsh is actually programmable enough to handle unexpected CSI key sequences and then turn them off. Example .zshrc snippet: function skip-csi-sequence() { local key while read -sk key && (( $((#key)) < 0x40 || $((#key)) > 0x7E )); do # empty body done if [[ $key = u ]] || [[ $key = "~" ]]; then # Ensure keys are sent normally, zle doesn't expect modifyOtherKeys / CSI u # (This means this key press is discarded, but the next one should be handled.) printf '\e[>4m\e[<u' fi } zle -N skip-csi-sequence bindkey '\e[' skip-csi-sequence Based on that it would probably be possible to write a Zsh extension that does handle CSI u properly, which would fix this for Zsh users at least... David _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev