Smart App Control hard-blocks bundled ssh.exe after 2.55.0.windows.5 reinstall (install-options.txt shows "SSH Option: OpenSSH", not ExternalOpenSSH)

[sergak01]

Existing issues matching what you're seeing

• I was not able to find an open or closed issue matching what I'm seeing

This looks related to #6374 and #6373 (same 2.55.0.windows.5 release). Opening separately since the practical failure mode here — Smart App Control hard-blocking the resulting bundled ssh.exe — is a step beyond what those two describe, but please close as duplicate if you'd rather consolidate.

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.9168]

Options set during installation

Editor Option: SublimeText
Custom Editor Path:
Default Branch Option: main
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: WinSSL
CRLF Option: LFOnly
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable FSMonitor: Disabled

Other interesting things

install-options.txt records SSH Option: OpenSSH (bundled) for this install — I don't recall being shown a "Choose SSH executable" page during this reinstall at all, which matches #6374's root-cause analysis (the installer's FileSearch('ssh.exe', GetEnv('PATH')) check misses ssh.exe on the system PATH, so the choice page never appears and it silently defaults to the bundled OpenSSH).

On my machine this goes one step further: Windows Smart App Control (currently in Evaluation mode) hard-blocks the resulting bundled C:\Program Files\Git\usr\bin\ssh.exe outright, so every git operation over an SSH remote fails until worked around. bash.exe also triggers a Smart App Control warning notification, though it still executes.

Workaround: manually setting core.sshCommand = C:/Windows/System32/OpenSSH/ssh.exe (Windows' own, already-trusted OpenSSH) restores normal git push/fetch immediately — which suggests the "external SSH" path the installer was supposed to offer/preserve (per #6374) is exactly the correct fix, not just a stopgap.

Terminal/shell

Git Bash and PowerShell (reproduces in both); also observed via an editor's (Cursor) automatic background git fetch

Commands that trigger the issue

git fetch origin
git push origin <branch>
git ls-remote origin HEAD

All against an SSH remote (e.g. git@github.com:<org>/<repo>.git). Also reproduces from a background/automatic fetch triggered by an editor (Cursor), not just an interactive shell.

Expected behaviour

After reinstalling Git for Windows, git fetch/push/ls-remote over SSH should keep working as before.

Actual behaviour

fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Running the bundled ssh.exe directly shows why:

PS> & "C:\Program Files\Git\usr\bin\ssh.exe" -V
Program 'ssh.exe' failed to run: An Application Control policy has blocked this file

Windows Security raises a toast for this, naming whichever process tried to load ssh.exe as the parent app — I saw two variants:

• "Part of this app has been blocked — Some features of Windows PowerShell may not work because we can't confirm who published ssh.exe that the app tried to load." (manually running ssh.exe from a PowerShell prompt)
• "Part of this app has been blocked — Some features of Git for Windows may not work because we can't confirm who published ssh.exe/bash.exe that the app tried to load." (during an editor's automatic background git fetch — Cursor, not a manual test)

So this isn't just a manual-testing artifact — it also fires during ordinary background git activity.

Repository

Not specific to one repository — reproduces against any SSH remote.