/ultrareview hangs after 'Claude Code process started' — no review-bug events emitted, 30-min timeout

[indigoae]

Repository: anthropics/claude-code
Component: /ultrareview (research preview)
Severity: blocks the feature on real-world repos; consumes free-run quota with no findings

Summary

/ultrareview <PR#> consistently fails on a moderately-sized monorepo (indigoae/bellatune, ~6.6 MB diff under review). The remote sandbox provisions and clones successfully, the review agent's process starts, but no <review-bug> events are ever emitted to the events stream. The session eventually hits the 30-minute timeout and surfaces as Remote review failed: remote session exceeded 30 minutes.

Two consecutive attempts on the same PR exhibited the identical failure shape, suggesting a deterministic bug rather than a transient infrastructure issue.

Reproduction

1. PR under review: a 5-commit architectural refactor on a Python monorepo. git diff origin/master..HEAD is 6608 lines, 23 files. The repo itself is too large for the local-bundle path (the /ultrareview confirmation prompt rejects it with "Repo is too large. Push a PR and use /ultrareview <PR#> instead.").
2. Pushed to a draft branch, opened PR.
3. Ran /ultrareview <PR#>. Confirmed launch.
4. Track URL surfaces a session ID. Review runs in the cloud sandbox.
5. ~30 minutes later: task-notification reports Remote review failed: remote session exceeded 30 minutes.

Failure shape (verified via the events API)

Used ~/.claude/.credentials.json claudeAiOauth.accessToken against GET https://api.anthropic.com/v1/code/sessions/{session_id}/events with anthropic-version: 2023-06-01.

Both sessions show this event sequence (oldest first):

1. Allocating sandbox
2. Environment runner started
3. Initializing environment
4. Cloning repository indigoae/bellatune
5. Cloning repository indigoae/bellatune (still in progress...)
6. Cloning repository indigoae/bellatune (presumably finished)
7. Finished processing sources
8. No setup script configured
9. Parallel initialization completed
10. Claude Code executor created
11. Starting Claude Code
12. Claude Code process started
13. (no further events for ~29 minutes)
14. Session marked failed with timeout message

Event types present in the stream: env_manager_log, system, control_request, control_response. No tool_use, no agent_log, no <review-bug> envelopes — the review agent never produces observable activity.

Two reproductions

#	Session ID	Setup duration	Time of "Claude Code process started"	Time of timeout	Total events
1	session_01F4t6gggkqB83NNnxpcWDDi	~51s	04:00:04 UTC	04:30 UTC	14
2	session_01VrDtLfdyfNzPkufEYxVpLc	~14 min	05:32:52 UTC	~06:02 UTC	22

Both used the same PR (rebased between attempts to land a CI fix on master). Setup duration varied substantially; the post-startup silence was consistent.

What we tried in between

• Attempt 1 was on a stale base. We then rebased onto a fresh master that included a CI fix.
• Reduced any setup-script complexity. Both attempts ran without a configured setup script (confirmed by the No setup script configured event).
• Confirmed PR is structurally fine: mergeable, no draft, all CI green on the PR after the rebase.

Suggested investigation paths

1. Subprocess silence inside the sandbox: the Claude Code process starts but produces no events. Is its stdout/stderr piped somewhere that's being throttled or not flushed? Are tool_use events serialized to the events stream synchronously, or buffered behind something that's hanging?
2. Diff size threshold: 6608 lines / 23 files is moderate. Is there a per-PR token budget or context-window pre-fill that's stalling the agent before it makes the first tool call?
3. Repo size threshold: the repo is large enough that the local-bundle path was rejected. Is there a memory/disk constraint inside the sandbox that's choking the review agent during context build-up?
4. Specific to this repo's structure: heavy use of pipeline/CLAUDE.md, pipeline/CURRENT_STATUS.md, etc. Many MD files in the diff. Some agents discovery / context-loading step might be timing out without surfacing a failure.

Workaround

We built a local equivalent in 12 Opus sub-agents (6 specialist scanners + 6 cross-verifiers) using the Claude Code SDK. ~25 min wall-clock, paper-based code-tracing instead of sandbox reproduction. Found 2 confirmed P0 operator-visible bugs, 5 P0 test-coverage gaps, 6 P1s, 6 P2s, ~14 P3 nits. The bugs were real and we've fixed them.

This is not a substitute for /ultrareview's sandbox-reproduced verification (which is the higher-signal half of the feature), but it's a viable fallback when the cloud path is broken.

Impact on free-run quota

Two of three free runs (Pro plan, valid through 2026-05-05) were consumed by this bug with zero findings produced. A separate billing/credit request is being filed via the in-app support messenger.

Related

• Memory note from a prior session at feedback_ultrareview_api_not_notification.md (in this account's ~/.claude/projects/.../memory/) flags a different /ultrareview reliability issue: task-notification under-delivers confirmed findings (3 of 7 observed on a separate PR in 2026-04-27). The events-API curl path is the workaround for that one.

[github-actions]

Found 3 possible duplicate issues:

1. Free ultrareview consumed despite 30-minute server timeout (no output returned) #54145
2. /ultrareview cloud session fails with CLAUDE_CODE_OAUTH_TOKEN not set, then silently times out at 30 min — consumes free runs #54181
3. [BUG] /ultrareview consumed free run despite 30-minute timeout failure #49706

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[github-actions]

This issue has been automatically closed as a duplicate of #54145.

If this is incorrect, please re-open this issue or create a new one.

🤖 Generated with Claude Code

[github-actions]

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.