Matt Daines

Git Credential Manager on Windows Subsystem for Linux (WSL)

I’ve recently been working through the Python → Go backend developer path on boot.dev. The second course on that path is Learn Linux. I’ve used Linux on and off over the years, mostly as a secondary OS.

The problem with that kind of usage is that knowledge decays fast. I drift back to Windows, muscle memory fades, and a few months later I’m relearning things I’ve already “learned” more than once.

To remedy this, I’m going to use Linux more often. On my work device that means using Windows Subsystem for Linux (WSL), but on my desktop it’ll mean booting into Ubuntu. Windows isn’t going away, but I can intentionally choose where I spend most of my time.

I immediately discovered an issue that needed resolving if I was going to use WSL: cloning private Git repositories that require OAuth and MFA.

This post documents the problem and the cleanest solution I found.

What is Git Credential Manager (GCM)?

Git Credential Manager is a helper that integrates Git with the host operating system’s credential store. More importantly, it supports OAuth and MFA flows, which Git itself does not implement. Instead, Git relies on external credential helpers to support modern authentication.

If you’re working with private repositories in Azure DevOps or GitHub, GCM is usually non-optional. In some environments, PATs aren’t even allowed by the organization.

The Problem

I tried to clone a private Azure DevOps repository and got prompted for a username and password.

That’s a red flag.

I knew the repository required OAuth + MFA, so plain Git auth was never going to work. The issue was that GCM wasn’t available inside WSL, even though it was installed on my Windows host.

There are two options:

Both are valid options. I chose the second.

Installing GCM in WSL introduces a second credential store and authentication flow. Reusing the Windows GCM keeps a single credential authority, with WSL Git delegating authentication to the Windows Git Credential Manager.

The Solution: Redirect Windows GCM into WSL

First, confirm that Git and Git Credential Manager are installed on the Windows host:

git --version
# Example: git version 2.52.0.windows.1

git credential-manager --version
# Example: 2.6.1+786ab03440ddc82e807a97c0e540f5247e44cec6

If either command fails, install (or reinstall) Git for Windows from https://git-scm.com or via Winget:

winget install --id Git.Git -e --source winget

Next, find the actual GCM executable path. I’ve noticed that this differs between x64 and ARM64 installs:

(Get-ChildItem -Recurse -Filter git-credential-manager.exe -LiteralPath "C:\Program Files\Git\")[0].FullName

Typical results:

Now switch to your WSL instance and configure Git to use that executable.

# x64
git config --global credential.helper "/mnt/c/Program\ Files/Git/mingw64/bin/git-credential-manager.exe"

# ARM64
git config --global credential.helper "/mnt/c/Program\ Files/Git/clangarm64/bin/git-credential-manager.exe"

WSL mounts the Windows C: drive at /mnt/c, allowing Git in WSL to invoke the Windows-hosted GCM directly.

You can verify the config with:

git config --global --get credential.helper

Result

From WSL, run git clone against a private repository.

If you’ve authenticated before on Windows, the clone should succeed silently. If not, GCM will trigger the standard OAuth/MFA flow.

Either way, credentials are stored once in Windows Credential Manager and reused by Git running in WSL.

The goal here wasn’t just to fix Git, but to remove an obstacle so I could continue learning Linux. Progress rarely goes straight from A to C, and fewer unnecessary obstacles make the detours easier to deal with.