[BUG] `/code-review` tells its background agent to call `ReportFindings`, which the background agent doesn't have

Status Fixed / completed
Reported on v2.1.217
Maintainer reply None cached
Activity 2 comments · opened Aug 5, 2026 · closed Aug 17, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

The /code-review command only _sometimes_ invokes the ReportFindings tool.

The command prompts the background agent:

When you are done, submit at most 15 findings via the ReportFindings tool, filling its fields as defined […]

But the background agent always reports something like:

Note: no ReportFindings tool is available in this session (ToolSearch returns no match), so findings are reported inline below.

And then the parent session:

  • invokes ReportFindings itself, or
  • presents the results as prose,
  • only sometimes mentions the background agent was missing the tool

What Should Happen?

The review agent should be able to call ReportFindings.

Or it is never told to.

Error Messages/Logs

No error is raised. But from the review agent's own transcript
(~/.claude/projects/<project>/<session>/subagents/agent-<id>.jsonl):

# the prompt the background agent received
When you are done, submit at most 15 findings via the ReportFindings tool, filling its
fields as defined - for each: the file path and start line, a severity, and a comment
that states the issue and the concrete scenario in which the code misbehaves.

# its first tool call
{"name": "ToolSearch", "input": {"query": "select:ReportFindings", "max_results": 3}}

# its conclusion
Note: no `ReportFindings` tool is available in this session (ToolSearch returns no
match), so findings are reported inline below.

Steps to Reproduce

  1. Build a minimal repo with a defect in the working tree:

```sh
rm -rf /tmp/rf-repro && mkdir -p /tmp/rf-repro && cd /tmp/rf-repro
git init -q && git config user.email repro@example.com && git config user.name Repro
cat > cart.py <<'PY'
def total(items):
"""Sum the price of each item."""
return sum(item["price"] for item in items)
PY
git add cart.py && git commit -qm "add cart total"
cat > cart.py <<'PY'
def total(items, discount=0):
"""Sum the price of each item, applying a percentage discount."""
subtotal = sum(item["price"] for item in items)
return subtotal - discount

def checkout(items, coupon):
# coupon is a percentage, e.g. 10 for 10% off
return total(items, coupon)
PY
```

  1. Start an interactive session with your own configuration excluded, so hooks, plugins and settings are ruled out:

``sh
cd /tmp/rf-repro && claude --setting-sources ""
``

  1. Run /code-review medium. Any level above low works; low never uses the structured path.
  1. Note the output line Running in the background as @code-review.
  1. Do not judge by the rendered findings panel. The parent session often re-reports and masks the failure. Read what the review agent itself returned:

``sh
grep -o 'ReportFindings[^"]\{0,80\}' /private/tmp/claude-501/*/*/tasks/*.output
``

The <output-file> in the task notification is a symlink to the agent's transcript. Expected output: the agent's ToolSearch select:ReportFindings probe, and its "no ReportFindings tool is available in this session" line.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.217 (assumed, not tested)

Claude Code Version

2.1.222 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Reproduced in cmux.app and Terminal.app, with claude --setting-sources ""

Since 2.1.218, /code-review runs as a background subagent. Background subagents keep only a fixed allowlist of built-in tools, and ReportFindings is not on it. But the review prompt is still composed against the parent session's tool list, where ReportFindings is present, so the prompt instructs the review agent to submit its findings through a tool that its own dispatch mode has already removed.

Every /code-review run therefore ends with the review agent discovering it cannot report, and falling back to prose.

Two changelog entries in 2.1.218 introduce this:

Changed /code-review to run as a background subagent, so review work no longer fills your conversation and keeps stacked slash commands as its review target
Changed skills with context: fork to run in the background by default; opt out per skill with background: false

The documented background: false opt-out is not reachable here, because /code-review is a built-in command rather than a file-backed skill, so there is no frontmatter to set.

The tool-stripping itself is documented and presumably intended (docs/en/sub-agents):

Apart from Agent and ExitPlanMode [...] a background subagent keeps every MCP tool but only these built-in tools: Read, Grep, Glob, Bash, PowerShell, Edit, Write, NotebookEdit, WebFetch, WebSearch, TodoWrite, Skill, ToolSearch, EnterWorktree, ExitWorktree, Monitor, TaskStop, SendMessage, and Artifact. Claude Code removes every other built-in tool from a background subagent, whether inherited or listed in the tools field [...] The removal reports no error.

ReportFindings is absent from that list.

Why this is easy to miss

The failure is usually invisible in the UI. When the background agent's notification arrives, the parent session might redo the report itself, and the parent does have ReportFindings, so a findings panel renders and the run looks correct.

Across six successful ReportFindings calls in my transcript history, every one came from a parent session after its own background agent had already reported the tool missing. Not once did a review agent call it.

This masking is lossy. In the reproduction below the background agent produced three findings and the parent reported two, silently dropping a real one. The parent had not relayed the review; it re-read the file itself and reported its own, shorter conclusion. The rendered panel looks authoritative either way, so a reviewer cannot tell which they are looking at.

Related issues

  • #80733 asks for a visible warning when the background filter strips a tool. That change probably would have surfaced this.
  • #77146 is a different ReportFindings failure (a 400 when a subagent is resumed from a transcript that names the tool).
  • #83516 and #73939 both concern the presentation of ReportFindings output but assume the call succeeds.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗