Skip to content
Latchkey

Git "detected dubious ownership" - Add safe.directory in CI

When a checkout is owned by a different user than the one running Git, Git blocks it and tells you to add a safe.directory exception. This page is the focused recipe for setting that config correctly in CI.

What this error means

Git refuses to operate on the checkout and prints the safe.directory instruction. You need to add the exception so subsequent Git steps run - typically in container jobs or when a cache restored the repo as a different UID.

git output
fatal: detected dubious ownership in repository at '/__w/app/app'
To add an exception for this directory, call:
    git config --global --add safe.directory /__w/app/app

Common causes

Checkout UID differs from the Git process UID

A container step running as root over a workspace checked out by the runner user triggers Git’s ownership safety check.

Restored cache/artifact owned by another user

A cache or artifact unpacked the repo with a different owner, so the Git process now sees an untrusted directory.

How to fix it

Add the specific path as a safe directory

Trust the exact checkout path for the current user. Prefer the specific path over a wildcard.

Terminal
git config --global --add safe.directory /__w/app/app

Trust the workspace on an isolated runner

On an ephemeral, single-tenant runner you can trust all paths, but only there.

Terminal
git config --global --add safe.directory '*'

Set it via env for container steps

When you cannot run a config step first, pass the exception through the environment.

Terminal
export GIT_CONFIG_COUNT=1
export GIT_CONFIG_KEY_0=safe.directory
export GIT_CONFIG_VALUE_0=/__w/app/app

How to prevent it

  • Keep the checkout owner and the Git process user consistent.
  • Add safe.directory for the workspace in container-based jobs.
  • Avoid restoring caches/artifacts as a different UID into the repo path.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →