Claude Code

Verified against Claude Code · 2026-07-23

Wire GitHub's claude-code-action without granting it more authority than the job needs

A workflow-authoring prompt for anthropics/claude-code-action that scopes the triggering condition, the GITHUB_TOKEN permissions block, and the allowed-tools config to exactly what the automated job does, since an unattended GitHub Actions run has no ask step to fall back on if a permission is too broad.

Claude CodeGitHub Actions5 fillable variables

The prompt

Ready to copy — highlighted parts are example details you can swap.

Write a GitHub Actions workflow YAML using anthropics/claude-code-action for this specific automated job, scoped as narrowly as the job allows — an unattended run in CI has no human present to answer a permission prompt, so anything left too broad here executes silently rather than pausing for confirmation.

WHAT SHOULD TRIGGER THIS WORKFLOW
An issue_comment or pull_request_review_comment containing the exact string @claude, on issues and PRs only, not on every push.

WHAT THIS WORKFLOW IS ACTUALLY RESPONSIBLE FOR
Read the PR diff and post a structured review comment back to the PR; it must never push a commit or modify a file directly.

GITHUB PERMISSIONS THIS JOB NEEDS
contents: read, pull-requests: write (to post the review comment), nothing else.

SECRETS THIS JOB REQUIRES
ANTHROPIC_API_KEY, stored as a repository secret, not an organization-wide one.

RUNNER ENVIRONMENT
ubuntu-latest, no dependency installation needed since this job only reads the diff via the GitHub API.

PRODUCE
1. The trigger block, matching An issue_comment or pull_request_review_comment containing the exact string @claude, on issues and PRs only, not on every push. precisely — if this should only fire on an @claude mention inside an issue or pull-request comment, scope it to that event and that exact string, not a broader event type that would also fire on unrelated activity and consume budget or take action nobody asked for.
2. The permissions block for GITHUB_TOKEN, granting only what contents: read, pull-requests: write (to post the review comment), nothing else. actually requires — contents: read if the job only reads code, pull-requests: write only if it must actually leave a comment or push a commit, never permissions: write-all as a default to avoid enumerating the real list.
3. The claude-code-action step itself, with allowed-tools scoped to Read the PR diff and post a structured review comment back to the PR; it must never push a commit or modify a file directly. — a job whose responsibility is reviewing a diff and posting a comment should not carry Bash access broad enough to also modify files, even though the underlying action supports it, because a review job that can silently also edit code is no longer just a review job.
4. The secrets reference for ANTHROPIC_API_KEY, stored as a repository secret, not an organization-wide one., pulled from repository or organization secrets, never hardcoded in the workflow file, and a note on which specific secret this job actually needs versus which secrets exist in this repository more broadly that it should not have access to.

CONSTRAINTS
- If Read the PR diff and post a structured review comment back to the PR; it must never push a commit or modify a file directly. indicates this job should never push a commit or modify a file directly, do not grant contents: write or Edit/Write tool access even if a future version of this job might want it — scope for what this job does today, and revisit the scope explicitly when the job's responsibility actually changes, rather than provisioning ahead of need.
- State what happens if An issue_comment or pull_request_review_comment containing the exact string @claude, on issues and PRs only, not on every push. fires on a pull request from a fork — a workflow with write permissions triggered by an external, untrusted contributor's PR is a materially different risk than the same workflow triggered only by a maintainer's own comment, and this distinction needs to be addressed explicitly, not left to whatever GitHub's default behavior happens to be.
- Confirm ubuntu-latest, no dependency installation needed since this job only reads the diff via the GitHub API. matches what this job actually needs — a job that only calls the GitHub API and posts a comment does not need the same runner image as one that installs dependencies and runs a full build.

OUTPUT
The complete workflow YAML, followed by one paragraph stating exactly what this workflow can and cannot do to this repository, written for a reviewer approving it for the first time.

Customize

Optional — swap in your own details for the highlighted parts above.

Why this works

A GitHub Actions workflow using claude-code-action is functionally an unattended agent with whatever GITHUB_TOKEN permissions the workflow file grants it, and unlike an interactive Claude Code session, there is no ask-permission fallback available if a scope turns out to be broader than the job needs — a workflow permissions block is enforced by GitHub's own runtime before the job even starts, so an overly broad grant is not a risk that might materialize under the wrong prompt, it is a capability the job has for the entire duration of every run regardless of what the underlying task actually required that particular time. Scoping allowed-tools to the job's actual responsibility, rather than the full set the action supports, matters for the same reason a subagent's tool grant matters: a review job that can also silently edit files has quietly become something other than a review job, and the distinction only shows up the one time the model's own reasoning, under whatever prompt triggered that run, decides an edit is warranted — at which point the workflow's permissions determine whether that decision can actually take effect, not the job's stated purpose in a README nobody re-reads before every run. The fork-PR distinction is the single most consequential branch in this entire setup and is easy to omit if a workflow is only ever tested against a maintainer's own comments: GitHub's default behavior around secrets and token permissions for workflows triggered by fork pull requests exists specifically because an external contributor's PR is untrusted code by definition, and a workflow with write permissions that fires on that trigger without accounting for it is a substantially different risk than the identical YAML triggered only by a trusted maintainer's comment, even though the workflow file itself might look nearly the same either way. Referencing secrets by name from repository secrets rather than hardcoding anything is the same discipline that applies to .mcp.json, applied to a context where the consequence of getting it wrong is worse — a workflow file lives in version control and is visible to anyone with read access to the repository, including, for a public repository, anyone on the internet.

Verified against

Claude Code Sonnet 4.6 · 2026-07-23

Changelog

  • 2026-07-23 Initial publish, verified against anthropics/claude-code-action in GitHub Actions (Sonnet 4.6).

Building this for real?

This is a free starting point. If you'd rather have custom software built and running for your business, that's Scult's day job.

EXPLORE CUSTOM SOFTWARE
All Claude Code prompts

Check your AI visibility

One URL in, a 0–100 score and the exact fixes out.

RUN THE CHECK

Browse all the tools

15 tools across six categories
13 of them never send your data anywhere

Free · No signup · No trial clock

SEE THE DIRECTORY