
Claude Code Code Review Gets Max Findings Control
This episode breaks down the new --max findings flag for Claude Code code review, including how to cap, uncape, and reset findings, plus when to use effort levels and review comments or fixes. It also covers important caveats like sticky settings, background subagent behavior, and related quality-of-life updates in recent Claude Code releases.
Chapter 1
Taking control of code review findings
Lachlan Reed
Right, if you've ever run a code review in Claude Code and wondered why it handed you exactly a handful of findings and stopped, this one's for you. This is The Claude Code Changelog, brought to you by Jellypod AI. I'm Lachlan.
James Turner
And I'm James. We touched on this briefly at the tail end of a quick hits list for version 2.1.288, but it deserves its own slot. Slash code review picked up a dash dash max findings flag, and it changes how you can use the command.
Lachlan Reed
Here's the setup. Before 2.1.288, slash code review capped how many findings it reported, and that ceiling wasn't documented. On a quick sanity check that's fine. On a pre release audit or a security sweep, a cap can hide secondary defects that still matter. And on a sprawling diff, the opposite problem shows up, where a pile of minor suggestions buries the one thing you needed to see.
James Turner
So there are three forms. First, slash code review, dash dash max findings, then a number. Say three or five, and the report is limited to at most that many. Second, dash dash max findings all, which removes the ceiling and reports everything it detects across correctness, logic bugs, security risks and edge cases. Third, dash dash max findings default, which puts you back on Claude Code's standard limit. The slash review alias takes the same argument.
Lachlan Reed
Now the bit that'll catch people out. This flag is sticky. Most flags are one and done, but Claude Code reuses your chosen max findings value across later runs and later sessions until you explicitly pass default. So if you run it with all before a release, then next week you do a casual review of a small change, it's still uncapped. That means more latency and more token spend than you were expecting.
James Turner
My suggestion is to treat all as a mode you enter and leave. Run the exhaustive review, then run default as soon as you're done. Or just put the reset in your habit, like closing a browser tab you opened for one task.
Lachlan Reed
Let's talk about what you can point it at. By default, slash code review looks at commits on your current branch ahead of upstream, plus uncommitted working tree changes. You can also give it a ref range like main, three dots, feature. Or a pull request number, like slash code review 1042. Or specific file paths.
James Turner
And you can combine it with effort levels: low, medium, high or max. Low and medium focus on high confidence defects only. High and max widen the scrutiny. So for a release gate you might type slash code review, high, dash dash max findings all. For a quick look at what you just wrote, slash code review, low, dash dash max findings three.
Lachlan Reed
Two more flags worth knowing. Dash dash comment publishes findings as inline review comments on a GitHub pull request, or as a single note on a GitLab merge request through the glab command line tool. And dash dash fix applies the proposed corrections to your local working tree once the review finishes.
James Turner
The architecture matters here too. The review runs as a background subagent with its own context window, so all the diff analysis and candidate verification doesn't fill up your main conversation. You keep working while it runs. But that has a catch with dash dash fix. Those edits land outside your normal session checkpoints, so slash rewind can't undo them. If you don't like what it changed, you're reaching for git checkout or git revert. Commit or stash before you fix.
Lachlan Reed
One more caveat. Uncapping findings on a big multi file change can mean heavy subagent token usage and a longer verification run. Cap it with a number first, and go to all when you really want the full list.
James Turner
Also from 2.1.287, code review fixes: finding comments and the collapsed Why this was flagged rationale used to stop mid sentence, and now they finish cleanly. And code review no longer skips a pull request after a push if the review had failed twice on earlier commits.
Lachlan Reed
Quick quality of life hits. In 2.1.288, if you clear a prompt with Ctrl+C by mistake, press Up on the empty prompt and the draft comes back, including pasted text and images. The background command time limit now applies only to unattended sessions, meaning the p flag, the Agent SDK, CI and cloud. In the terminal, desktop app and VS Code, there's no limit, so your dev servers and file watchers can keep running.
James Turner
A few more. If you're behind Bedrock Mantle or a gateway that chokes on structured outputs, there's a new environment variable, CLAUDE_CODE_DISABLE_STRUCTURED_OUTPUTS, which you set to 1. In the agents view, Ctrl+F searches sessions by name, and Alt plus Up or Down jumps between groups. And claude project purge is now just claude purge, with the old name still working and printing a notice. Catch you next time.