Fix Git error: 'refusing to work with untrusted repository'

What this error means

Git refuses to operate on repositories it considers unsafe. This typically happens when the repository directory (or its .git directory) is owned by a different user than the process running Git, or when permissions suggest the repo could be tampered with.

You may see one of:

• fatal: refusing to work with untrusted repository
• fatal: detected dubious ownership in repository
• fatal: unsafe repository ('/path' is owned by someone else)

This protection was added to prevent code execution via untrusted working directories (e.g., CVE-2022-24765). You must either fix ownership or explicitly mark the path as trusted.

Quickstart (safe choices first)

1. Prefer to fix ownership (recommended):

# Linux/macOS
sudo chown -R "$(id -u):$(id -g)" /path/to/repo
# Then verify
cd /path/to/repo && git status

1. Or explicitly trust the path using safe.directory:

# Trust a single repo for your user
git config --global --add safe.directory /path/to/repo

# For the current repo only (run inside the repo)
git config --add safe.directory .

# CI/containers (system-wide). Use with care.
sudo git config --system --add safe.directory /path/to/repo

Windows (Git Bash or PowerShell):

# Use Windows-style paths
git config --global --add safe.directory C:/path/to/repo

Avoid using the wildcard trust unless you fully understand the risk:

# Not recommended outside isolated CI/containers
sudo git config --system --add safe.directory '*'

Minimal working example (reproduce and fix)

# Reproduce the error by creating a repo as root, then using it as a normal user
sudo rm -rf /tmp/untrusted
sudo mkdir -p /tmp/untrusted
sudo bash -lc 'cd /tmp/untrusted && git init'

# As a normal user
cd /tmp/untrusted
git status  # Expect an "untrusted" / "dubious ownership" error

# Fix 1: Change ownership (recommended)
sudo chown -R "$(id -u):$(id -g)" /tmp/untrusted
git status  # Works now

# OR Fix 2: Trust the directory
# (Reset owner to root to re-trigger, then trust)
sudo chown -R root:root /tmp/untrusted
git config --global --add safe.directory /tmp/untrusted
git status  # Works because the path is now trusted

Why it happens

Common scenarios:

• You cloned or built the repo as root or with sudo.
• The repo sits on a mounted volume from another user (Docker bind mounts, WSL interop, SMB/NFS shares).
• Corporate images change directory ownership to Administrators or a service account.
• In CI, workspaces are created by a bootstrap user; your build runs as another user.

Git checks that the current user owns the repo or that the repo path is listed in safe.directory.

Recommended fixes by environment

• Local development (Linux/macOS): Prefer chown to your user, then continue.
• Windows desktop:
  • If the owner shows as Administrators or SYSTEM, either take ownership or mark the repo trusted:
  • Example: git config --global --add safe.directory C:/dev/my-repo
• WSL:
  • If the repo lives under /mnt/c/..., ownership may look odd. Use safe.directory for that path, or keep your repos under your Linux home (e.g., /home/you) and chown there.
• Docker/containers:
  • Match container UID/GID to the host user when mounting volumes, or trust the workspace path via system safe.directory during the job setup.
• CI runners:
  • Add a bootstrap step that either chowns the workspace or sets safe.directory for the checkout path before running Git.

Step-by-step: choose and apply a fix

1. Identify the repo path and owner:

# Show owner of the repo and its .git directory
stat -c '%U:%G %n' /path/to/repo /path/to/repo/.git 2>/dev/null || ls -ld /path/to/repo

1. If the owner is not your user, pick one:

• Fix ownership: Best security. Use when you control the filesystem.
• Trust via safe.directory: Use when you can’t change ownership (network shares, corporate-managed dirs, CI, containers).

1. Apply the fix (see Quickstart).

2. Verify:

cd /path/to/repo
git status

Pitfalls and safety notes

• Wildcard trust ('*'): Grants trust to all repositories on the machine. Do this only in isolated CI/containers or locked-down build agents.
• Paths must match exactly: On Windows, use forward slashes (C:/path). On macOS with case-sensitive FS, ensure correct casing.
• Symlinks: Trust the real path you use. If you switch between symlinked and real paths, add both to safe.directory.
• Sudo usage: Avoid running Git with sudo in your dev workflow; it creates ownership mismatches.
• Network shares: You may not be able to change ownership. Prefer safe.directory for that share path.

Performance notes

• chown -R on large repos can be slow. If feasible, reclone the repo as the correct user instead of recursively changing ownership.
• Using safe.directory does not modify files and is instantaneous regardless of repo size.
• On network filesystems (SMB/NFS), ownership and stat calls can be slower. Trusting via safe.directory can reduce repeated checks on repo opening but won’t fix underlying network latency.
• Aligning container user IDs with the host (e.g., docker run --user $(id -u):$(id -g)) avoids repeated chown operations across builds.

Tiny FAQ

• Is safe.directory secure?

  • Yes when scoped to specific paths you control. Avoid '*' on shared machines.

• Do I need to trust both the repo root and .git?

  • No. Trust the repository root path. Git handles the internal .git directory.

• Which Git versions have this check?

  • Git 2.35+ introduced stricter ownership checks; modern versions use safe.directory to mark trusted paths.

• Can I fix by changing permissions only (chmod)?

  • No. Ownership matters. Use chown or safe.directory.

• My repo is on C:\ under WSL and shows as root:root. What now?

  • Add the mounted path to safe.directory or move the repo into your WSL home and chown it.