七台机器上的同一个代理，各守各的规矩：查出 git 看不见的本地配置（中英切换）

Same three-person team, same seven computers. Machines 1–3 develop, 4 and 5 review, 6 validates on Windows, 7 merges. There is exactly one copy of the rules in the repo: AGENTS.md says use pnpm, format with uv run ruff format, never push to main, never skip a failing test; .claude/settings.json holds 5 allow rules and 4 deny rules.

All of this happened on one Thursday. The agent on machine 2 ran git push and rm -rf dist without asking, while the same commands on machine 1 stopped for confirmation every single time. Machine 3's agent installed dependencies with npm, and a package-lock.json showed up in its commit. Machine 4 reviewed a PR with a single line: "no blocking issues". Machine 5 approved a PR with test_sync failing, because "that test is known to be flaky, ignore it". Machine 7's agent merged without running tests. One more thing only surfaced afterwards: machine 2's agent had been connected the whole time to an MCP server pointing at the production database, while the GitHub server the team configured in .mcp.json had never been enabled on that machine at all.

Everyone opened AGENTS.md. The rules were there, and they were correct. Same repo, same agent, yet the agents on the seven machines were following different rules.

My claim: only part of what an agent actually does is decided by files in git. The rest lives in each machine's HOME directory, where neither git nor code review can see it. Every "don't ask again" click adds an allow rule that applies on that machine only. One extra CLAUDE.md in a parent directory, and Claude Code skips AGENTS.md entirely. A different global ruff version means a different formatting diff. Splitting work across seven machines assumes machine 5's review can stand in for machine 4's, and machine 6's validation for machine 7's. Until you've checked these local differences, that assumption doesn't hold.

First, the lab setup. I didn't reproduce any of this on your real seven computers. On one box I built 7 separate HOME directories (m1–m7), cloned the same repo into each, and planted one common kind of local drift per machine. What tells me which rules are really active isn't my reading of the docs. It's Claude Code 2.1.292's own --debug log, which writes Adding N allow rule(s) to destination '...' each time it loads a batch of permission rules. Claude isn't logged in on this box, so claude -p just prints Not logged in. But config loading, permission loading and MCP connections all happen before that point, and the log records them anyway. The cost is that I can't see which instruction files the model actually took in. For that part I can only cite the docs, and I flag it separately below.

Experiment 1: seven HOMEs, and what Claude Code says it loaded

First I ran the real CLI once on each of the seven simulated machines and kept only the permission lines from the log:

== m1          4 deny rule(s) 'projectSettings'
== m2          5 allow rule(s) 'projectSettings'
               4 deny rule(s) 'projectSettings'
               8 allow rule(s) 'localSettings'
== m3 … m7     4 deny rule(s) 'projectSettings'

There are two findings here, and I didn't see the first one coming.

First, the 5 committed allow rules were active on only 1 of the 7 machines. The deny rules loaded everywhere. The allow rules loaded only on m2. The reason is that m2 is the only machine that ever "trusted this folder": someone once opened Claude interactively there, clicked through the trust dialog, and ~/.claude.json recorded hasTrustDialogAccepted: true. The other six only ever run headless jobs like claude -p, so the trust dialog never had a chance to appear and the committed allow rules never took effect. The docs say this plainly: project allow rules, and settings that widen access such as enableAllProjectMcpServers, take effect only after the workspace is trusted; deny and ask apply immediately. It's a security feature that stops a freshly cloned stranger's repo from approving things for you automatically. For a team, the result is one settings.json that runs smoothly on one machine and asks for confirmation at every step on six others, with no error telling you why. And the review and validation machines are exactly the ones that only run headless jobs.

Second, the 8 extra allow rules on m2 were clicked into existence one at a time. Each time someone picks "Yes, and don't ask again", Claude Code writes a rule into .claude/settings.local.json, a file it adds to the global gitignore. The 8 I planted on m2 are git push, rm -rf, curl, npm install, psql, docker compose, WebFetch(domain:*) and chmod. Each one is defensible on its own. Together they give that machine's agent far more power than the team agreed to, and nobody ever reviewed them. MCP makes the point even more clearly:

$ claude mcp list        # m2
github: https://api.githubcopilot.com/mcp/ (HTTP) - ⏸ Pending approval (run `claude` to approve)
pg: npx -y @modelcontextprotocol/server-postgres postgresql://ro@db-prod.internal/app - ✔ Connected

The GitHub server the team committed is pending approval and has never been enabled. The local-scope production-database server that someone added with claude mcp add during a debugging session has been connected all along. Local-scope MCP config lives in ~/.claude.json, keyed by project path, and never shows up in git status.

Experiment 2: my first fingerprint failed

Since the drift lives on the machine, my first idea was to fingerprint each machine: concatenate the bytes of ~/.claude, ~/.claude.json, ~/.codex and the agent-related files in the repo, take a sha256, compare the seven, and call any mismatch drift. It went wrong in three different ways:

m1 7578aa1ef6d8   m3 7578aa1ef6d8   m7 7578aa1ef6d8    ← three "identical" machines
m6 differs from m1: AGENTS.md 923b04… vs 5b2188… (5 extra \r)
after one claude launch on m1: 7578aa1ef6d8 → 36a942ef060c

m3 and m7 hash exactly like the clean m1, yet they are the two worst machines of the seven. m3's clone sits in ~/work/app, and ~/work/CLAUDE.md says "Use npm". m7 has an untracked AGENTS.override.md in the repo that says "skip tests when merging". My script only looked at a fixed set of paths, and neither file was among them. m6 was flagged only because core.autocrlf=true turned the line endings into CRLF; the content hadn't changed. The last line shows the fingerprint isn't even stable: launch Claude once and ~/.claude.json and the debug directory change, and so does the hash.

The root cause is that I compared by "which files", while the agent reads files by its loading rules, and those are not the same thing. These are the loading rules that matter:

• Claude Code walks up from the current directory and, at every level, looks for CLAUDE.md, .claude/CLAUDE.md and CLAUDE.local.md. So a file at any level under HOME can get pulled in.
• Claude Code reads AGENTS.md only when there is no CLAUDE.md in the current directory or any directory above it (the docs say this is supported from 2.1.277). So a parent-dir CLAUDE.md that says "use npm" doesn't just add one rule; it stops the whole AGENTS.md from being read.
• Codex reads only one file per directory, and AGENTS.override.md wins over AGENTS.md. One untracked override file replaces that level's team rules wholesale. Codex also caps the combined project docs at 32 KiB by default and doesn't read past that.
• Auto memory lives in ~/.claude/projects/<path>/memory/. Different path, different memory. The "test_sync is flaky, ignore it" note that machine 5 learned doesn't exist on machine 4.

Version 2: compare by meaning, and state the consequence of each item

The second version, agentfp.py, no longer compares file bytes. It follows the agents' loading rules and lists what can change behavior. Each item goes into a category with its consequence spelled out, for example "committed allow rules are inactive on this clone" or "Claude will read ~/work/CLAUDE.md instead of AGENTS.md". Line endings are normalized before any text is compared. --check compares the result against a reviewed baseline committed in the repo, and exits non-zero on any drift the baseline doesn't list or any tool at the wrong version.

The first run of version 2 produced a false alarm of its own: m4, which only has a user-level ~/.claude/CLAUDE.md, was reported as "parent-dir CLAUDE.md, will skip AGENTS.md". HOME is itself a parent of the repo, and ~/.claude/CLAUDE.md happens to match the pattern "a .claude/CLAUDE.md in a parent directory". The docs exclude exactly this case: the user-level file is loaded, but it doesn't affect whether AGENTS.md is read. After fixing that, and splitting untracked files out from modified tracked files, here are the results:

The toolchain is agent config too

Most people treat tool versions and agent config as separate things. But the agent runs the formatter itself, and whatever diff the formatter produces ends up in the PR. I tested two real repos that pin ruff: format with the repo's pinned version first, then format again with a different version, and count the files that changed:

httpx   pins 0.12.11, run 0.17.1: 17 files, +197/−163 (all Markdown docs)
fastapi pins 0.14.14, run 0.9.0 : 4 files; switch back to 0.14.14: another 4 files (ping-pong)
fastapi pins 0.14.14, run 0.17.1: 120 files, +396/−480 (code blocks under docs/, translations included)
                    back to 0.14.14: 0 files — once changed, it doesn't go back

0.17.1 started formatting Python code blocks inside Markdown. If a machine has the newer ruff on PATH, one helpful "let me format that" from the agent touches a hundred-plus doc files, and the pinned older version can't undo it, because it accepts the new layout as valid. The global ruff on this very box is 0.17.1, outside fastapi's pinned range. That's why agentfp also checks tool versions on PATH, and it's how m3 got blocked.

What open-source repos look like

To see whether this is just our team's problem, I scanned the root directories of 1000 GitHub repos with 3000+ stars and a push in the last month. 491 have at least one kind of agent instruction file, 404 have AGENTS.md, 264 have CLAUDE.md, and 213 have both. Of those 213, 74 use a symlink, 81 import with @AGENTS.md inside CLAUDE.md, 2 are byte-identical copies, 18 contain only a one-line "go read the other file", and 38 maintain two independent rulebooks.

11 of those 38 pairs are more than 80% similar: clearly one file once, edited separately since. firecrawl's CLAUDE.md has one rule its AGENTS.md lacks: "never bypass the knip check with --no-verify". In other words, Codex never sees that rule and Claude does. nx's CLAUDE.md adds two MANDATORY documentation rules and a whole section on code comments, while its AGENTS.md has a section on "testing a local build in other repos" that Claude never sees. Another 5 repos have committed .claude/settings.local.json to git; shadcn-ui/ui is one of them, and its copy holds 6 allow rules someone clicked into existence. At least 7 repos have an AGENTS.md over 32 KiB. browser-use's is 38463 bytes, and the part past the cap is the entire tool reference, starting at # Tools: Available Tools, which Codex doesn't read by default.

CI can catch drift at the repo level. Drift at the machine level can only be checked on each machine.

The fix: one rules file, one setup script, one launcher

Repo level: the shared rules live only in AGENTS.md. CLAUDE.md holds a single line, @AGENTS.md, with any Claude-only additions below it. That way, even if some other CLAUDE.md sits in a parent directory, the repo's rules still get imported instead of skipped. In CI, lint-agent-config.py checks four things: no machine-local file is committed; CLAUDE.md is a symlink to AGENTS.md or imports it; AGENTS.md is no larger than 32 KiB; and the tool version pinned in the baseline matches pyproject.toml. I ran it against a few real repos: firecrawl and nx fail on the two rulebooks, browser-use fails on 38463 bytes, shadcn-ui/ui fails on the committed settings.local.json, and astral-sh/ruff passes.

Machine level: run bootstrap-agent.sh once for every clone on every machine. It does four things: marks the folder as trusted in ~/.claude.json, installs the pinned tools with uv sync, installs the launcher, and runs agentfp --check once.

agent/bootstrap-agent.sh

#!/usr/bin/env bash
# bootstrap-agent.sh - run once per machine per clone (and again after pulling agent/ changes).
# Makes the repo's committed agent config the one that actually applies on this machine.
set -euo pipefail
top=$(git rev-parse --show-toplevel); cd "$top"
# 1) Trust this clone for Claude Code, so committed allow rules apply in headless runs (documented key in ~/.claude.json).
python3 - "$top" <<'PY'
import json, os, sys, pathlib
p = pathlib.Path(os.path.expanduser("~/.claude.json")); top = sys.argv[1]
d = json.loads(p.read_text()) if p.exists() else {}
d.setdefault("projects", {}).setdefault(top, {})["hasTrustDialogAccepted"] = True
tmp = p.with_suffix(".tmp"); tmp.write_text(json.dumps(d, indent=2)); os.replace(tmp, p)
print(f"trusted {top}")
PY
# 2) Pinned toolchain from the repo, not from whatever is on PATH.
uv sync --frozen --group dev >/dev/null 2>&1 || uv sync --group dev
echo "ruff via uv: $(uv run ruff --version)"
# 3) Install the launcher the fleet uses instead of bare `claude`.
mkdir -p ~/.local/bin && install -m 755 agent/agent-claude ~/.local/bin/agent-claude
# 4) Report anything machine-local that would still change behaviour.
command -v ruff >/dev/null && echo "PATH ruff: $(ruff --version)  (must match the pin; uv tool install ruff==<pin> or remove it)"
python3 agent/agentfp.py . --check agent/fleet-baseline.json || {
  echo "bootstrap: drift above must be removed or added to allowed_drift in a reviewed PR"; exit 1; }

Every launch: on machines 4–7, don't run claude directly. Run agent-claude.

agent/agent-claude

#!/usr/bin/env bash
# agent-claude - launch Claude Code from the repo's committed config only.
#   user + local settings files, CLAUDE.local.md and user-level instructions are not read (--setting-sources project);
#   MCP servers come only from the committed .mcp.json (--strict-mcp-config);
#   auto memory is off so per-machine "learned" notes don't steer reviews.
set -euo pipefail
top=$(git rev-parse --show-toplevel)
python3 "$top/agent/agentfp.py" "$top" --check "$top/agent/fleet-baseline.json" >&2 || {
  echo "agent-claude: refusing to start on a drifted machine (see above)" >&2; exit 3; }
export CLAUDE_CODE_DISABLE_AUTO_MEMORY=1
exec claude --setting-sources project --strict-mcp-config --mcp-config "$top/.mcp.json" "$@"

--setting-sources project reads only the settings committed to the repo, not user-level or local settings. --strict-mcp-config connects only the servers in .mcp.json. Auto memory is turned off with an environment variable. Here's the same debug log after the fix:

== m1 trusted, plain claude      5 allow 'projectSettings' · 4 deny 'projectSettings'
== m2 trusted, plain claude      5 allow 'projectSettings' · 4 deny 'projectSettings' · 8 allow 'localSettings'
                                 MCP server "pg": Successfully connected (transport: stdio)
== m2 via agent-claude           5 allow 'projectSettings' · 4 deny 'projectSettings'
                                 (no pg; github: Skipping connection (cached needs-auth))

Look at the second line: trusting the folder on its own fixed nothing on m2. The 8 local allow rules and the production-database server still loaded. What actually keeps them out is the launcher's flags. And the launcher can't help m3, m6 or m7. A parent-dir CLAUDE.md counts as a project source, so --setting-sources project still reads it. Codex's config and override files are out of reach of Claude's flags altogether. For those three machines, the only option is for --check to refuse to start, and for a person to move or delete the file, or change those two config lines. Once all of that was done, all seven exited 0. The full code is in agent-config-kit.tar.gz, including agentfp.py, the baseline, the CI check and the workflow.

Costs, and when not to do this

Don't force it on the dev machines. The people on machines 1–3 work and watch at the same time. Their personal shortcut rules, plugins and memory save real effort, and stripping all of it out would make those machines a pain to use. Enforce only on machines 4–7, whose conclusions other people take as-is. That's also what allowed_drift in the baseline is for: personal preferences can stay on a machine, but the launcher won't let them influence review, validation or merge.

Headless jobs may get stuck. Once the local allow rules are gone, any claude -p job that only ran because of "don't ask again" will stall at a permission prompt and eventually time out. That's actually a good thing: it forces you to commit the rules you really need into settings.json, where they get reviewed once. But expect several of these stalls in the first week.

Auto-trusting carries risk. The trust dialog exists to protect you from malicious repos. Project settings can contain hooks, and once the folder is trusted, committed hooks and allow rules all take effect. In a private three-person repo, that risk is acceptable. If your review machines check out PR branches from outside contributors, don't auto-trust, or at least use CODEOWNERS so that any change to .claude/ or .mcp.json must be reviewed by a person. Otherwise a single PR can quietly hand your review machine new allow rules.

There's a stronger option, but it costs more. Claude Code's managed settings (/etc/claude-code/managed-settings.json on Linux) combined with allowManagedPermissionRulesOnly can block local allow rules at the system level. But that needs root and affects every user and every repo on the machine. It suits company-managed machines, not a computer that runs your own projects as well as the team's. Codex has no switch like --setting-sources, so there I can only detect, not block.

Some things I haven't verified. Claude isn't logged in on this box, so "the launcher doesn't read ~/.claude/CLAUDE.md or CLAUDE.local.md" rests on the docs' description of settingSources; I haven't seen it in the model's context myself. GitHub MCP still shows needs-auth under the launcher, because each machine has to complete its own auth, and the launcher can't solve that. And the specific behaviors in the opening, like "machine 2 pushed code" and "machine 5 approved the PR", are consequences I derived from these configs. I didn't have a real model act them out.

Things you can do tomorrow

1. On every machine, in the repo directory, run cat .claude/settings.local.json; claude mcp list, then check the parent directories for a CLAUDE.md. Most teams will find something with this step alone.
2. Change CLAUDE.md to a single line, @AGENTS.md, so you maintain one rulebook instead of two. If yours have already split, diff them first to see which rules only one agent can read.
3. Add .claude/settings.local.json, CLAUDE.local.md and AGENTS.override.md to .gitignore, and run the lint script in CI.
4. On machines that only run headless jobs, either run the setup script once to trust the folder, or accept that committed allow rules won't apply. Either way, you must know which one it is.
5. On the review, validation and merge machines, run the agent through the launcher. Allowed drift in the baseline changes only by PR.
6. Run formatters and linters only through uv run or pnpm exec, say so in the agent instructions, and uninstall or pin the global copies.

Do all that, and the agents on all seven machines will at least be following the same rules. Whether an agent then sticks to those rules reliably is a separate question, but it starts with all seven machines reading the same rules.