.claude/settings.json appears untracked in every active worktree and is not gitignored, so it gets swept into unrelated PRs.
Evidence
git check-ignore -v .claude/settings.json → not ignored. .gitignore has no .claude entry.
Present, untracked, with byte-identical contents in 4 of 4 active lane worktrees:
/private/tmp/factory-322-claim-hotfix
/private/tmp/wt-351-stall
/private/tmp/wt-fix2-reclaim
/private/tmp/wt-355-candidates
Contents in each:
{ "permissions": { "allow": [ "mcp__relaycast__*" ] } }Four independent worktrees, none of which authored it deliberately — it is written by the harness/tooling, not by anyone making a decision about permissions.
It has already caused a problem
It reached PR #347 — a fleet reclaim fix — as +7/-0, where it would have committed a permissions broadening into the repo inside an unrelated change. I stripped it before merge (dfa67784).
Worse, I initially read it as a lane deliberately working around a permission prompt and said so on the PR. That was wrong and I corrected it, but the correction cost time and was unfair to the author. The next reviewer will make the same mistake, because the file looks like an intentional commit.
Why ignoring is the right fix rather than vigilance
- It regenerates, so removing it once does not help.
- It carries permissions configuration, which is the worst category of file to land accidentally: it is invisible in a PR title, it outlives the task, and
git log gives no natural place to look for when the allow-list changed.
- Every author touching this repo from a lane worktree has to notice and exclude it manually, forever.
Suggested change
Add to .gitignore:
If any .claude/ content is meant to be shared and version-controlled (e.g. checked-in agent definitions), narrow it to .claude/settings.json plus .claude/settings.local.json instead and say which files are intended to be tracked.
Low priority relative to the live dispatch incident, but cheap and it removes a recurring foot-gun.
.claude/settings.jsonappears untracked in every active worktree and is not gitignored, so it gets swept into unrelated PRs.Evidence
git check-ignore -v .claude/settings.json→ not ignored..gitignorehas no.claudeentry.Present, untracked, with byte-identical contents in 4 of 4 active lane worktrees:
Contents in each:
{ "permissions": { "allow": [ "mcp__relaycast__*" ] } }Four independent worktrees, none of which authored it deliberately — it is written by the harness/tooling, not by anyone making a decision about permissions.
It has already caused a problem
It reached PR #347 — a fleet reclaim fix — as
+7/-0, where it would have committed a permissions broadening into the repo inside an unrelated change. I stripped it before merge (dfa67784).Worse, I initially read it as a lane deliberately working around a permission prompt and said so on the PR. That was wrong and I corrected it, but the correction cost time and was unfair to the author. The next reviewer will make the same mistake, because the file looks like an intentional commit.
Why ignoring is the right fix rather than vigilance
git loggives no natural place to look for when the allow-list changed.Suggested change
Add to
.gitignore:If any
.claude/content is meant to be shared and version-controlled (e.g. checked-in agent definitions), narrow it to.claude/settings.jsonplus.claude/settings.local.jsoninstead and say which files are intended to be tracked.Low priority relative to the live dispatch incident, but cheap and it removes a recurring foot-gun.