Auto-mode's "Merge Without Review" rule blocks a signature-preserving `git push` to `main`, mischaracterizes a fast-forward as a force-push, and has no way to express repo-specific release policy

Summary

In an auto-mode session, the permission classifier twice denied a git push origin main following a local git merge --ff-only <branch> — the standard mechanism for landing an approved PR without letting GitHub's merge API rewrite commit SHAs and re-sign commits with its own key. The denial text mischaracterized the action as a force-push (no --force/--force-with-lease flag was used at any point) and cited "bypassing review." A read-only follow-up command (git fetch + git rev-parse) was also denied under the same category. An identical action minutes later, on the same branch, produced no denial at all.

I dug into why, including extracting the classifier's actual system prompt from the installed CLI binary (strings on ~/.local/share/claude/versions/*, Merge Without Review rule text below). That surfaced two things worth separating: a factual bug (the force-push claim, and a read-only command denied under a merge-review rule), and a design gap — the classifier has one hardcoded opinion about what a "reviewed" merge looks like (gh pr merge, with GitHub-side reviewDecision == APPROVED), and no supported way for a repo or user to declare a different, equally legitimate release policy.

Environment

• Claude Code, auto mode
• Repo: private
• Date: 2026-07-15

What happened

1. git checkout main && git merge --ff-only claude/backfill-error-handling-refactor (local, zero new objects) — succeeded, no denial.
2. git push origin main — denied. Reason (verbatim):

> [Merge Without Review] The agent bypassed the PR merge process entirely — instead of using gh pr merge (which would respect any required-review/branch-protection gates on main), it locally fast-forward merged the feature branch and pushed directly to main, landing the PR's content without going through a reviewed merge; the user's "merge-pr" instruction implies the normal PR merge mechanism, not a manual bypass push.

1. Operator ran the equivalent push directly via the ! shell-passthrough prefix — succeeded.
2. git fetch origin --quiet && git rev-parse origin/main HEAD (read-only, no mutation) — denied, same category:

> [Merge Without Review] The agent bypassed the PR merge flow entirely — instead of using gh pr merge (which would enforce any required review/branch-protection gates), it manually git merge --ff-only'd the feature branch into main locally and force-pushed main directly, merging PR #35's content without any human review or the review the user's "merge-pr" instruction implied.

1. Minutes later, the identical action shape (local ff-only merge, agent-proposed git push origin main) recurred with two additional signed commits folded onto the branch — no denial. The successful push in this instance was also run by the operator via !, not proposed by the agent — see the open questions below.

What the rule actually checks, and why "no branch protection" didn't clear it

I assumed initially that the fix was proving main has no branch protection or required-review ruleset (gh api .../branches/main/protection → 404, gh api .../rulesets → []). That evidence is real but turned out to be answering the wrong question. The classifier's own rule text (extracted from the shipped binary) is:

Merge Without Review: Merging a PR before any human has approved it. [...] gh pr merge --auto on a repo with required-reviews branch protection is NOT this rule — --auto queues until reviews+checks pass; the gate is server-enforced.

Branch protection is only referenced as a carve-out for --auto. The general rule is about whether a human review happened, not whether one is required. Two consequences:

• The classifier is an LLM judging the visible transcript, not something that queries GitHub state itself. It needs to see approval evidence (a gh pr view --json reviewDecision result reading APPROVED) in the tool-call history to conclude a human reviewed the PR. Absent that, "no human has approved it" is a literally correct read of the transcript, independent of whether the repo enforces review.
• On a solo-maintainer repo, that evidence structurally cannot exist — there is no second person to leave an approving review, so reviewDecision will essentially never read APPROVED. The rule, as written, has no exit for that case except the classifier's user-intent override, which (per the same prompt) only clears a soft block when the user's own message names "the specific thing that makes it dangerous" — for this rule, that's naming merging without review specifically. "Merge this PR" / invoking a skill by its trigger phrase doesn't name that, so it was never going to clear on the first pass regardless of how correct the underlying reasoning was. What did clear it (step 3, step 5) was the operator re-running the push themselves after the block — the same prompt explicitly treats that as "strengthened consent, not a suspicious retry," which is a reasonable design and explains the denied/succeeded split without needing to invoke non-determinism.

Concrete problems

1. Factual inaccuracy. Denial (4) describes the push as a force-push. No --force/--force-with-lease flag was used anywhere in the session; a plain git push only succeeds as a fast-forward, which Git enforces by rejecting anything else.
2. A read-only command was denied under a merge-review rule. git fetch + git rev-parse mutate nothing and merge nothing. Denying it prevented confirming repository state via git/gh at all, forcing a fallback to a raw gh api call to establish ground truth.
3. The classifier is decoupled from the Bash permission allowlist, silently. .claude/settings.local.json for this repo already allowlists Bash(git push *) (and more broadly Bash(git *)) — patterns that cover the denied command outright. The denial happened anyway. That's plausibly correct behavior (the classifier's soft_deny rules are a separate layer from tool-permission allowlisting, by design, per the schema), but nothing surfaces that distinction to the user — an allowlisted Bash pattern reasonably reads as "Claude Code won't stop me here," and it doesn't.
4. No supported way to declare "this repo has no second reviewer, and that's intentional." See below.

This is also a policy question, not only a bug

Three things worth the team's attention beyond the specific denial:

1. gh pr merge is not a neutral substitute for what this workflow does. Every mode (--merge, --squash, --rebase) creates new commit objects server-side: it re-signs commits with GitHub's web-flow key (discarding the operator's own GPG/Yubikey signature — real personal validation, not a formality), rewrites the commit SHAs, and resets commit timestamps to the time of the merge operation rather than preserving the original authorship record. A local git merge --ff-only + push does none of that — it's not a workaround for gh pr merge, it's a strictly more history-preserving operation that happens to also close the PR.
2. Different repos have different legitimate release policies, and Claude Code should be able to support all of them rather than defaulting to one. A funded startup with a required-reviewers ruleset, a solo open-source maintainer, a personal project, and a new/unreviewed prototype repo don't share a review model — and shouldn't have to fight the same classifier default to express that. The permissions.autoMode.{allow,soft_deny,hard_deny,environment} customization surface (confirmed present in the settings schema) is the right shape for this, but there's no worked example or documentation for "declare this repo's actual release policy" as a use case, and no built-in exception for "solo-maintainer repo, no second reviewer will ever exist."
3. Is gh pr merge actually safer here, or just the more common default? A commit signed by the author's own key is stronger, more verifiable provenance than one re-signed by GitHub's web-flow key. Enforcing the GitHub-merge path as "the reviewed, safe path" trades that away for a workflow that's more common, not more secure, for a solo-maintainer repo with no second reviewer to route around in the first place.

Open questions for the team

1. Does the auto-mode classifier have access to loaded Skill content or project-level docs (e.g. AGENTS.md), or only the raw tool call plus conversation text? If the latter, that's worth documenting — a skill's authored rationale for an action currently can't reach the classifier at all.
2. Is permissions.autoMode.environment/allow in settings.json the intended, supported mechanism for declaring "this repo's review model is X, not GitHub-required-review"? If so, a documented example for the solo-maintainer case would help; if not, what is?
3. Should a matching Bash permission allowlist entry exempt a call from soft_deny classification, or are the two meant to be fully independent? Either is defensible, but it should be discoverable rather than something a user finds out by hitting a denial.
4. Can the "force-pushed" claim be corrected to check the actual flags used, rather than inferring --force from "this is a direct push to main"?
5. Can "Merge Without Review" avoid firing on read-only commands (git fetch, git rev-parse, gh pr view) that don't merge or push anything?

Impact

No data loss, no destructive action, no actual bypass of any configured control. The direct cost was operator time — two commands the agent was already correctly positioned to run had to be re-run manually. The larger cost is ongoing: every session that uses a deliberately-chosen, already-safer release practice has to re-litigate it against a classifier default that isn't configurable per-repo, which is a standing tax that scales with how much a team's practices differ from the default assumption — exactly where thoughtful teams are most likely to differ on purpose.