Claude Code in GitHub Actions: A Complete Guide to Automated PR Fixes

Claude Code in GitHub Actions is safest when it is a narrow, reviewable automation, not a privileged bot that edits every pull request. Start with a read-only workflow that produces a bounded report. Add write capability only after the repository has tests, branch protection, scoped permissions, and a maintainer-triggered path for applying a proposed change.

The current Claude Code action documents event-specific access checks, configurable tool restrictions, and cautions for untrusted input. GitHub’s OIDC guidance separately explains how a job can obtain a short-lived identity token when it has the id-token: write permission. Those are useful building blocks, but neither removes the need to decide exactly which event, actor, code, and credential the job trusts. (Anthropic. claude-code-action Security Documentation. GitHub; GitHub Actions OIDC reference)

Start with the lowest-risk job

Use a staged rollout rather than enabling automatic fixes in the first workflow:

Claude Code’s action documentation says the action can be configured through a prompt and claude_args, including an allowed-tools list and a maximum-turns setting. Use those as limits, not as a substitute for GitHub permissions. A review job usually needs read access and no ability to change a branch. A patch job should receive only the write scope needed to create its proposal. (Claude Code custom automations)

Treat pull-request code and comments as untrusted input

This is the hard part of the integration. Pull-request titles, descriptions, comments, issue text, source code, repository instructions, and tool output can all contain text intended to change the agent’s behavior. A workflow that combines untrusted input with base-repository secrets or a write token needs a deliberately designed trust boundary.

The action’s security documentation warns that pull_request_target and workflow_run execute with base-repository secrets. It also explains that checking out a pull request head into the working directory in those contexts makes that checkout the code the action and Claude use. Do not make a broad write-capable agent run on a fork’s head commit simply because the event supplies convenient secrets. (Claude Code action security guidance)

Practical controls include:

1. Prefer a maintainer trigger for any workflow that can write code, comments, or labels.
2. Keep the job permissions: block explicit and minimal; do not rely on repository-wide defaults.
3. Do not allow all bots or all non-write users to initiate a write-capable workflow. The action specifically warns that allowed_bots: '*' can admit prompts controlled by external apps, and that allowed_non_write_users bypasses a primary access check. (Claude Code action security guidance)
4. Allow only the tools and scripts needed for the named task. A lint explanation may need file reads; it should not need shell access, credential files, network access, or deployment commands.
5. Treat every generated patch as a pull request requiring tests and human review, even if the prompt asks for a simple formatting fix.

Choose an authentication path deliberately

The action setup guide supports API-key or OAuth-token configuration through GitHub secrets, and documents workload identity federation as a way to exchange a GitHub Actions OIDC token for a short-lived Anthropic access token. A secret must never be embedded in workflow YAML or echoed to logs. (Claude Code action setup)

If using OIDC or workload identity federation, bind the trust policy to the organization, repository, branch or environment, and workflow identity appropriate to the job. GitHub notes that id-token: write only enables the workflow to request an OIDC token; it does not grant write access to repositories or cloud services. Those permissions must be granted separately and narrowly. (GitHub Actions OIDC reference)

For a small internal repository, a properly scoped secret may be the most straightforward choice. For a high-value or widely reused workflow, short-lived identity can reduce the operational burden of storing and rotating a static credential. Either path still needs log hygiene, revocation, and a response plan if a prompt injection attempt succeeds.

Make the task contract smaller than the repository

Avoid prompts such as “fix this PR” or “make CI green.” They invite broad tool use and make review hard. Instead, supply a small, explicit contract:

Task: inspect the named failing test and the files it directly exercises.
Do not modify workflow files, dependency manifests, credentials, or deployment code.
Run only: npm test -- <named test>.
Return: diagnosis, proposed diff summary, test result, and any missing evidence.
Stop if the change would require a new permission, external network access, or a different directory.

Keep the contract in version control and test it against representative failures. The action’s documented limitations are also a useful guardrail: formal pull-request approval and merging are not tasks to delegate to the action, and shell use should be explicitly allowed rather than assumed. (Claude Code action capabilities and limitations)

Observe before you automate remediation

For the first several runs, collect only a structured report: trigger, actor, commit SHA, files read, tools invoked, proposed changes, test commands, result, token or billing telemetry available to your organization, and the human disposition. Review false positives, unsafe requests, and patches that appeared correct but failed the full suite.

Only then expand from review to patch proposals. If a repeatable failure class has a stable test and a small affected surface, give it its own job with its own tool allowlist. Do not let an agent discover a new category of write operation from an issue comment.

The reliable outcome is modest: a well-contained agent can shorten diagnosis and produce reviewable proposals. It should not become the authority that decides what code runs with secrets, what branch is merged, or what production system changes.