Skip to content
Latchkey

Git "detected dubious ownership in repository" in CI

Git refuses to operate on a repository whose files are owned by a different user than the one running the command. In containers, a UID mismatch between the checkout owner and the process user triggers this safety check.

What this error means

Any Git command in the checkout fails with fatal: detected dubious ownership in repository at '/path'. It commonly appears when a container step runs as a different user than the one that performed the checkout.

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 owned by a different UID

The repository was checked out as one user (e.g. the runner) but Git runs as another (e.g. root inside a container action). Git’s ownership check then flags the directory as untrusted.

Volume mounted from the host

Mounting the workspace into a container can change the apparent owner relative to the in-container user, producing the same mismatch.

How to fix it

Mark the directory as safe

Tell Git to trust the specific checkout path (or the workspace) for the current user.

Terminal
git config --global --add safe.directory /__w/app/app
# or trust the whole workspace
git config --global --add safe.directory '*'

Align the user that owns and runs the checkout

  1. Run Git as the same user that performed the checkout.
  2. In container steps, chown the workspace to the in-container user, or run the action as the runner user.
  3. On GitHub Actions, prefer actions/checkout, which sets this up correctly for the default runner user.

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 switching users between checkout and later Git steps.

Related guides

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