In Claude Code, /security-review is a command that runs a security review of the changes you're about to ship. It looks at the pending changes on your current branch and flags security problems in them, such as injection flaws, authentication and authorization gaps, and data exposure. A "pending change" is simply new or edited work that hasn't been merged or shipped yet. Running the command means a security issue gets caught while you can still fix it quietly, instead of after it's live.

What the /security-review command does

When you run /security-review, Claude reads the difference between what your code looked like before and what it looks like now (the "diff"), and reviews only that. It is not rewriting anything or shipping anything. It reads, then reports back what it found and where, so a person can decide what to do about it. Think of it as a careful second set of eyes focused on one question: could this change be used to break in, leak data, or do something it shouldn't?

/security-review

Run a security-focused review of the pending changes on your branch. Click to copy.

The kinds of problems it looks for

The review is built around the categories of mistake that most often turn into real security incidents. A few of the big ones, in plain terms:

what it checks
InjectionUntrusted input that gets treated as a command or a database query, letting an attacker slip in instructions of their own.Risk
Authentication and authorization gapsPlaces where the code fails to check who someone is, or lets them reach something they shouldn't be allowed to.Risk
Data exposureSensitive information (keys, personal data, internal details) leaking somewhere it can be seen or logged.Risk

Three of the risk categories a security review targets.

How it's different from /code-review

Claude Code also has a general /code-review that checks a change for correctness and cleanup, the everyday "is this good code?" pass. The /security-review command is a deeper, security-focused version of that same idea. It complements the general review rather than replacing it: run the general review to catch bugs, and run /security-review when you specifically want to know whether a change is safe to expose to the world.

Pass 1/code-reviewThe everyday read. Is the change correct, and is it clean? Catches bugs and rough edges.
Pass 2/security-reviewThe deeper read. Could this change be exploited? Focused only on security risk.

A real example

Say your team just added a login screen and a page that returns a customer's account details. That's exactly the kind of change where a small mistake becomes a big problem: a missing permission check could let one customer pull up another's data. Before shipping it, you run the command.

claude
› /security-review # Reviewing pending changes on this branch... # Found: the account page returns details # without checking the request belongs to # the logged-in user (authorization gap). Flagged 1 issue to review before shipping.

Nothing shipped. The review simply pointed at the risky line and explained why it matters, so the gap gets closed in review instead of in production. The same pattern is worth running any time a change touches sign-in, handles user input, reads or writes files, or returns data.

Good moments to run it: before you ship a change that touches authentication, handles user input, accesses files, or returns data. Those are the areas where a security issue does the most damage, so they're the ones worth a second, focused look.

Why this matters if you don't code

You may never type this command yourself, and that's fine. The reason it's worth knowing is what it represents: a repeatable safety check that runs on every risky change, without waiting on a specialist's calendar. Catching a problem in review is cheap and quiet. Catching it after it ships means a scramble, and sometimes a breach. Building that check into how work gets done is the kind of system that separates teams who use AI well from teams who just talk to it.