[BUG] `/ultrareview` crashes before producing findings — 2 consecutive failures, same branch

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?

Hi Anthropic team,

/ultrareview (the Claude Code cloud multi-agent review) has crashed on two consecutive attempts against the same branch with no findings produced. Each attempt consumed one of my three free ultrareview credits. I'd appreciate either guidance on what's failing or a credit refund.

Failure signature

Both runs ended with the same notification:

<task-notification>
<task-type>remote_agent</task-type>
<status>completed</status>
<summary>Remote review completed</summary>
</task-notification>

{"error":"Review crashed before producing findings. See session logs for details."}

The status: completed from the orchestrator combined with the embedded crash error suggests the orchestrator caught a downstream failure but didn't surface useful detail to the CLI.

Cloud session URLs

• Attempt 1 (Free ultrareview 1 of 3): https://claude.ai/code/session_01AdhLbc49EACmRnunAitQWo?from=cli
• Attempt 2 (Free ultrareview 2 of 3): https://claude.ai/code/session_01YRsu3G3p3x1BpFghzPNS3z?from=cli

Reproduction details

• Command: /ultrareview with no arguments (reviewing current local branch against base)
• Branch: mcp-server-early-phase → master
• Repo: Azure DevOps — puremedia/CloudCover 2.0/ServiceDelivery (private, so the CLI bundle contains the diff)
• Diff size: 67 files changed, 8,341 insertions, 50 deletions
• Subject matter: Adds a new apps/mcp-server/ directory implementing a Model Context Protocol server (OAuth 2.1 facade in front of Azure AD B2C, 16 MCP tools, 14 test files, 4 ADO YAML pipelines)
• Both runs reported the same scope on launch: Scope: 67 files changed, 8341 insertions(+), 50 deletions(-)
• No CLI-side error was returned before the task-notification — orchestrator launch succeeded both times, then crashed in the cloud

What I think might be happening (speculation, not diagnosis)

A few possibilities I haven't been able to rule out from the CLI side:

1. Bundle size near a cap. 8.3K LOC of insertions plus the full repo CLAUDE.md context may exceed an internal per-agent budget when fanned out across multiple Sonnet review agents.
2. Content-filter trigger on .env-local. The branch includes a .env-local diff with real-looking secret strings (an HMAC EMAIL_TOKEN_KEY, an ABLY_API_KEY, a Permissions-service API key, etc.) that may be tripping a live-credentials detector and aborting the review rather than partial-completing.
3. MCP / OAuth / ADB2C terminology. The branch is dense with mcp.read, mcp.write, Authorization: Bearer, client_secret, PKCE, redirect_uri — none of which are unusual in an OAuth review, but the volume + the live-secret context could compound any auth-related filter.

(I've separately reproduced equivalent findings via a local deep review at /effort max on Opus 4.7 with no issues, so the content itself is reviewable — just not by the cloud orchestrator in its current state.)

What would be helpful

1. Confirmation that the cloud session logs show the actual crash cause (input cap, content filter, runtime exception in an agent, etc.)
2. If it's a content-filter issue: a way to either redact the bundle client-side before the run, or a clearer error message in the CLI.
3. A refund of the two free credits consumed by the crashes — I'd rather not burn the 3rd attempt blind.

Happy to provide more detail (CLI version, OS, transcript) if useful.

Thanks!

What Should Happen?

/ultrareview should produce structured review findings
(or, on a controlled failure, a specific, actionable error
message in the CLI). Two outcomes would be acceptable:

1. Normal success — the cloud orchestrator runs the

multi-agent review, posts findings back into the CLI
session, and consumes one of the three free credits.

1. Controlled failure with a useful error — if the cloud

orchestrator decides the input is too large, the diff
contains content it won't process, or any other hard stop
applies, the CLI should surface a specific reason (e.g.,
"diff exceeds N LOC", "credential-shaped content detected,
redact before retry", "orchestrator timeout") instead of
the generic "Review crashed before producing findings"
string. A controlled failure should NOT consume one of the
three free credits.

What happened instead: two consecutive runs against the
same branch returned only the generic crash error with no
diagnostic detail, and both still consumed a free credit
(credit counter went 1/3 → 2/3 → 3/3 with no findings to
show for it).

Error Messages/Logs

Steps to Reproduce

The two cloud sessions referenced below ARE the
reproduction — Anthropic engineers should be able to pull
orchestrator + agent logs for both sessions from the
backend, since the failure happens entirely in the cloud
(the CLI just sees the final crash error).

The CLI-side steps were:

1. In Claude Code CLI v2.1.152 on Linux/bash, sitting on

the local feature branch in a private repo, run:

/ultrareview

(no arguments — defaults to current branch vs base)

1. The CLI confirms launch with this banner:

Free ultrareview 1 of 3.
Ultrareview launched for <branch> → master (~5-10 min,
runs in the cloud).
Track: https://claude.ai/code/session_<id>?from=cli
Scope: 67 files changed, 8341 insertions(+), 50
deletions(-)

1. ~5–10 minutes later, the task-notification arrives with

body:

{"error":"Review crashed before producing findings. See
session logs for details."}

1. Re-running /ultrareview without changing anything in

the branch produces an identical failure on attempt 2.

Both failed cloud sessions (full backend access required):

• Attempt 1: https://claude.ai/code/session_01AdhLbc49EA

CmRnunAitQWo?from=cli

• Attempt 2: https://claude.ai/code/session_01YRsu3G3p3x

1BpFghzPNS3z?from=cli

The repo is private to my employer, so I can't share it
externally — but the relevant input shape is:

• Single feature branch, 8 commits, ~67 files changed,

~8,341 insertions, ~50 deletions

• Most of the diff is one new directory adding a small

Node.js / Express HTTP server (~1,500 LOC of source) that
acts as an OAuth 2.1 facade in front of Azure AD B2C and
exposes 16 Model Context Protocol tool handlers

• 14 new Mocha/Chai/Sinon test files (~1,500 LOC)
• 4 new Azure DevOps YAML pipeline files (one per

environment)

• Several markdown design docs (~700 LOC of docs)
• A modified .env-local file that contains real-looking

secret strings: an HMAC signing key, an Ably API key, a
Permissions-service API key, a Shippo token, a Mailgun
route key. These are dev/staging credentials that exist in
the team's shared local .env-local file (a separate
problem I'm fixing in the same PR review), but they have
the SHAPE of live secrets.

• The repo's CLAUDE.md files are also bundled in the

context (root + per-app + per-test-dir).

If it would help diagnosis, I can privately share:

• A redacted patch file (git format-patch --stdout) of the

branch against master

• A file listing (git diff --stat) with the line counts

per file

• The exact content of the .env-local diff (or a

structurally-identical redacted version) if you suspect
content filtering

For comparison: an in-session local deep review by the
same Opus 4.7 model on the same branch completed normally
and produced detailed findings, so the diff is reviewable
in principle — the failure appears specific to the cloud
ultrareview orchestrator's input handling.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

2.1.152

Claude Code Version

2.1.152

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other

Additional Information

I run Fedora 44 Workstation and used the bash terminal