Fix Git 'detected dubious ownership' on Windows

You pull up a repo you've been using for months, type git status, and get smacked with this:

fatal: detected dubious ownership in repository at 'C:/Users/you/projects/api'

It usually happens right after a Windows cumulative update (the April 2022 patch and anything since), a domain password reset, a fresh machine setup where you copied the repo from a backup drive, or when IT pushed a new SID mapping through Group Policy. The repo itself is fine. Git just doesn't trust who's touching it anymore.

Why Git is suddenly suspicious

In Git 2.35.2 (April 2022), the maintainers patched CVE-2022-24765. The bug was nasty — on multi-user Windows boxes, a lower-privileged account could plant a .git/config file that ran arbitrary commands as a higher-privileged user. The fix: Git now checks the Windows security identifier (SID) of the folder owner against the SID of the user running git. If they don't match, Git refuses to operate.

Windows updates and domain resets quietly generate new SIDs, or remap old ones. Your files are untouched, but the owner on disk is no longer the same identity Git sees in your session. Git doesn't know the difference between "the drive was reimaged" and "an attacker staged this." So it errors out.

The fix

Open Git Bash, PowerShell, or Command Prompt. Any of them work. You don't need admin.
Tell Git which directories to trust. The safest version is to whitelist only the parent folder that holds your repos:
```
git config --global --add safe.directory C:/Users/you/projects
```
Replace that path with your actual repo root. Forward slashes. No trailing slash. If the repo itself lives at C:/code/app, use C:/code/app, not C:/code, unless you really do want everything under C:/code trusted.
Have multiple repos scattered across drives? Add each one. Or, if you accept the risk (single-user machine, no shared accounts), trust everything:
```
git config --global --add safe.directory "*"
```
I know this is tempting. Don't do it on a shared box, a build server, or anything running CI as a service account. That's exactly the scenario CVE-2022-24765 was written to protect.
Verify it stuck:
```
git config --global --get-all safe.directory
```
You should see every path you added, one per line.
Run git status in the repo. If you still see the error, the path you added doesn't match what Git is checking. Jump to the troubleshooting section.

Where these entries actually live

Git stores the list in your global config file. On Windows that's %USERPROFILE%\.gitconfig. You can edit it by hand if you prefer:

[safe]
    directory = C:/Users/you/projects
    directory = D:/work/client-site

YAML-style indentation isn't required, but the [safe] section header and repeated directory keys are. Misspelling the section as [safety] is a common slip — Git ignores unknown sections silently.

Don't confuse this with takeown or icacls

Every Stack Overflow thread on this error has someone suggesting you run takeown /f . /r or reset ACLs with icacls. Skip it. Rewriting ownership across a repo can break file permissions on WSL mounts, network shares, and OneDrive-synced folders, and it doesn't fix Git's internal SID check anyway. The safe.directory list is the real fix. Permission surgery is the wrong tool.

If it still fails

Path case mismatch. Windows paths are case-insensitive, Git's comparison isn't always. If git rev-parse --show-toplevel returns C:/Users/You/Projects with a capital Y, add that exact casing too.
You added the repo but the error points to the parent. Git walks up looking for a .git folder. If you have a stray .git at C:/Users/you, that's the repo Git cares about. Add that path.
You're in WSL or Git Bash and the SID lookup fails. Mounted Windows drives under /mnt/c/ can confuse the ownership check. Add the POSIX path too: git config --global --add safe.directory /mnt/c/Users/you/projects.
Corporate machine with roaming profiles. Group Policy may overwrite .gitconfig on logon. Check %PROGRAMDATA%\Git\config for a system-level override and coordinate with IT before fighting it.
Still stuck? Run git rev-parse --show-toplevel inside the failing repo and add that literal string to safe.directory. That's the authoritative path Git is complaining about — anything else is a guess.

Once the entry's in there, the error won't come back unless the SID changes again. If your org resets machine SIDs regularly, consider scripting the safe.directory additions into your onboarding docs so nobody loses an hour to this again.