source-control:babysit-prs: claude[bot] review job commits a fix locally but cannot push it (GitHub App write denied)

[kyle-sexton]

Lane: babysit-prs (safe-tier fix-round worker)

Triggering example: #377, claude[bot] review run 29679358520 against head 473e4c3. The bot correctly diagnosed a real bug in plugins/autonomy/skills/setup/scripts/check-security-binding.mjs (IPv6 ::/96 IPv4-compatible-literal bypass), drafted a fix, and made a local commit 833246e — but that commit never reached origin: "write access to the branch was denied by the GitHub App". The bot left a checklist comment describing the intended fix and fixture plan, but the commit itself is orphaned and unreachable by anyone reading the PR from GitHub's UI.

What happened: A structurally correct, verified fix sat uncommitted-to-remote because the reviewing GitHub App lacks push permission on this branch. The babysit worker had to independently rediscover, re-verify, and re-implement the same fix from scratch (it did, successfully, in a later commit) — but a differently-shaped finding could easily have been missed if the orphaned local commit was the only place the fix's specifics were captured, since the checklist comment described it in prose, not a diff.

What should happen: either the reviewing bot's GitHub App is granted push access to head branches it's asked to review (so a self-diagnosed, self-fixed finding lands automatically), or — if push access is intentionally withheld — the bot's own comment should say explicitly "fix drafted locally but could not be pushed; treat this comment as the complete diff, not a pointer to a commit" so a human or a later worker doesn't have to discover the discrepancy by digging through git cat-file/git log to notice the named commit SHA doesn't actually exist on the remote.

Category: operational

[kyle-sexton]

This was generated by AI during triage.

Triage → needs-human. Bot-identity/permissions cluster with #450. Cross-repo: granting the reviewing claude[bot] GitHub App push access to head branches is a github-iac / GitHub App settings decision, not a plugin change. Alternative if push is intentionally withheld: the bot's own comment must self-declare "fix drafted locally but could not be pushed — treat this comment as the complete diff, not a pointer to commit ", so a later worker/human doesn't have to discover the orphaned-commit discrepancy via git log. Decide the policy. Priority: medium.

[kyle-sexton]

This was generated by AI (needs-human decision-brief pass).

Decision brief (2-minute read)

Problem. When the reviewing claude[bot] GitHub App self-diagnoses and self-fixes a finding, it commits locally but cannot push to the PR head branch ("write access to the branch was denied by the GitHub App"), leaving an orphaned local commit whose SHA appears in a checklist comment but exists nowhere on the remote. A later worker/human must rediscover the discrepancy via git log, and a differently-shaped finding could be lost entirely.

Today. Verified on main: the reviewing bot runs from .github/workflows/claude-review.yml; the App's branch write permission is a GitHub-App / settings property (github-iac territory), not plugin code. The babysit contract already treats permission/identity degradations as things that must surface loudly — the sibling #450 maintainer decision (2026-07-19) rules that a silent bot→personal identity fallback must become a loud, reported finding with cause — but that decision covers the babysit worker's own writes, not the reviewing App's push permission, so #454 is not resolved by it.

Options.

1. RECOMMENDED — Keep push withheld; make the bot's review comment self-declare the un-pushed fix loudly. When the App drafts a fix it cannot push, its comment states explicitly "fix drafted locally but could not be pushed — treat this comment as the complete diff, not a pointer to commit <SHA>," and emits the full diff inline. In-repo (review workflow/prompt), reversible, and consistent with source-control:babysit-prs: safety.md's 'never retry a harness permission denial' rule doesn't match auto-mode classifier's actual (retriable) behavior #455 (permission denials surface loudly) and source-control:babysit-prs: gh-bot.sh bot token generation fails, worker writes fall back to personal identity #450's loud-degrade posture. Rationale for not granting push: a reviewing identity that also authors commits on the branch it reviews muddies the author≠approver separation the feat(source-control): babysit autopilot merge tier — bot-account review + criteria-gated merge #476 merge tier leans on — though note that separation is defined at the merge approver, so this is a judgment tradeoff, not a settled constraint. Cost: the fix still needs a human/worker to apply it (no auto-land).
2. Grant the App push access to head branches it reviews. A self-diagnosed fix lands automatically — removes the re-work entirely, and it is the only option that actually lands the fix without human intervention. github-iac / GitHub-App-settings change (cross-repo, larger blast radius); tradeoff is the SoD tension in Option 1's rationale plus a broader write grant to a bot identity. Reversible, but a settings change rather than a prompt tweak.

Cross-links. #450 (loud bot-identity/permission degrade — same class, decided). #476 (author≠approver merge tier — the SoD consideration weighing against a push grant). #455 (permission denials surface loudly to the human).

Decision asked: Withhold push and require the loud self-declaring comment (Option 1), or grant the review App push access to head branches so its self-fixes land automatically (Option 2)?

[kyle-sexton]

Operator decision (2026-07-19, decision-session final batch; relayed). RESEARCH-GATED GRANT DIRECTION.

In-session verified facts: the review job runs the same Claude GitHub App used for @claude tagging (which can commit/push where granted); the push denial is this repo's own deliberate scope — .github/workflows/claude-review.yml:22 grants the review job contents: read only. So this is a permission-policy choice, not an App limitation.

Operator's ruling, verbatim:

Do the research and make sure this is all accurate, and that we do what is best practice, and in alignment with Anthropic intent

Disposition: the operator leans toward granting the review job what it needs to push its fix commits, gated on a research pass first — current official Anthropic claude-code-action documentation and guidance (how the official action is intended to handle fix commits and what permission set it prescribes), plus GitHub App/workflow permission best practice. Implement per findings: if best practice + Anthropic intent support contents: write for the review job, make the change (ci-workflows reusable workflow + this repo's caller — placement per the cross-repo ownership convention); if research contradicts, fall back to the brief's loud un-pushed-fix self-declaration and bring the fork back to the operator. Merge-approval separation (#476 author≠approver) is unaffected either way.

Re-intake: removing needs-human, adding priority: needs-triage for routing.

[kyle-sexton]

This was generated by AI during triage.

Research-gated disposition: FALL BACK to Option 1 (loud un-pushed-fix self-declaration) + return the grant to the operator on a corrected surface. The research does not contradict letting the bot push fixes in principle — but it does contradict the premise that this is a workflow-permission-scope choice, which was the surface the operator authorized. The contemplated ci-workflows reusable + caller contents: write change would be a no-op for push capability. Details below.

What the research established

1. Anthropic intent — the action is designed to push fixes (supports the grant in principle)

• The official Claude Code GitHub Actions docs prescribe the Claude GitHub App with Contents: Read & write ("to modify repository files") and Pull requests: Read & write ("to create PRs and push changes"): https://code.claude.com/docs/en/github-actions (Manual setup section).
• Anthropic's own worked examples grant the job contents: write when Claude commits: same page, "Using with Amazon Bedrock and Google Cloud" workflow blocks.
• So an autonomous fix-and-push is a first-class, intended capability, not a misuse. Anthropic intent does not counsel against the bot pushing fixes.

2. The effective lever is the GitHub App installation permission — NOT the workflow permissions: block (this is the decisive finding)

This is where the operator's in-session premise ("the push denial is this repo's own deliberate scope — claude-review.yml grants the review job contents: read only") does not survive verification.

• The action does not push with the workflow's auto-minted GITHUB_TOKEN. It exchanges the OIDC token for a GitHub App installation token at https://api.anthropic.com/api/github/github-app-token-exchange. That token's permission set is DEFAULT_PERMISSIONS (contents: write, pull_requests: write, issues: write) merged with the additional_permissions input — sourced from src/github/token.ts and confirmed independent of the workflow job's declared permissions: block. Source-level reference: https://deepwiki.com/anthropics/claude-code-action/5.2-authentication-configuration
• Corroborated by a user report showing permissions: contents: read did not stop the bot pushing, because "it uses the GitHub App's own installation token, which has whatever permissions were granted at App install time": claude-code-action pushes commits when only review was requested; workflow permissions: contents: read does not constrain it anthropics/claude-code-action#1289 (single unresolved report — treated as a flag, then confirmed against the source above, not as standalone authority).
• The open question "can Contents be limited to read-only?" is answered the same way — control lives at the App, labeled area:permissions: contents: write permission required? anthropics/claude-code-action#755

Consequence. The minted token always requests contents: write; what it actually receives is bounded by the GitHub App installation grant, not by our caller/reusable YAML. Adding contents: write to ci-workflows/.github/workflows/claude-review.yml and this repo's caller would therefore not change the bot's push capability. The correct lever is the Claude GitHub App installation's Contents permission — github-iac territory, which is exactly what this issue's original triage comment concluded ("granting push access is a github-iac / GitHub App settings decision, not a plugin change").

3. The grant cannot be "scoped narrowly to the review job" as the disposition assumed

• App installation permissions are per-installation and apply uniformly to every job and every selected repo the installation covers. There is no action input that reduces a job's minted-token scope below DEFAULT_PERMISSIONS (additional_permissions only extends it). So you cannot grant "write to the @claude tag job, read to the review job" through one App — both run under the same installation token capability.
• Granting Contents: write at the installation makes the reviewing identity write-capable across every repo and job the installation touches, not just this review job. That materially widens the blast radius beyond the operator's "scoped narrowly" framing and is the real tradeoff to weigh.
• A genuinely SoD-preserving alternative exists and is already patterned in ci-workflows (the dedicated read-only STANDARDS_REVIEW_APP_* credential): a separate, dedicated review App distinct from the write-capable @claude App. That is a design decision for the operator, not one to make here.

4. GitHub / least-privilege best practice

Least privilege says scope-to-need and prefer read-only for review-only jobs (GitHub Actions permissions guidance; general CI/CD least-privilege posture). A push grant is permissible but should be the narrowest identity that needs it — which, per finding 3, an installation-level grant is not. Merge-approval separation (#476 author≠approver) is genuinely unaffected either way: a fix commit on a PR head branch still requires independent human/CODEOWNERS approval to merge.

Why this routes to the fallback, not the grant

The operator authorized: if research supports it, make the ci-workflows reusable + caller contents: write change; if research contradicts, fall back and bring the fork back. The authorized change is a no-op (finding 2), and the effective change (github-iac App-installation permission, finding 3) is a different, broader surface the operator did not authorize and whose blast radius exceeds the "scoped narrowly" framing. Per the standing instruction to bring the fork back rather than decide unilaterally, the grant returns to the operator.

Disposition

Interim (implement now, reversible, in the shared review surface): Option 1 — loud un-pushed-fix self-declaration.

Spec (cross-repo — placement per the ownership convention, so this comment is the specification, NOT the implementation):

• Where: melodic-software/ci-workflows/.github/workflows/claude-review.yml — the reusable's default inputs.prompt. This repo's caller passes no custom prompt, so the SSOT for review behavior across all consumers is the reusable default. (Implementation is a separate ci-workflows PR.)
• What: append an instruction that when Claude drafts a fix it cannot push, its review comment must state loudly and verbatim: "fix drafted locally but could not be pushed — treat this comment as the complete diff, not a pointer to commit <SHA>" and emit the full diff inline, so a later human/worker applies it without rediscovering an orphaned local commit via git log. Consistent with the loud-degrade posture of source-control:babysit-prs: gh-bot.sh bot token generation fails, worker writes fall back to personal identity #450 and source-control:babysit-prs: safety.md's 'never retry a harness permission denial' rule doesn't match auto-mode classifier's actual (retriable) behavior #455.

Grant question → back to the operator (do not action unilaterally). If the operator still wants the bot to push its fixes despite the research, the decision must be re-specified on the correct surface with the corrected tradeoffs:

1. It is a github-iac / Claude GitHub App installation change (grant Contents: Read & write to the installation covering this repo), not a ci-workflows/caller YAML change.
2. It grants the reviewing identity installation-wide write (every covered repo and job), which cannot be narrowed to this one review job through the official App.
3. The SoD-preserving alternative is a dedicated read-only vs. write-capable App split (the STANDARDS_REVIEW_APP_* pattern), if narrow scoping is desired.
4. Confirm the installation's current Contents scope first — I could not read repos/.../installation (requires App-JWT auth; returned 401). Whoever holds App-admin access should verify whether the current denial is a Read-only installation grant, branch protection, or Anthropic's exchange-service scoping, before any change.

Sources

• https://code.claude.com/docs/en/github-actions
• https://github.com/anthropics/claude-code-action/blob/main/docs/setup.md
• https://github.com/anthropics/claude-code-action/blob/main/docs/security.md
• https://deepwiki.com/anthropics/claude-code-action/5.2-authentication-configuration (source-level: src/github/token.ts DEFAULT_PERMISSIONS + OIDC exchange)
• claude-code-action pushes commits when only review was requested; workflow permissions: contents: read does not constrain it anthropics/claude-code-action#1289
• contents: write permission required? anthropics/claude-code-action#755

Routing status: ready for the Option 1 fallback (a ci-workflows prompt PR). Priority unchanged (medium).