Git “detected dubious ownership”: the fix, sized right
The error means the repo's owner isn't the user running git: a real protection, not a nuisance. The one-line fix, the wildcard to avoid, and when the mismatch is the actual bug.
Git’s detected dubious ownership error means the repository’s files are owned by a different user than the one running git, and git refused to touch it: by default “Git only allows you to access repositories owned by yourself.” The error itself prints the fix: a one-line safe.directory exception that marks that repository as deliberately shared. Before pasting it, though, it’s worth asking why the owners differ. Sometimes the mismatch is the actual problem.
fatal: detected dubious ownership in repository at '/srv/repo'
git config --global --add safe.directory /srv/repoWhy git checks ownership at all
The check arrived in git 2.35.2 as the fix for CVE-2022-24765, and the attack it stops is sneakier than it sounds: on a shared machine, someone plants a .git directory in a location above yours (the advisory’s examples include C:\.git and mounted network drives). Git configuration can specify programs to run (as GitHub’s security post notes, settings like core.fsmonitor “cause Git to execute arbitrary commands”), so merely having a git-aware shell prompt run git status near a hostile repo could execute an attacker’s code. The ownership rule closes that door: a repo owned by someone else isn’t even parsed until you vouch for it.
The fix, sized correctly
safe.directory is a per-path allowlist, and the right entry is the narrowest one: the specific repository you know and trust. The tempting wide version (the same command with "*" as the path) is documented as a complete opt-out: it treats every repository on the machine as safe, which is exactly the protection CVE-2022-24765 added, switched off. On a single-user laptop that trade might be defensible; on any shared or server machine it isn’t. Add paths one at a time, and let each one be a small deliberate decision.
When the error is a hint, not an obstacle
On an agent server this error usually means something true: you’re acting as the wrong user. An OpenClaw workspace is a git repository owned by the agent’s runtime user. Inspect it as root and git objects, correctly, that root isn’t the owner. The clean response isn’t an exception for root, it’s doing the work as the owner: sudo -u <owner> git -C /path status keeps every file the right user’s, where a root-side safe.directory entry normalizes root touching agent files (and root-created files in a user’s repo cause the next mystery; see why agents shouldn’t run as root for the same principle from the other side). The other habitat is containers and mounted volumes, where a repo written by one uid is read by another; there, aligning the uids, or scoping safe.directory to the one mounted path, is the right fix.
The two-line diagnosis
ls -ld /path/to/repo/.git # who owns it?
whoami # who am I?If those two answers should match, fix the identity you’re working as (or the volume’s uid mapping). If they legitimately differ (a deploy user’s repo you administer, a repo your agent works in that you audit from outside), then safe.directory with the explicit path is precisely the tool git gave you, used as designed.