Summary
anthropics/claude-code-action runs restoreConfigFromBase() on every job, which does git checkout origin/<base> -- CLAUDE.md (CLAUDE.md is one of its SENSITIVE_PATHS) before the agent/reviewer runs, because the PR head is treated as untrusted. It then leaves the restored file unstaged.
Source (anthropics/claude-code-action):
src/github/operations/restore-config.ts:26 — "CLAUDE.md" in SENSITIVE_PATHS:77 restoreConfigFromBase(baseBranch) → :125 git checkout origin/${baseBranch} -- <path> → :133 unstages
Two consequences
1. Recurring false-positive review findings on any PR that edits CLAUDE.md.
For a PR that adds/changes house rules in CLAUDE.md, the restore rewrites the in-CI working copy back to main's version, producing a real M CLAUDE.md (working-tree vs committed HEAD) inside the job only. The reviewer sees git status → M CLAUDE.md and reports it as a "working tree revert / uncommitted change that will be lost" — flagging it as blocking. It is never staged or committed; the branch HEAD is correct. This was hit on PR #843 (the probability-framed Fubini examples), where the same "BLOCKING: CLAUDE.md working tree revert" finding reappeared on consecutive reviews and cannot be cleared by any branch change, because the artifact is regenerated each run. See #843 (comment) for the full trace.
2. @claude CI sessions run against main's CLAUDE.md, not the PR's edited version.
Because the restore happens before the agent runs, any @claude session on a PR that changes the house rules is operating under main's rules, not the rules the PR introduces. New conventions added in a PR don't take effect for @claude until they merge to main.
Options to consider
- Accept as known noise (lowest effort): treat any "CLAUDE.md working tree revert / uncommitted CLAUDE.md" review finding as non-actionable, and note it in the review workflow prompt so the reviewer stops flagging it (e.g., instruct it to ignore a
git status M CLAUDE.md that matches origin/<base>).
- Tell the reviewer about the restore: add a line to
claude-code-review.yml's prompt explaining that CLAUDE.md is restored from base by the action and an in-CI M CLAUDE.md is expected and must not be reported.
- Upstream: ask anthropics/claude-code-action to either skip the restore when the only diff is to a repo's own root
CLAUDE.md, or to surface the restore so the model can distinguish it from a developer's uncommitted change.
Acceptance
Reviews of PRs that edit CLAUDE.md no longer surface a "CLAUDE.md working-tree revert" blocker, and there's a documented understanding that @claude sessions see base-branch house rules until merge.
Summary
anthropics/claude-code-actionrunsrestoreConfigFromBase()on every job, which doesgit checkout origin/<base> -- CLAUDE.md(CLAUDE.md is one of itsSENSITIVE_PATHS) before the agent/reviewer runs, because the PR head is treated as untrusted. It then leaves the restored file unstaged.Source (anthropics/claude-code-action):
src/github/operations/restore-config.ts:26—"CLAUDE.md"inSENSITIVE_PATHS:77restoreConfigFromBase(baseBranch)→:125git checkout origin/${baseBranch} -- <path>→:133unstagesTwo consequences
1. Recurring false-positive review findings on any PR that edits
CLAUDE.md.For a PR that adds/changes house rules in
CLAUDE.md, the restore rewrites the in-CI working copy back tomain's version, producing a realM CLAUDE.md(working-tree vs committed HEAD) inside the job only. The reviewer seesgit status→M CLAUDE.mdand reports it as a "working tree revert / uncommitted change that will be lost" — flagging it as blocking. It is never staged or committed; the branch HEAD is correct. This was hit on PR #843 (the probability-framed Fubini examples), where the same "BLOCKING: CLAUDE.md working tree revert" finding reappeared on consecutive reviews and cannot be cleared by any branch change, because the artifact is regenerated each run. See #843 (comment) for the full trace.2.
@claudeCI sessions run againstmain'sCLAUDE.md, not the PR's edited version.Because the restore happens before the agent runs, any
@claudesession on a PR that changes the house rules is operating undermain's rules, not the rules the PR introduces. New conventions added in a PR don't take effect for@claudeuntil they merge tomain.Options to consider
git statusM CLAUDE.mdthat matchesorigin/<base>).claude-code-review.yml's prompt explaining that CLAUDE.md is restored from base by the action and an in-CIM CLAUDE.mdis expected and must not be reported.CLAUDE.md, or to surface the restore so the model can distinguish it from a developer's uncommitted change.Acceptance
Reviews of PRs that edit
CLAUDE.mdno longer surface a "CLAUDE.md working-tree revert" blocker, and there's a documented understanding that@claudesessions see base-branch house rules until merge.