Claude Code Security Review: Catch Bugs Before Merge

A Claude Code security review uses Claude to read your code changes and flag vulnerabilities before they ship — SQL injection, XSS, hardcoded secrets, broken auth, and unsafe input handling. You run it two ways: the /security-review slash command inside a session, or the official GitHub Action that reviews every pull request automatically.

Command and Action behaviour verified 31 July 2026 against Anthropic's write-up on automating security reviews.

Security bugs are cheapest to fix before they merge. Once a SQL injection or a leaked API key lands on your main branch, it can sit there for months. The Claude Code security review closes that gap by putting an AI reviewer in the loop right where you work — in your terminal and on your pull requests. This guide covers both forms, exactly what each one catches, where the limits are, and how to fit it into a workflow you already trust. We put this through its paces on our own setup first, so the notes below reflect what really happened, not what should happen.

Claude currently spans the latest models — Claude Opus 5 ($5/$25 per million tokens), Claude Sonnet 5 ($3/$15), and Claude Haiku 4.5 ($1/$5), per Anthropic's pricing — and we review this guide regularly so the steps stay accurate as those releases move. If you are new to the tool itself, our what is Claude Code explainer sets the stage. Here we focus purely on security.

What a Claude Code security review actually does

It reasons about your changes the way an application security engineer would — tracing where untrusted input enters and following it through the code — rather than matching regex patterns, which is what keeps the findings signal rather than noise.

A Claude Code security review is a security-focused pass over your code. Instead of asking Claude a general "is this okay?" question, you trigger a dedicated review that reasons about your changes the way an application security engineer would: it traces where untrusted input enters, follows it through the code, and asks whether anything dangerous can happen along the way.

Because Claude reads the code semantically rather than matching regex patterns, it understands context. It can tell the difference between a string concatenation that is safe because the input is a hardcoded constant and one that is exploitable because the value comes from a request parameter. That context is what separates a useful review from a wall of noise.

There are two ways to run it, and they share the same underlying analysis:

1. The /security-review slash command, run inside an interactive Claude Code session.
2. The official anthropics/claude-code-security-review GitHub Action, which runs the same review automatically on pull requests and posts findings as comments.

Anthropic introduced both together so the same review you run locally is the one that guards your pull requests. You can read the announcement in Anthropic's write-up on automating security reviews.

Running the /security-review command

Typing /security-review in a session scans your pending diff and returns findings with file and line references, a severity, a category, an exploit scenario, and a suggested fix. Speed is the point: run it before opening a pull request.

The fastest way to try it is the slash command. Open a Claude Code session in your project and type:

/security-review

Claude looks at your pending changes — the diff you are working on — and produces a security-focused report. Each finding typically includes the file and line number, a severity, a category (like sql_injection or xss), a description of the problem, an exploit scenario that shows how it could be abused, and a suggested fix. That last part matters: a good review does not just point at a problem, it hands you the patch.

Slash commands are the general mechanism Claude Code uses for these built-in workflows; if you want to go deeper on the pattern, see our guide to Claude Code slash commands. The nice thing about running /security-review locally is speed. You can run it before you even open a pull request, fix what it finds, and keep the diff clean. It pairs well with the habits in our Claude Code tips and tricks roundup — treat it as a pre-commit reflex, not a once-a-quarter event.

On our own repo — a Next.js app we build entirely in Claude Code — the local /security-review is the form we actually lean on, because there is rarely a second human standing by to catch an unsafe input handler before it merges. Running it against the pending diff before opening a pull request is exactly the kind of check that is easy to wave through late at night: a route missing a permission gate, a value flowing somewhere it should not. We read a clean result as "nothing obvious here," never as "this is safe" — which is precisely the limit the section below spells out.

Make sure you are on a recent version first; if the command is missing, our note on how to update Claude Code covers the upgrade.

Setting up the GitHub Action on pull requests

Roughly twenty lines of YAML gives every change the same review automatically. The action is diff-aware, filters false positives, needs an API key secret and comment-write permission, and should only run on trusted pull requests.

The slash command is great for the code in front of you, but teams want a guarantee that every change gets reviewed. That is what the GitHub Action is for. It runs the same Claude Code security review automatically whenever a pull request opens or updates, then comments its findings inline so reviewers see them without leaving GitHub.

Setup is a standard GitHub Actions flow — roughly 20 lines of YAML in a new workflow file. In broad strokes:

1. Add a workflow file under .github/workflows/ in your repository.
2. Reference the anthropics/claude-code-security-review action as a step.
3. Provide an Anthropic API key as a repository secret so the action can call Claude.
4. Grant the workflow permission to write pull-request comments so it can post results.

The action is diff-aware: on a pull request it focuses on the changed files rather than re-scanning your whole codebase, which keeps it fast and relevant. It also applies false-positive filtering to cut down on noise, so reviewers are not buried under low-value warnings. Full, current setup details — the exact inputs, model options, and toggles — live in the official claude-code-security-review repository; treat that as the source of truth, since inputs and defaults change over time.

One important safety note from Anthropic: the action is not hardened against prompt injection, so you should only run it on trusted pull requests. For public repositories, configure GitHub to require maintainer approval before workflows run on contributions from outside collaborators. If you already lean on automation, this slots in alongside patterns like Claude Code hooks and Claude Code MCP servers as part of a broader automated pipeline. On the housekeeping side, if you would rather Claude not appear in your repository's contributor list once it starts committing fixes, our guide to removing Claude as a GitHub contributor explains the commit trailer behind it.

What the Claude Code security review flags

Nine vulnerability classes, weighted toward the ones that need data-flow reasoning: injection, cross-site scripting, command execution, hardcoded secrets, broken authorization, unsafe input handling, weak cryptography, business-logic races, and sensitive data exposure.

Here is a concrete look at the vulnerability classes a Claude Code security review targets, with a plain example of each. This is the table to bookmark.

Because the review reasons about data flow, it is especially good at the injection and authorization categories, where a pattern-only scanner tends to either miss the bug or scream about every string operation. The review also deliberately filters out some low-signal categories — generic denial-of-service concerns, rate-limiting notes, and unproven input-validation nitpicks — so the findings you get are the ones worth acting on.

Limits: it is a first pass, not a full audit

Four limits matter. There is no completeness guarantee, findings need human verification, only the changed code is examined, and the Action is not hardened against prompt injection. A clean result means nothing obvious, not proven safe.

This is the part too many teams skip. A Claude Code security review is a strong, fast first-pass reviewer — it is not a replacement for a professional security audit, a penetration test, or dedicated SAST/DAST tooling.

Keep these limits in mind:

• No completeness guarantee. A clean review means Claude did not find a problem in the changed code, not that the code is provably secure. Absence of findings is not proof of safety.
• Findings need verification. AI reviewers can produce false positives and, occasionally, false negatives. Confirm each real finding and sanity-check the suggested fix before you apply it — the same care you would give any generated code. If you have ever seen an agent do something dramatic, our cautionary tale about when Claude Code deleted a database is a reminder to keep a human in the loop.
• It reviews what it sees. The command reviews your current changes; the Action is diff-aware on pull requests. Neither is a substitute for periodic full-codebase audits of legacy code that predates the tool.
• Prompt-injection caution. As noted, the Action is not hardened against prompt injection, so restrict it to trusted pull requests.

None of this makes the tool less valuable — it makes it honest. The review catches a large share of common, high-impact bugs early and cheaply, which frees your human experts and paid audits to focus on the hard, architectural risks that AI cannot fully judge.

Best practices for wiring it into your workflow

Five habits turn it into a guardrail: run it before every merge, keep tests and human reviewers alongside it, re-run after applying a fix, read each exploit scenario before trusting it, and exclude generated directories.

To get real value, wire it into your normal flow rather than treating it as an afterthought:

• Run it before you merge, every time. Use /security-review locally before opening a pull request, and let the Action guard the branch as a backstop. Two chances to catch a bug beats one.
• Combine it with tests and human review. The review is one layer. Keep your unit and integration tests — the same review discipline applies when you use Claude Code for QA automation to write them — and keep a human reviewer on anything touching auth, payments, or user data.
• Fix, then re-run. After applying a suggested fix, run the review again to confirm the issue is resolved and you did not introduce a new one.
• Verify before you trust. Read each finding's exploit scenario. If the path is not actually reachable in your app, mark it and move on; if it is, patch it.
• Tune for your repo. Exclude generated directories and, where supported, add custom instructions so the review understands your framework's safe patterns.

Used this way, the Claude Code security review becomes a quiet, constant guardrail — one that turns "we'll audit it later" into "it was reviewed before it merged." Reviewing your code is only half of it, though: Claude Code security covers the agent's own threat model, from permissions to prompt injection.

Auditing a whole repo rather than a diff? How to scan Claude Code for vulnerabilities covers all three paths — and the five bug classes the review deliberately filters out.