Fixing GNUPGHOME in MSYS2 When GnuPG Looks for Keys in the Wrong Directory

GnuPG fails inside MSYS2 because the shell imports the Windows GNUPGHOME variable at startup and its automatic path translation corrupts it: C:\Users\you\AppData\Roaming\gnupg comes back as /home/you/C:/Users/you/AppData/Roaming/gnupg, a hybrid no program can resolve. The dependable fix is to stop trusting the imported value. Add this line to ~/.bashrc so every MSYS2 shell starts with a correctly converted path:

export GNUPGHOME="$(cygpath -u "$APPDATA")/gnupg"

cygpath -u converts a Windows path into the POSIX form MSYS2 tools expect, so GnuPG finds the same keyring you already use from PowerShell. Restart the terminal (or run source ~/.bashrc) and gpg -k will list your keys.

Why the path turns into a hybrid

MSYS2 emulates a POSIX environment on Windows. When a shell starts, it pulls in the Windows environment — including anything you stored with setx under HKCU\Environment — and tries to translate values that look like paths, so MSYS2 programs see /c/Users/... instead of C:\Users\....

That translation is heuristic, and drive-letter paths inside variable values are a known weak spot. Instead of converting the value, the runtime sometimes prepends the MSYS2 home directory to it, producing the glued string in the error message. Neither side can use the result: the first half is a POSIX path, the second half a Windows path.

PowerShell never hits this because a native Windows build of GnuPG reads the registry value directly as C:\Users\...\gnupg — there is no translation layer in between. The problem exists only inside the MSYS2 environment.

Why setting the variable in the shell did not help

A common trap: running

GNUPGHOME="/c/Users/you/AppData/Roaming/gnupg"

creates a shell variable, which echo can see but child processes cannot. GnuPG is a separate program, so it keeps inheriting the mangled value from the environment and fails exactly as before. The assignment needs export to cross that boundary:

export GNUPGHOME="/c/Users/you/AppData/Roaming/gnupg"

Even then, check the directory name character by character. One transposed letter (say, Roamning instead of Roaming) points GnuPG at a directory that does not exist — and GnuPG may quietly create a fresh, empty keyring there, so your keys appear to vanish rather than raising an obvious error.

The fix: convert the path yourself in ~/.bashrc

Rather than hoping the runtime translation behaves, compute the correct POSIX path explicitly. cygpath ships with MSYS2 and converts between Windows and POSIX path notations; -u produces the Unix style:

# ~/.bashrc
export GNUPGHOME="$(cygpath -u "$APPDATA")/gnupg"

Keep the double quotes: they protect the command if your profile path ever contains spaces. Because this line runs on every shell start, it overrides whatever the Windows side provided, so GnuPG always receives the form the MSYS2 build expects. Apply it with source ~/.bashrc or by opening a new terminal.

Confirm GnuPG sees the right home

1. echo "$GNUPGHOME" should print /c/Users/you/AppData/Roaming/gnupg.
2. ls "$GNUPGHOME" should show keyring files such as pubring.kbx and trustdb.gpg.
3. gpgconf --list-dirs homedir prints the directory GnuPG will actually use — the most direct check, because it shows what the binary resolved rather than what you assumed.
4. gpg -k should now list your public keys.

One keyring or two?

Pointing MSYS2's GnuPG at %APPDATA%\gnupg means PowerShell tools and MSYS2 tools share one set of keys — convenient, but two different GnuPG builds now touch the same files. Avoid running operations in both at the same moment, and expect an occasional version-mismatch warning after upgrading one side.

The alternative is to let MSYS2 keep its own default home (~/.gnupg inside the MSYS2 home). You get clean isolation, at the cost of moving keys between environments with gpg --export and --import when you need them in both places.

MSYS2 also offers MSYS2_ENV_CONV_EXCL, which excludes a variable from automatic translation and leaves it as C:\Users\.... That only helps if the gpg you invoke is a native Windows build that understands drive-letter paths; the cygpath approach works no matter which build sits in $PATH, which makes it the safer default.

Frequently Asked Questions

Do I still need the setx command on the Windows side?

Yes, if your native Windows GnuPG used from PowerShell depends on it. The .bashrc line only affects MSYS2 shells and overrides the imported value there; it does not touch the registry.

Why does the error mention /home/myname?

That is your MSYS2 home directory. The failed translation glued it in front of the unconverted Windows path, which is why the message shows two path styles joined together.

What exactly does cygpath do?

It converts between Windows and POSIX path notations: cygpath -u "C:\Users\me" prints /c/Users/me, and -w converts the other way. It is part of the MSYS2 tool set.

Does the same fix work in Git Bash?

Git Bash uses the same MSYS2 runtime and also ships cygpath, so the identical line works if you run GnuPG from that shell.

How do I check which gpg binary is running?

Run type -a gpg. It lists every match in $PATH, showing whether you are using /usr/bin/gpg from MSYS2 or a native Windows build earlier in the path.

GnuPG still says the directory does not exist — now what?

Confirm the resolved value with gpgconf --list-dirs homedir and list it. If the path is right but empty, your keyring lives elsewhere: search for pubring.kbx under your user profile and either move it or repoint GNUPGHOME at its real location.