Existing issues matching what you're seeing
Git for Windows version
$ git --version --build-options
git version 2.55.0.windows.4
cpu: x86_64
built from commit: a93524749d7806870fd2b4b00a3812da1d6e5f4a
sizeof-long: 4
sizeof-size_t: 8
shell-path: D:/git-sdk-64/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
C:\Program Files\Git\etc\install-options.txt:
Editor Option: Notepad++
Custom Editor Path:
Default Branch Option:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: WinSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Git Pull Behavior Option: FFOnly
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable FSMonitor: Disabled
Other interesting things
No response
Terminal/shell
(git) bash and CMD
Commands that trigger the issue
Setting the `SSH_ASKPASS` environment variable to a command whose path contains spaces.
This can be reproduced on a (git) `bash` with the following sequence of commands:
mkdir -p 'folder with space'
echo 'echo %KEY_PASSPHRASE%' > './folder with space/getPassphrase.bat'
export SSH_ASKPASS='./folder with space/getPassphrase.bat'
export SSH_ASKPASS_REQUIRE=force
export KEY_PASSPHRASE=<my-pw>
eval $(ssh-agent)
ssh-add
This creates a simple bat script that just echos the Passphrase set to the env variable named `KEY_PASSPHRASE`.
But the problem should also surface with other kind of programs with more sophisticated means to obtain a passphrase.
And since under Windows paths like `C:\Program Files\Git` or `C:\Program Files (x86)\Git`, this could be a common issue.
The same issue arises when invoking an equivalent series of commands on the CMD terminal.
Quoting the script path does not solve this problem either since the quotes are then considered part of the ASKPASS command.
Interestingly it works fine, if `SSH_ASKPASS` is set to a bash script (with extension .sh) and the variable access is adapted accordingly.
Expected behaviour
The specified command is executed as expected, either out of the box with the ability to quote the executable path properly (in case arguments should generally be supported).
Actual behaviour
Command "~\folder" not found.
(or similar. On my computer, set up for German it's literally:
Der Befehl "~\folder" ist entweder falsch geschrieben oder konnte nicht gefunden werden.)
Repository
No response
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
No response
Terminal/shell
(git) bash and CMD
Commands that trigger the issue
Expected behaviour
The specified command is executed as expected, either out of the box with the ability to quote the executable path properly (in case arguments should generally be supported).
Actual behaviour
Command "~\folder" not found.(or similar. On my computer, set up for German it's literally:
Der Befehl "~\folder" ist entweder falsch geschrieben oder konnte nicht gefunden werden.)Repository
No response