Yes, a tool that reads configuration from the directory it runs in should be careful with directories it does not own. Git's documented default is to refuse to parse a repository's config, let alone run its hooks, when someone else owns the repository, unless the path is explicitly marked safe.
What the rule says
The safe.directory setting in Git lists directories that are considered safe even if owned by another user. Per the Git documentation, by default Git will refuse to even parse a Git config of a repository owned by someone else, and this setting allows exceptions, for example intentionally shared repositories.
Two details are worth copying.
First, the setting is only respected in protected configuration. The docs say this prevents untrusted repositories from tampering with the value. A repo cannot add itself to its own safe list.
Second, there is a deliberate opt out. Setting the value to an asterisk marks all directories safe. The documentation names it as a way to completely opt out of the check, so it exists, but it is a blunt one.
Why a CLI author should care
Developer tools run in whatever folder the user is in. That folder might be a shared build host, a cloned third-party repository, or a directory a different account wrote into. If your tool loads a config file, a plugin list or a script path from that folder, the folder's owner decides what your tool does.
The danger is a mismatch of trust. The person typing the command trusts your tool. They did not necessarily agree to trust a file someone else left next to their code.
Steps to apply it
- List every file your CLI reads from the working directory, including config, plugin manifests and hook scripts.
- For each one, decide whether it can cause code to run or network calls to be made.
- For those that can, check file ownership before reading. If the owner is not the current user (or an administrator), stop and say why.
- Provide an explicit allow mechanism stored in the user's own configuration, never in the project folder.
- Print a clear error that names the path and the command to allow it.
- Do not offer a single switch that disables the check for everything without a loud warning.
Where it applies and where it does not
This is a defence for one situation: a file on disk owned by a different account. It does not stop a repository you cloned yourself from containing a hostile config. For that, see the guide to trust prompts for untrusted folders.
| Situation | Ownership check helps | Trust prompt helps |
|---|---|---|
| Shared host, other user's folder | Yes | Yes |
| Repo you cloned from a stranger | No | Yes |
| Your own project | Not needed | Not needed |
Quick check
Can a repository add itself to safe.directory?
No. Git only respects the setting in protected configuration, which is how it stops an untrusted repository from tampering with the list.
Is setting it to an asterisk a good fix for the error?
It removes the check entirely. List the specific path instead, unless you have a controlled reason to trust everything.
Safeguard's free scan at gold.safeguard.sh/scan can inventory the dependencies your CLI loads, which is a separate check from file ownership.
Sources
Last reviewed: 19 October 2026.
