ultrareview crashed before producing findings + rate limit error — 2nd occurrence same account, all 3/3 free quota now consumed

Resolved 💬 2 comments Opened May 5, 2026 by dhscfh Closed Jun 2, 2026

Summary

Second /ultrareview crash on the same account today, this time on a different repository (monorepo with proper SessionStart hook for dependency install). All 3/3 free runs now consumed with 0 findings produced.

Repro

| | |
|---|---|
| Command | /ultrareview 2 (PR mode) |
| Repo | dhscfh/twexam (private) |
| PR | https://github.com/dhscfh/twexam/pull/2 |
| Session | https://claude.ai/code/session_01XyEq1rMbLt7aweqCpXG5ns |
| Diff size | 338 files / +51,868 / -11 |
| Stack | pnpm + Turborepo monorepo (Next.js 16, Capacitor 8, Supabase) |
| Free runs at start | 3/3 |
| Free runs after | 0/3 (last one consumed) |

What happened

CLI launched the cloud session successfully. After the usual wait the task completed with this exact payload:

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

Concurrently the CLI surfaced:

API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited

(Status page https://status.claude.com showed all systems operational at the time, no public incident posted.)

What I had done to avoid the known crash bug

Read the docs and prior issues (#55031, #54871, #53455, #54812, #49905) before launching. Specifically prepared:

PR-mode review (not branch bundle) — clone-from-GitHub path is more reliable than bundle upload per docs
SessionStart hook committed to repo at .claude/settings.json:

``json { "hooks": { "SessionStart": [{ "matcher": "startup|resume", "hooks": [{ "type": "command", "command": "if [ \"$CLAUDE_CODE_REMOTE\" = \"true\" ]; then pnpm install --frozen-lockfile; fi" }] }] } }``

Repo state clean: pnpm type-check 11/11 PASS, pnpm test 85 tests PASS, pnpm build PASS locally before push
Constructed a dedicated review base branch to keep PR scope tight (excluded data/docs/.autoflow noise)

→ Setup-script-missing is not the cause here. The crash is in the review pipeline itself.

Same-account, same-day pattern

Earlier today I had the exact same crash on a different repo (dhscfh/stgfolio PR #4), already documented:

Standalone issue: #56202
Cross-comment on the master tracking issue: #55031 (first reply)

That crash also consumed a free run. Plus this one. Plus an earlier one. = 3/3 free runs consumed today, 0 findings produced, ~30 minutes of cloud sandbox time wasted.

The free runs expire today (May 5, 2026) per the docs, so I have no recourse to retry — these crashes effectively converted my entire trial allotment into nothing.

Asks

Refund all 3 free runs to my account — none of them produced any output. Per the docs "a run counts once the remote session starts," but there are now ~9 open issues (#55031, #54871, #53455, #54812, #54516, #53301, #52780, #49905, #56202) where users have hit this same crash class and asked the same. The pattern is too consistent to be edge-case.
Investigate the rate-limit + crash co-occurrence — the simultaneous "Server is temporarily limiting requests" + "Review crashed" suggests the cloud sandbox provisioner is failing under load and surfacing a generic crash to the user, not a real review-pipeline bug. Worth distinguishing in telemetry.
Make crash failures NOT consume quota — if the review never produced findings, charging it as a successful run is asymmetrical. This has been requested across most of the linked issues.