Skip to content
WSLHow-To Published Updated 3 min readViews unavailable

How to Reuse Git Credential Manager Securely Between Windows and WSL

A safe Windows-WSL Git credential setup using GCM's Windows helper, executable interop, helper precedence, path quoting, host scoping, tests, and cleanup.

Git Credential Manager (GCM) can store and broker HTTPS Git credentials through the Windows credential facilities and provider authentication flows. WSL Git can invoke the Windows GCM executable through WSL interoperability, so one protected broker serves both environments without copying tokens into ~/.git-credentials. The configuration must point to the installed executable and avoid a second helper winning first.

Inventory both Git installations

Inside WSL, record Linux Git and current helper configuration:

git --version
git config --show-origin --get-all credential.helper
git config --show-origin --get-regexp '^credential\.' || :

From Windows PowerShell, confirm Git for Windows/GCM installation and version:

where.exe git-credential-manager.exe
git-credential-manager.exe --version
git config --show-origin --get-all credential.helper

Executable locations differ by Git/GCM installer and architecture. Use the path returned on the actual machine and convert it with wslpath rather than copying an old Program Files example.

Configure one explicit helper

If Windows reports C:\Program Files\Git\mingw64\bin\git-credential-manager.exe, its WSL path is commonly /mnt/c/Program Files/Git/mingw64/bin/git-credential-manager.exe. Configure the value as one argument through Git config:

git config --global --unset-all credential.helper 2>/dev/null || :
git config --global credential.helper \
  '/mnt/c/Program Files/Git/mingw64/bin/git-credential-manager.exe'
git config --show-origin --get-all credential.helper

The Git configuration parser and shell quoting each have rules; inspect the stored value and run a test instead of adding backslashes until it “looks escaped.” Newer GCM versions can provide documented configuration commands and WSL guidance; prefer them when available.

Multiple helpers are consulted in order. A plaintext store helper earlier in system/global/repository config can capture credentials even if GCM is also listed. Check all origins, including /etc/gitconfig, ~/.gitconfig, XDG config, includes, and repository-local settings. Remove only obsolete entries you own.

Scope credentials to the real remote

Use the canonical HTTPS host and verify git remote -v. Git normally keys HTTP credentials by scheme/host; some services require path-aware account separation, configured narrowly with credential.<url>.useHttpPath. Enabling useHttpPath globally can create needless repeated prompts.

Do not put a personal access token in the remote URL, environment, command line, or shell history. Let GCM launch the provider’s browser/device authentication. Review the requested account and scopes, use short-lived tokens where supported, and rely on organizational conditional-access policy.

WSL Windows-executable interop must be enabled, and the Windows drive containing GCM must be mounted/executable. If an organization disables interop as a security boundary, install and configure a supported Linux credential helper instead; do not weaken policy to share convenience.

Search for legacy plaintext material before declaring migration complete: ~/.git-credentials, credential-bearing remote URLs, shell history, CI environment files, editor settings, and old helper-specific stores. Revoke any token that was previously written in plaintext, then remove the file through the organization’s secure-handling process. Moving future authentication to GCM does not retroactively invalidate copies already committed, backed up, or synchronized elsewhere.

Verify and revoke end to end

Use a non-destructive git ls-remote https://... against an authorized test repository. Confirm the interactive flow is presented by the expected GCM/provider, the token does not appear in process lists/logs, a second request succeeds without plaintext prompts, and Windows Credential Manager shows an expected entry without exposing its secret.

Test account switch, expired/revoked token, proxy/VPN, WSL distro export/import, Windows password/account change, helper upgrade, and removal. Use GCM’s documented erase/logout command or provider revocation; deleting .gitconfig does not revoke a server token.

The secure result is one known helper, invoked through supported interop, with provider-scoped credentials stored in Windows and a tested revocation path. Shared convenience should reduce secret copies, not hide which component owns them.

Related:

Sources:

Comments