If you built a mental model of /code-review and /verify any time before late July 2026, part of it is now wrong. Two changes landed four days apart — one that removes a capability Claude had quietly relied on, and one that changes where and how /code-review actually executes — and neither is the kind of change you’d notice unless you were watching the changelog line by line.
This piece verifies both changes against the current official documentation (code.claude.com/docs/en/changelog, code.claude.com/docs/en/code-review, and code.claude.com/docs/en/skills) and works through what each one means for a working session.
v2.1.215 (July 19, 2026): Claude stopped inviting itself to review your code
The official skills documentation states it plainly:
“Claude invokes some bundled skills automatically when relevant; others, including
/verifyand/code-review, run only when you invoke them, which keeps you in control of when these longer-running checks spend time and tokens. Before v2.1.215, Claude could also run/verifyand/code-reviewon its own.”
Before this release, /code-review and /verify behaved like any other bundled skill Claude is allowed to self-invoke: Claude could decide, mid-session, that a review or a build-and-run verification was warranted, and launch it without being asked. After v2.1.215, that self-invocation path is closed for these two specifically. They only run when you type /code-review or /verify yourself.
It’s worth being precise about what /code-review and /verify actually are, since it’s easy to assume they’re marketplace plugins. They’re not — they’re bundled skills, shipped with Claude Code by default, distinct from a plugin you’d install via /plugin. Both are prompt-based: Claude Code hands Claude a detailed instruction set and lets it orchestrate the work with its own tools, rather than executing fixed logic directly the way a built-in command like /compact does.
Why this matters even if you never noticed Claude self-invoking
Both skills are expensive relative to a normal turn. /code-review dispatches multiple agents in parallel to examine a diff and its surrounding codebase, cross-verifies their findings against each other, then reports. /verify builds and runs your actual application to confirm a change works, rather than trusting tests or type checks alone. Both cost meaningfully more tokens and wall-clock time than continuing a normal conversation turn.
When Claude could trigger either one autonomously, that cost was incurred on Claude’s judgment, not yours — in a long autonomous session, or across several parallel sessions, self-invoked reviews and verifications could accumulate spend you didn’t explicitly authorize. Removing self-invocation for exactly these two skills, while leaving other bundled skills auto-invocable, reads as a targeted decision: keep automatic invocation for cheap, low-risk skills, and require an explicit ask for the two that are consistently the most expensive.
v2.1.218 (July 22, 2026): /code-review moved to a background subagent
Three days later, /code-review specifically got a second, unrelated change. From the official docs:
“The review runs as a background subagent with its own context window, so it doesn’t fill your conversation. The findings arrive in your conversation when the review completes.”
Before v2.1.218, running /code-review executed inline, in your current conversation, consuming your session’s context window as it worked. As of v2.1.218, it defaults to running as a background subagent — a forked context (context: fork, background: true by default in skill frontmatter terms) — so you can keep working in your main session while the review runs, and the findings land back in your conversation once it’s done.
Two secondary behavior changes ship in the same release, both easy to miss if you’re not reading the fine print:
Stacked command parsing changed. Before v2.1.218, a slash command written immediately after /code-review expanded as its own separate skill invocation. So /code-review /fix-issue 123 would trigger /code-review and separately load /fix-issue as a second skill. As of v2.1.218, that’s gone — everything after the review target is read as plain text describing the review target itself, not as a second command to expand. /code-review /fix-issue 123 now reviews with /fix-issue 123 as literal target text.
--fix edits made in the background fall outside checkpoints. This is the one worth remembering. When /code-review --fix runs in the background (the new default), its edits are applied outside your session’s checkpoint system — /rewind will not undo them. You have to revert with git instead. When /code-review runs in the foreground (which still happens in a few specific cases — see below), its edits land inside your turn as usual, so /rewind restores them normally.
# Runs in the background by default (v2.1.218+)
/code-review --fix
# → Fixes applied outside checkpoints. /rewind will NOT undo this — use git.
# Running /code-review again while a review is already in progress
# forces foreground execution for the new invocation
# → Normal turn behavior, /rewind works as expectedAccording to the docs, /code-review still runs in the foreground in a specific set of cases: when you invoke it again while an earlier review is already running, when you’re in non-interactive mode (-p flag or the Agent SDK, except ultra which launches without waiting), or when CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1 is set (which disables every background task feature, not just this one).
What didn’t change
The core review mechanics are the same as before both releases. /code-review reviews your branch’s unpushed commits plus uncommitted working-tree changes by default, and accepts a file path, PR number, branch name, or ref range (main...my-feature) as an explicit target.
/code-review # Review the current branch
/code-review --fix # Apply findings directly to the working tree
/code-review --comment # Post findings as inline PR comments
/code-review high # Raise effort for broader (noisier) detection
/code-review ultra # Escalate to the cloud-based ultrareviewEffort levels still trade coverage for confidence: low and medium report only high-confidence findings, high through max cast a wider net that may include less-certain findings. ultra still has its own argument parsing — a single word is read as a branch name or PR number, and any longer text that doesn’t name one is attached to the review as a note (/code-review ultra check my auth changes reviews the current branch with that note included).
One more constraint worth knowing if you automate around /code-review: it’s marked disable-model-invocation in its skill frontmatter, and setting it as a scheduled task’s prompt doesn’t trigger an actual review — Claude reads the text literally instead of running the skill. If you’re building a scheduled or CI-triggered review pipeline, invoke it as an explicit prompt in a live session or via claude -p '/code-review', not through the scheduled-task prompt field.
Practical Guidance
Stop assuming Claude will review on its own. If any part of your workflow depended on Claude occasionally deciding to run /code-review or /verify unprompted after finishing a task, that stopped working as of v2.1.215. Add an explicit /code-review or /verify step to your own routine — end of task, pre-commit, whatever cadence you were implicitly relying on Claude to self-trigger.
Use git, not /rewind, to undo background --fix edits. Since background execution is now the default for /code-review --fix, get in the habit of checking git diff or git status before and after, rather than reaching for /rewind out of habit — it silently won’t touch background-applied fixes.
Re-check any command chaining you built around /code-review. If you had a workflow that relied on stacking a second command after /code-review and having it expand independently, that behavior is gone as of v2.1.218. Anything after the review flags/effort level is now review-target text, full stop.
Don’t try to schedule /code-review as a scheduled-task prompt. It won’t run the skill — disable-model-invocation blocks that path by design. Trigger it from a live session or a claude -p invocation instead.
Keep Review and QA in the Same Loop
Claude’s /code-review catches logic errors and correctness bugs in your diff — but it doesn’t see what actually renders in the browser. BugHerd lets reviewers pin visual bug reports directly on staging pages instead of screenshot-and-Slack. Pairs cleanly with a /code-review pass before merge: Claude catches the code issues, BugHerd catches what only shows up on the rendered page.
FAQ
Q: Did /code-review and /verify used to run automatically in every Claude Code session?
No — Claude could invoke them autonomously when it judged them relevant, not on a fixed schedule. As of v2.1.215 (July 19, 2026), that autonomous invocation path is closed for both skills specifically; they now run only when you type /code-review or /verify yourself.
Q: Is /code-review a plugin I need to install?
No. It’s a bundled skill shipped with Claude Code by default, distinct from marketplace plugins installed via /plugin. No installation step is required to use it.
Q: Does /code-review still run inside my conversation, consuming my context window?
Only in specific cases. As of v2.1.218 (July 22, 2026), it defaults to running as a background subagent with its own context window, so it doesn’t consume your main session’s context. It falls back to foreground execution if a review is already in progress, in non-interactive (-p/SDK) mode, or when CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1 is set.
Q: Can I undo a /code-review --fix with /rewind?
Only if it ran in the foreground. Background --fix edits (the default since v2.1.218) are applied outside your session’s checkpoint system, so /rewind doesn’t touch them — revert with git instead.
Q: Can I schedule /code-review to run automatically on a timer?
Not as a scheduled-task prompt — /code-review is marked disable-model-invocation, so a scheduled task using it as its prompt just reads it as plain text instead of running the review. Trigger it from a live session or claude -p '/code-review' instead.
Q: Does chaining another command after /code-review still work the way it used to?
No. Before v2.1.218, a command stacked right after /code-review expanded as its own separate skill. As of v2.1.218, everything after the target/flags is read as plain review-target text instead.