shipped gpg-agent doesnt work for me...

[rodwiddowson]

Existing issues matching what you're seeing

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

Git for Windows version

git version 2.53.0.windows.1
cpu: x86_64
built from commit: a5512bdee37ed7142c233d21e2d347ffc4860ff3
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.18.0
OpenSSL: OpenSSL 3.5.5 27 Jan 2026
zlib: 1.3.1
SHA-1: SHA1_DC
SHA-256: SHA256_BLK

Windows version

Windows 11

Windows CPU architecture

x86_64 (64-bit)

Additional Windows version information

Microsoft Windows [Version 10.0.26200.7623] (11 pro 25H2(

Options set during installation

Editor Option: CustomEditor
Custom Editor Path: C:\Windows\System32\notepad.exe
Default Branch Option: main
Path Option: Cmd
Plink Path: C:\Program Files\PuTTY\plink.exe
SSH Option: Plink
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Rebase
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable FSMonitor: Disabled

Other interesting things

• I can sign files OK using gpg -a -s -b
• I have previously been able to sign by git tag -s -m "foo" foo
• Today the last started failing

error: gpg failed to sign the data:
gpg: can't connect to the gpg-agent: IPC connect call failed
gpg: keydb_search failed: No agent running
gpg: skipped "01483F262A4B3FF0": No agent running
[GNUPG:] INV_SGNR 0 01483F262A4B3FF0
[GNUPG:] FAILURE sign 33554509
gpg: signing failed: No agent running

• I played around by explicitly running the git-shipped gpg-agent (--daemon) but it appeared to exit
• eventually I took a SWAG and renamed gpg.exe in the git distro to git-gpg.exe. My theory was that this would force git to use the gpg elsewhere on the path (which I knew worked)
• I could then create a signed tag.

I did do due diligence with stopping any agents, trying the git gpg-agent by hand. But because I was making this up as I went along I didn't really know what to do. Most notable experiment was to start the agent in one command window and then say (in another)

"c:\Program Files\Git\usr\bin\gpg-agent.exe"
gpg-agent[1452]: no gpg-agent running in this session

I'm sorted now albeit with a kludge, but this might help

Terminal/shell

Cmd and powershell. I also tried bash

Commands that trigger the issue

git tag -s -m "Tag 12.1.6.0" 12.1.6.0

Expected behaviour

git tag -s -m "Tag 12.1.6.0" 12.1.6.0

git show 12.1.6.0
tag 12.1.6.0
Tagger: Rod Widdowson <rdw@steadingsoftware.com>
Date:   Wed Feb 4 14:07:31 2026 +0000

Tag 12.1.6.0
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEESvTYPu3fQ9o8BssxAUg/JipLP/AFAmmDUqMACgkQAUg/JipL
P/Czmg//WpU7YMgwObuj74/zDBvqM2ulISSaOAdFAzKxFWoA49uYhyaJKhtx ```

### Actual behaviour

git tag -s -m "Tag 12.1.6.0" 12.1.6.0

gpg: can't connect to the gpg-agent: IPC connect call failed
gpg: keydb_search failed: No agent running
gpg: skipped "01483F262A4B3FF0": No agent running
gpg: signing failed: No agent running
error: gpg failed to sign the data
error: unable to sign the tag
The tag message has been left in .git/TAG_EDITMSG

### Repository

_No response_

[Magdii222]

Thanks for the detailed report — I’m seeing similar behaviour on my system. In my case, GPG signing also fails with gpg: can't connect to the gpg-agent: IPC connect call failed and Git reports error: gpg failed to sign the data. It looks like the bundled gpg-agent is either not starting correctly or exits immediately. Manually launching the agent in a separate shell results in the same message you described (no gpg-agent running in this session). Using an external GPG installation works as a workaround, but the Git‑for‑Windows agent still appears to be non‑functional. Happy to provide logs or run additional diagnostics if that helps.

[rodwiddowson]

I love the smell of badly trained ais in the morning.

[dscho]

@rodwiddowson do you think you could trace the gpg-agent startup in Process Monitor? I suspect a DLL problem (if an .exe or a .dll lives in a different folder than a .dll it depends on, it is always susceptible to DLL search path problems).

[rodwiddowson]

@dscho will do. It may not be immediate tho