Claude Code GitHub Actions Automation: Safe PR Review Setup

Claude Code GitHub Actions Automation: Safe PR Review Setup

To run Claude Code in GitHub Actions, install Anthropic's official action in your repository, store the API key as a secret, give the workflow read access to code and write access only to pull request comments, and trigger a review on every PR. What separates a safe pilot from a risk is limiting permissions, tools and triggers before you switch it on. This guide follows the official documentation and marks clearly what is documented, what is implementation practice, and what is a hypothesis to validate in your own repository.

Key takeaways

• The official integration runs Claude Code as a workflow step and comments on the pull request. It does not replace a person's approval.
• The API key belongs in GitHub Secrets, never in the workflow file and never in variables printed to the log.
• The workflow permissions block and the list of tools the agent may use are the two main controls. Start with read-only.
• PR content is untrusted input. Treat PR text, issues and files as a possible prompt injection attempt.
• Start with one repository and one flow, define a success metric beforehand, and decide after the pilot whether to expand, adjust or stop.

What does Claude Code do inside a pipeline?

In interactive use, Claude Code runs in a person's terminal. That person sees each step and approves actions. In CI, it runs with nobody watching in real time. That difference changes everything: what used to be a permission prompt on screen becomes a configuration you have to decide in advance.

The official documentation describes the GitHub Actions integration through the claude-code-action. It supports two main uses. The first is responding to mentions, when someone writes @claude in a PR or issue comment. The second is running automatically with a fixed prompt when an event happens, such as a pull request being opened or updated. For review, the second mode is usually more predictable, because the prompt is yours and lives in version control, instead of depending on whoever wrote the comment.

The agent reads the repository code, considers the diff and the instructions in your CLAUDE.md file, and returns comments. If you grant more permissions, it can also edit files and create commits. In a first review phase, do not grant that. To learn how to write that context file, see How to Write a Good CLAUDE.md for Your Company Repository.

What should you prepare before turning it on?

Before you open the workflow editor, settle the decisions that are not technical. They prevent rework and make the pilot defensible in front of whoever owns security and data protection at your company.

• Choose a low or medium risk repository with reasonable tests and clear code owners. Avoid starting with the repository that touches payments or sensitive personal data.
• Decide who owns the API key and the cost of usage. Create a key dedicated to CI, separate from development keys.
• Decide what the automatic review should look at: likely bugs, missing tests, team conventions, security risks. A short list works better than a generic request to review everything.
• Agree on the golden rule: the agent's comment is a suggestion, and merge approval stays with a person.
• Write the success metric before you start. For example: the team finds most comments useful in a sample reviewed by humans. Without it, the pilot turns into opinion.

If the repository contains customers' personal data (fixtures, dumps, committed logs), clean it up or keep it out of the agent's reach, because the content it reads may be sent to the model provider. For the regulatory context, see LGPD and Artificial Intelligence for Companies: What to Do.

Step by step: your first automatic PR review

The outline below follows the flow in Anthropic's official documentation. Exact input names and the current version of the action change over time, so check the official page before copying anything.

• Step 1, install the app: the documentation describes installing the GitHub App from within Claude Code itself, or installing the app manually on the repository. Install it only on the pilot repositories, not across the whole organization.
• Step 2, secret: under Settings, Secrets and variables, Actions, create the ANTHROPIC_API_KEY secret with the CI-only key. The workflow references the secret by name, and the value never appears in the file.
• Step 3, workflow file: create a file inside .github/workflows. The trigger is the pull request event (opened and updated). The step uses Anthropic's official action, receives the key through the secret, and uses a review prompt written by you.
• Step 4, explicit permissions: declare the permissions block in the workflow. To comment on a PR, read access to contents and write access to pull requests is generally enough. Check the documentation to see whether your chosen mode requires anything extra, such as the identity permission used for cloud authentication.
• Step 5, review prompt: ask for a concrete output. For example: flag a small number of problems per PR, each with file, reason and suggestion, ignore style issues the linter already covers, and say so when nothing relevant is found.
• Step 6, execution limits: use the action's argument options to cap the number of agent turns and restrict the allowed tools. This controls cost and the surface of possible actions.
• Step 7, test on a throwaway PR: open a test PR with a deliberately planted error and check that the comment appears, that it points to the error, and that the log exposes nothing sensitive.
• Step 8, pin the version: reference the action by a stable version or, better, by commit hash, as GitHub's security hardening guide for Actions recommends. Update it deliberately.

The expected result is simple: on every PR, a short and useful comment, with no code changes and no access to anything beyond what is needed.

How do you restrict workflow and agent permissions?

There are two layers of permission, and both matter.

The first belongs to GitHub. The token the workflow receives may have broad scope by default, depending on repository or organization settings. The practice recommended in GitHub's documentation is to declare the permissions block and grant the minimum. For review, that means read access to repository contents and write access only where the comment is posted. Do not grant content write access if the agent should not commit.

The second layer belongs to Claude Code. The action lets you define which tools the agent may use. A review only needs to read files, search the code and see the diff. It does not need to run arbitrary shell commands, reach the network or install packages. If you later need it to run tests, allow one specific command, not the whole shell. The logic is the same one explained in Claude Code Security: Permissions, Sandbox and Secrets for Teams: deny by default and allow by documented exception.

A quick checklist to review the workflow before you accept its merge:

• Does the permissions block exist, and is it at the minimum level?
• Does the agent have access only to read tools?
• Is there a turn limit to prevent long loops and unpredictable cost?
• Is the action pinned to a version or hash?
• Does the workflow run only on the intended events and branches?
• Is the group that can change the workflow file small, with mandatory review?

That last question is easy to forget. If anyone can edit the workflow in a PR and that PR runs with secrets, the control is only apparent.

How do you protect secrets and prevent prompt injection?

Secrets in CI have three typical risks: leaking into logs, being read by code that is not yours, and staying alive for too long.

For the first, always use GitHub Secrets, never write the key in the YAML, and do not print environment variables in debugging steps. GitHub masks secret values in logs, but masking does not cover transformations of the value, so do not rely on it as your only defense.

For the second, pay attention to PRs coming from forks. By default, GitHub does not pass secrets to workflows triggered by pull requests from forks, and that is a useful protection. Some triggers bypass this restriction, such as pull_request_target, and GitHub's security guidance warns that they need care because they run in the context of the base repository. If your repository accepts outside contributions, keep the automatic review limited to internal branches during the pilot.

For the third, treat the key as disposable: give it an owner, set a usage limit at the provider when possible, and keep a rotation routine. The article Managing API Keys and Secrets for AI Agents: Storage and Rotation covers that cycle in detail.

Then there is prompt injection. Whoever writes the PR title, the description, a comment or even a code file can include instructions aimed at the model, such as ignoring earlier rules and revealing information. In a review that only reads and comments, the damage is smaller but still real: the comment can be manipulated, and if write or network tools are present, the impact grows. OWASP's references on prompt injection prevention and its Top 10 for LLM applications are the starting point. In practice, what protects you most is the combination of minimal permissions, no useful secrets within the agent's reach, and human review before any action.

Illustrative scenario: a small team and an API repository

Illustrative scenario: a logistics company has a small team maintaining an internal tracking API. PRs sit waiting for review because two senior people hold most of the approvals. The team decides to test Claude Code in CI.

They map the current flow: who opens the PR, who reviews it, and where repeated problems tend to show up (input validation, missing tests for edge cases, queries without pagination). Then they set limits: the workflow runs only on PRs from internal branches, with read access to contents and write access to pull requests, and the agent can only read files. The prompt asks for a small number of findings per PR, focused on the three recurring problems.

During the pilot, the automatic review comments before the human reviewers look at the PR. People still approve. At the end of the agreed period, the team samples the comments, marks each as useful, noisy or wrong, and decides: expand to another repository, adjust the prompt, or stop. Nothing here depends on a promised number, only on the sample the team collected itself.

How do you measure whether automatic review is worth it?

The working method applies directly here: map, limit, pilot and hand over. Mapping means understanding the current review process and where time is lost. Limiting means deciding permissions, tools and repositories. Piloting means running a real flow with logs and an agreed metric. Handing over means giving the team the workflow documentation, a key owner and a decision criterion for continuing.

To measure, use simple signals you can collect without a new tool:

• The share of comments the team found useful in a sample reviewed by people.
• Wrong or out-of-context comments, which point to a prompt or CLAUDE.md that needs adjusting.
• Time between opening the PR and the first feedback, compared with the period before the pilot.
• Usage cost per PR, tracked in the provider dashboard, to know whether the usage pattern fits the budget.
• Incidents: any log with sensitive data, manipulated comment, or permission used beyond what was planned.

To structure the decision criteria at the end, How to Measure an AI Automation Pilot: Metrics and Decision Gates helps define what expanding, adjusting or stopping means. If the goal is to roll usage out to the whole team, the Claude Code for Teams adoption guide covers roles and governance.

One hypothesis to validate in your own context: automatic review tends to be more useful for repetitive patterns and less useful for architecture decisions. This does not come from the documentation. It comes from the logic of what an agent can see in a diff. Test it in your repository before generalizing.

Frequently asked questions

Does Claude Code in GitHub Actions replace human code review?

No. It works as a first read that flags likely problems and team conventions. The decision to approve the merge should stay with a responsible person, especially for code that touches personal data or critical business rules.

Do I need to give the agent write permission to review PRs?

To comment, the workflow needs write access only to pull requests, plus read access to repository contents. You do not need to grant content write access or free command execution. If you later want the agent to suggest fixes by commit, treat that as a second phase, with a new pilot and a new risk review.

Is it safe to run the review on PRs from forks or outside contributors?

It is the highest risk situation, because the PR content is fully controlled by third parties and may contain prompt injection. By default GitHub does not pass secrets to workflows triggered by fork PRs, and it is worth keeping that behavior. In the pilot, limit the automatic review to internal branches and only evaluate the external case later, with a specific security review.

Where does my code data go when the agent runs?

The content the agent reads during the job is sent to the model provider to generate the response, and the job runs on GitHub runners, hosted or self-hosted. Check the provider's terms of use and data retention terms, and align with whoever owns data protection at your company. If the repository contains personal data, clean it up or exclude those files from the agent's reach before you start.

Sources

• Anthropic: Claude Code com GitHub Actions
• GitHub: Security hardening for GitHub Actions
• OWASP: prevenção de prompt injection
• OWASP Top 10 para aplicações com LLM