claude-code - 💡(How to fix) Fix /ultrareview: cloud worker produced findings but CLI received error payload; results inaccessible from CLI [1 participants]

Summary

/ultrareview ran a cloud review that completed successfully and produced findings (14 confirmed, 9 refuted, visible at the cloud session URL), but the task-notification dispatched back to the CLI reported status: completed with an error payload as the findings — so from inside the CLI, the run looked like a crash with zero output. The free credit was consumed and there is no in-CLI signal that findings actually exist at the tracking URL.

Edited from the original report after I opened the cloud session URL in a browser and saw the findings list. Original framing said the worker crashed; that's wrong — the worker finished, but the result delivery to the CLI was broken.

Repro

1. From a Claude Code CLI session, run /ultrareview on a branch with a large diff.
2. Wait for the task-notification.
3. Observe the notification payload (see below).
4. Open the cloud session URL in a browser — findings are present and verified.

Environment

• Claude Code: 2.1.138 (CLI)
• Branch: main
• Diff scope reported by /ultrareview: 90 files, +17,056 / -107
• Cloud session: https://claude.ai/code/session_018iwdDUHejK4cWoRwaGG7aN
• Launch: 2026-05-10 06:22:09 UTC
• Notification returned: 2026-05-10 06:45:49 UTC (~23 min later)

Observed

Task-notification payload received in CLI:

<task-notification>
<task-id>r3ybh2rt7</task-id>
<task-type>remote_agent</task-type>
<status>completed</status>
<summary>Remote review completed</summary>
</task-notification>
The remote review produced the following findings:

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

But the cloud session UI (same session id) shows a fully-populated Verify panel header reading 14 confirmed · 9 refuted, with ~27 distinct finding rows across edge/venue-gateway (FFmpeg lifecycle, SSE reply.hijack(), operator-key handling) and apps/backstage-web (load-in flow state, TestPage/CompletePage rendering, contract mismatches). So the worker completed and the results exist server-side; only the delivery to the CLI was broken.

Local CLI confirmed credit was spent: Free ultrareview 3 of 3.

A subsequent retry (06:53:41 UTC) hit a transient server-side rate limit and never started — that part may just be load.

Expected

• When the cloud worker produces findings, the task-notification should deliver those findings (not an error string), or at minimum link to the tracking URL inline so the user knows results exist.
• status: completed with a payload of {"error": ...} is contradictory — pick one. If the worker succeeded, status should reflect that and the findings should ride along; if delivery failed, status should be delivery_failed (or similar) with a recovery URL.
• A run whose findings the user can't access from the CLI should not silently consume a free credit — at minimum surface "results available at <url>" so the user doesn't think it was wasted.

Asks

1. Fix the result-delivery path between cloud worker → task-notification so populated findings reach the CLI when the worker completes.
2. When delivery fails, surface a "results available at <session url>" message inline in the CLI instead of an error payload that looks like a crash.
3. Restore the credit for 018iwdDUHejK4cWoRwaGG7aN (or, if the credit cost is justified because the worker did the work, surface that explicitly so users know to open the URL).
4. Status field should never be completed when the payload is {"error": ...}.