Existing issues matching what you're seeing
Git for Windows version
git version 2.55.0.windows.5
cpu: x86_64
built from commit: 32c4f7689275d233577576630e1ac5b7eb354eb0
sizeof-long: 4
sizeof-size_t: 8
shell-path: D:/git-sdk-64-build-installers/usr/bin/sh
rust: disabled
feature: fsmonitor--daemon
gettext: enabled
libcurl: 8.21.0
OpenSSL: OpenSSL 3.5.7 9 Jun 2026
zlib: 1.3.2
SHA-1: SHA1_DC
SHA-256: SHA256_BLK
default-ref-format: files
default-hash: sha1
Windows version
Windows 11
Windows CPU architecture
x86_64 (64-bit)
Additional Windows version information
Microsoft Windows [Version 10.0.26200.9445]
Options set during installation
Editor Option: VIM
Custom Editor Path:
Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable FSMonitor: Disabled
Other interesting things
uname -a: MINGW64_NT-10.0-26200 NZXT 3.6.10-710e5275.x86_64 2026-07-28 09:32 UTC x86_64 Msys- Bundled ssh:
OpenSSH_10.5p1, OpenSSL 3.5.7 9 Jun 2026 (/usr/bin/ssh)
- Windows Terminal 1.24.11911.0
- The Git Bash profile in Windows Terminal is the one generated by Git for Windows
("source": "Git"); only font/colors/starting directory were changed.
- The remote end is a normal Linux OpenSSH server. Network problems were ruled out: the server
logs Received disconnect from ... port ...:11: disconnected by user, i.e. the client sent a
regular SSH disconnect.
Terminal/shell
Windows Terminal. Reproduces both in the Git Bash profile and when Git's ssh.exe is launched directly from a PowerShell tab in Windows Terminal (no bash involved).
Commands that trigger the issue
1. Open Windows Terminal with the Git Bash profile.
2. `ssh user@some-linux-host` (plain remote bash; no tmux or full-screen program needed).
3. Resize the Windows Terminal window by dragging its border a few times.
It usually happens within a few resizes.
Also reproduces without bash, from a PowerShell tab in Windows Terminal:
& 'C:\Program Files\Git\usr\bin\ssh.exe' user@some-linux-host
# then resize the window
Controls (same host, same day):
| Terminal | ssh | Result |
|---|---|---|
| Windows Terminal, Git Bash profile | Git's `/usr/bin/ssh` | **disconnects** |
| Windows Terminal, PowerShell tab | Git's `ssh.exe` (bash not involved) | **disconnects** |
| Windows Terminal, PowerShell tab | Windows' built-in OpenSSH (`System32\OpenSSH\ssh.exe`) | stays connected (even in the same window while the Git Bash tab disconnected) |
| Git Bash in MinTTY | Git's `/usr/bin/ssh` | stays connected (resizing only stutters) |
Expected behaviour
The ssh session survives a terminal resize, as it does in MinTTY and with Windows' built-in
OpenSSH.
Actual behaviour
ssh prints
poll: No error
Connection to some-linux-host closed.
and exits.
The tail of ssh -vv -E <logfile> shows the window-change requests immediately followed by the
channel being freed, with no EOF/close/exit-status from the server:
debug2: client_check_window_change: changed
debug2: channel 0: request window-change confirm 0
debug2: client_check_window_change: changed
debug2: channel 0: request window-change confirm 0
debug2: client_check_window_change: changed
debug2: channel 0: request window-change confirm 0
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 183896, received 686884 bytes, in 1943.0 seconds
Bytes per second: sent 94.6, received 353.5
debug1: Exit status -1
(poll: No error itself is not written to the -E log; it only appears on the terminal.)
In OpenSSH's clientloop.c (client_wait_until_can_do_something), when ppoll() returns -1 and
errno != EINTR, the client calls quit_message("poll: %s", strerror(errno)) and ends the
session. strerror(0) is "No error", so it looks like ppoll() returns -1 with errno left at 0
when interrupted by the SIGWINCH generated from the Windows console resize (in MinTTY the resize
arrives through the pty and the problem does not occur).
Side effect: if a remote program had enabled mouse tracking, the local terminal is left in
mouse-reporting mode after the disconnect (mouse movement prints 35;41;83M... at the prompt),
because the reset sequence is never received.
Repository
N/A
Existing issues matching what you're seeing
Git for Windows version
Windows version
Windows 11
Windows CPU architecture
x86_64 (64-bit)
Additional Windows version information
Options set during installation
Other interesting things
uname -a:MINGW64_NT-10.0-26200 NZXT 3.6.10-710e5275.x86_64 2026-07-28 09:32 UTC x86_64 MsysOpenSSH_10.5p1, OpenSSL 3.5.7 9 Jun 2026(/usr/bin/ssh)(
"source": "Git"); only font/colors/starting directory were changed.logs
Received disconnect from ... port ...:11: disconnected by user, i.e. the client sent aregular SSH disconnect.
Terminal/shell
Windows Terminal. Reproduces both in the Git Bash profile and when Git's
ssh.exeis launched directly from a PowerShell tab in Windows Terminal (no bash involved).Commands that trigger the issue
Expected behaviour
The ssh session survives a terminal resize, as it does in MinTTY and with Windows' built-in
OpenSSH.
Actual behaviour
ssh prints
and exits.
The tail of
ssh -vv -E <logfile>shows the window-change requests immediately followed by thechannel being freed, with no EOF/close/exit-status from the server:
(
poll: No erroritself is not written to the-Elog; it only appears on the terminal.)In OpenSSH's
clientloop.c(client_wait_until_can_do_something), whenppoll()returns -1 anderrno != EINTR, the client callsquit_message("poll: %s", strerror(errno))and ends thesession.
strerror(0)is "No error", so it looks likeppoll()returns -1 with errno left at 0when interrupted by the SIGWINCH generated from the Windows console resize (in MinTTY the resize
arrives through the pty and the problem does not occur).
Side effect: if a remote program had enabled mouse tracking, the local terminal is left in
mouse-reporting mode after the disconnect (mouse movement prints
35;41;83M...at the prompt),because the reset sequence is never received.
Repository
N/A