[BUG] /install-github-app review workflow never posts a review: template omits --allowedTools (and uses pull-requests: read)

Summary

The claude-code-review.yml workflow template generated by /install-github-app produces a job that always succeeds and never posts a review. It is missing the --allowedTools declaration that claude-code-action's own example for the same use case includes, so every attempt the agent makes to post its review is denied by the permission layer. The job then exits success, giving a green check that is indistinguishable from one that never ran — while still consuming a full review's worth of tokens.

Version

Claude Code 2.1.224 (current latest; also the version whose embedded template I inspected). The template appears unchanged in recent releases — no CHANGELOG entry touches it.

The generated template

/install-github-app writes this (abridged, exactly as embedded in the CLI binary):

    permissions:
      contents: read
      pull-requests: read
      issues: read
      id-token: write
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 1
      - name: Run Claude Code Review
        uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          plugin_marketplaces: 'https://github.com/anthropics/claude-code.git'
          plugins: 'code-review@claude-code-plugins'
          prompt: '/code-review:code-review ${{ github.repository }}/pull/${{ github.event.pull_request.number }}'

Two problems:

1. No claude_args / --allowedTools. In v1 agent mode the action runs the prompt headless; nothing is posted unless the agent can call a posting tool. With no allow rules, those calls are denied.
2. pull-requests: read. Even once the tools are allowed, the token cannot publish a review or comment.

Compare anthropics/claude-code-action's own examples/pr-review-comprehensive.yml, which does the same job correctly:

    permissions:
      contents: read
      pull-requests: write
      id-token: write
...
          track_progress: true
          claude_args: |
            --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"

The CLI template is missing both the write permission and the tool declaration.

Evidence

A real run of the unmodified template:

"type": "result", "subtype": "success", "is_error": false,
"duration_ms": 957591,
"num_turns": 33,
"total_cost_usd": 9.057688,
"permission_denials_count": 53

followed by Post buffered inline comments → No buffered inline comments, and the job concluding success.

So the agent ran a complete 16-minute review, then had 53 tool calls denied, then reported success and posted nothing. Note these are permission denials, not HTTP 403s — the read-only token is a second, independent defect, but the tool declaration is what silently swallows the review.

(Job log is in a private repository, so I can't link it. Happy to send the full log to a maintainer directly if that helps.)

Reproduction

1. In a fresh repo, run /install-github-app and accept the "Claude Code Review" workflow.
2. Open any PR.
3. The claude-review job turns green. No review, no comment, no inline comments.

Impact

• Silent failure: a green required-looking check that reviewed nothing. Users reasonably read it as "reviewed, no findings."
• Wasted spend: the review is fully computed and then thrown away. ~$9 of equivalent usage per PR in the run above, repeated on every synchronize event.
• Affects every repo onboarded through /install-github-app that accepts the review workflow, not just misconfigured ones — nothing the user does at install time avoids it.

Suggested fix

Bring the CLI's embedded template in line with claude-code-action's own example:

• add claude_args: --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"
• change pull-requests: read → write
• consider track_progress: true so a long review is visible while it runs

A secondary hardening idea: have the action fail (or at least warn loudly) when a review session ends with a nonzero permission_denials_count and nothing posted. The silence is what made this take a while to find.