claude-code - 💡(How to fix) Fix [BUG] /ultrareview consumed free run despite 30-minute timeout failure [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#49706Fetched 2026-04-17 08:33:42
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Author
Timeline (top)
labeled ×5commented ×1

Error Message

When a remote ultrareview session fails with a timeout or any system-side error and returns no findings, the failed session should not be counted against the user's free run allotment. Free runs should only be deducted when the review successfully delivers findings to the CLI.

Error Messages/Logs

  • The failure is a system-side timeout, not a user-cancelled or user-error case.
RAW_BUFFERClick to expand / collapse

Preflight Checklist

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

What's Wrong?

Version: 2.1.112 (VS Code extension + CLI, macOS) Plan: Claude Max 5x Feature: /ultrareview (research preview)

Bug: Free ultrareview run was consumed despite complete remote session failure with zero findings returned.

Reproduction:

  1. cd into a fresh clone of github.com/Tracy625/cq-collab
  2. Launch claude CLI
  3. Run /ultrareview 44 (PR: +4710/-424, 59 commits)
  4. Confirmation dialog showed "Free runs remaining: 3/3"
  5. Session launched: session_014tuJwbYUNHRRornrL6vJV5
  6. After ~30 minutes, session returned: "Remote review failed: remote session exceeded 30 minutes" "Remote review failed (session exceeded 30 minutes). Retry /ultrareview 44, or run /review locally instead."
  7. No findings were delivered.
  8. Free run count dropped from 3/3 to 2/3.

A second attempt (session_01B4qAupJzBGGhJ86ScFzghA) was launched to verify, consuming another free run. Count is now tracking toward 1/3 if the second session also times out.

What Should Happen?

When a remote ultrareview session fails with a timeout or any system-side error and returns no findings, the failed session should not be counted against the user's free run allotment. Free runs should only be deducted when the review successfully delivers findings to the CLI.

Additionally, the 30-minute hard timeout should be documented in the /ultrareview docs so users can make informed decisions about PR size before launching. The current docs state "10 to 20 minutes" as typical duration with no mention of a hard cap.

Requested resolution:

  1. Refund the consumed free run(s) for the failed session(s) on this account.
  2. Consider increasing the 30-minute timeout for large PRs, OR surface an up-front PR-size check before the confirmation dialog so users can split the PR or fall back to /review before consuming a free run.

Error Messages/Logs

Steps to Reproduce

  1. Ensure Claude Code CLI v2.1.86+ is installed (tested on v2.1.112) and you are on Max 5x plan with 3/3 ultrareview free runs available.

  2. Clone a sufficiently large PR target repo: cd ~/Desktop git clone https://github.com/Tracy625/cq-collab.git cq-collab-review cd cq-collab-review

  3. Launch Claude Code CLI: claude

  4. In the session, run: /ultrareview 44 (PR #44 contains +4710/-424 lines across 59 commits — 18 P0/P1 fixes spanning multiple modules)

  5. Confirm the launch dialog (shows "Free runs remaining: 3/3", estimated cost 0 credits).

  6. Wait approximately 30 minutes. The session returns: Remote review failed: remote session exceeded 30 minutes Remote review failed (session exceeded 30 minutes). Retry /ultrareview 44, or run /review locally instead. No findings are delivered to the CLI.

  7. Free run count has dropped from 3/3 to 2/3.

Observations:

  • The failure is a system-side timeout, not a user-cancelled or user-error case.
  • No partial findings, no diagnostic output — just the timeout message.
  • The free run counter decrements identically to a successful run.
  • Reproduction is deterministic on large PRs: a second attempt (session_01B4qAupJzBGGhJ86ScFzghA) on the same PR is currently in flight with the same expected outcome.

Relevant session IDs for log lookup:

  • session_014tuJwbYUNHRRornrL6vJV5 (first failure)
  • session_01B4qAupJzBGGhJ86ScFzghA (second attempt, in progress at time of report)

Note: This bug likely affects any PR large enough to exceed the 30-minute remote timeout. The current /ultrareview docs state typical duration is 10-20 minutes but do not mention the hard cap.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.112

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response

extent analysis

TL;DR

The free ultrareview run should not be consumed when a remote session fails with a timeout and returns no findings, suggesting a fix is needed to handle session failures without deducting free runs.

Guidance

  • Review the current logic for handling remote session timeouts to ensure that free runs are not deducted in cases where no findings are returned.
  • Consider implementing a check to refund the consumed free run(s) for failed sessions that return no findings.
  • Evaluate the 30-minute timeout for large PRs and consider increasing it or adding an up-front PR-size check to inform users before consuming a free run.
  • Document the 30-minute hard timeout in the /ultrareview docs to help users make informed decisions about PR size before launching.

Example

No code snippet is provided as the issue is more related to the logic and functionality of the /ultrareview feature rather than a specific code error.

Notes

The issue seems to be a regression, as it worked in a previous version, and the current version (2.1.112) is affected. The problem is likely related to the handling of remote session timeouts and the deduction of free runs.

Recommendation

Apply a workaround to handle session failures without deducting free runs, as the root cause of the issue is related to the logic of handling remote session timeouts. This will help prevent unnecessary consumption of free runs until a permanent fix is implemented.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] /ultrareview consumed free run despite 30-minute timeout failure [1 comments, 2 participants]