Git "detected dubious ownership in repository" in CI

By Daniel Zoghalchali·Latchkey

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.

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

Diagnose it: depth, refs, or credentials?

CI checkouts are shallow and detached by default, which breaks anything that needs history or a branch name. Before treating it as a credential problem, confirm what the runner actually fetched.

- run: |
    git rev-parse --is-shallow-repository
    git rev-parse --abbrev-ref HEAD      # prints HEAD when detached
    git log --oneline -3
    git remote -v
    git for-each-ref --format="%(refname)" | head

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.

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.

The checkout options that fix most of this

- uses: actions/checkout@v4
  with:
    fetch-depth: 0        # full history: diffs, tags, git describe
    submodules: recursive # submodules are NOT fetched by default
    persist-credentials: false  # if a later step pushes with its own token

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.

Frequently asked questions

Related guides

References

• Git reference manual
• GitHub Actions documentation