[BUG] Ultrareview PR mode: unreachable private repo fails as `Session initialization failed` after showing `Cloned repository ✓`, and burns a free run

Summary

Two /code-review ultra <PR#> runs against a private, personally-owned repository failed with Session initialization failed. No reviewer agents ran. The two attempts were several months apart — the first was my initial try at the feature, the second was the first time I revisited it — so this has survived many releases in between.

The cause was that my claude.ai GitHub connection could not see private repositories. /web-setup fixed it completely. None of that was discoverable from the error, which reported a successful clone and gave no indication GitHub access was involved.

The failure is silent and misdirecting in three specific ways:

1. PR mode doesn't preflight the GitHub access it depends on. The target repo is known before provisioning. The access check could run first and fail with actionable text.
2. Cloned repository ✓ is displayed while the required grant is missing. That checkmark actively pointed diagnosis away from GitHub.
3. Each failed attempt consumed one of the three one-time free runs, despite no review work being performed.

Environment

| | |
|---|---|
| Claude Code version | 2.1.228 (2nd run); unknown but several months older for the 1st |
| Platform | macOS (darwin 24.6.0), zsh |
| Plan | Pro |
| Repository | private, owned by a personal account (not an org) |
| Command | /code-review ultra <PR#> |
| Failed session (1st) | session_01RnqhQhg7Cy9xT1HzZ7Jqgj — several months ago; exact timestamp is on the session record |
| Failed session (2nd) | session_018iKCfFSNVwLawoESo73rpV — 2026-08-11 |

What happened

Both runs failed immediately and in the same way, despite the months and releases separating them. The session detail page showed:

Initialized session
  ✓ Set up a cloud container
  ✓ Cloned repository
  ⊘ Run setup script        ("Add a setup script to install dependencies and configure your environment.")
  ⊘ Start Claude Code

Session couldn't start
This session hit an error it can't recover from. Start a new session to continue.

Session initialization failed

<img width="563" height="593" alt="Image" src="https://github.com/user-attachments/assets/e6173e72-6174-41ef-a235-7ede4fadc986" />

Claude Code never launched. The environment was the stock Default one — Trusted network access, no environment variables, no setup script — so the documented "setup script exits non-zero → session fails to start" path does not apply.

Root cause and the fix

The repository is private, and my claude.ai GitHub connection could not see private repositories. Confirmed after the fact: the repo did not appear in the repository list at claude.ai/code.

Running /web-setup in the CLI resolved it. After that, the repo appeared in the web repo list and a plain cloud session against it started and ran normally.

Why this was hard to diagnose

• The local gh token was never the problem. It carried gist, read:org, repo scope throughout and could read the private repo fine at every point. Nothing locally suggested a credential gap.
• claude --cloud succeeded while ultrareview failed. I used a claude --cloud "..." canary to test whether cloud sessions worked at all. It succeeded — almost certainly via the documented fallback that bundles and uploads the local repo when GitHub access isn't available. That fallback routed around the exact broken grant, making the infrastructure look healthy and sending diagnosis in the wrong direction. Ultrareview PR mode has no such fallback, since it clones the PR from the host. This asymmetry means the CLI can look completely healthy while the web-side grant is broken.
• Cloned repository ✓ contradicted the actual cause. Whatever that step reports, it isn't the access path PR mode ultimately depends on. A checkmark there while the underlying grant is missing is worse than no signal at all.
• Nothing in the repo or local environment explained it. Small repo (41MB), no submodules, no LFS, no .mcp.json, valid .claude/settings.json containing only PreToolUse/PostToolUse hooks (which fire on tool use, well after boot), current CLI, and no incidents on status.claude.com.

Total time to diagnose: roughly an hour, most of it spent ruling out repo-side and infrastructure causes that the error message left open.

Suggested fixes

1. Preflight the GitHub access check before provisioning. PR mode knows the target repo up front. Verifying reachability first would turn this into an instant, actionable failure — ideally naming /web-setup or the GitHub App directly.
2. Make the checklist reflect real state. If the clone step's ✓ can coexist with a missing grant, it should not display as success.
3. Don't consume free runs for sessions that never reach review work. Documented policy counts a run "once the cloud session starts," and a VM was indeed provisioned — but no reviewer agents ran and no output was produced. Spending a one-time, non-refreshing allotment on a preventable config gap is a harsh outcome, particularly when a preflight check could have caught it before launch. It also discourages users from ever trying the paid feature, for fear of getting burned again, which undermines the point of a free demo allotment. In my case that is not hypothetical: after the first failure burned a run and told me nothing, I did not touch the feature again for months.

Prior art

#73369 (open since 2026-07-02, no comments) reports a GitHub access failure from a different point in the flow — that one fails before any container or clone, with an explicit GitHub repository access check failed — re-authorize GitHub in settings.

That message is exactly the right one for my situation too. Same class of problem, but one path produces an actionable error and the other produces Session initialization failed after a misleading ✓. Whatever check generates that message doesn't appear to run on the path these sessions took.