[BUG] /ultrareview fails with "no GitHub remote" on properly configured HTTPS origin (v2.1.119)

Resolved 💬 3 comments Opened Apr 24, 2026 by Ryo-Takaoka Closed Apr 27, 2026

Summary

/ultrareview fails with a "no GitHub remote detected" style error on a
repository that has a properly configured HTTPS origin, a valid
merge-base with main, and a live GitHub Pull Request. All four
documented invocation styles fail:

  • /ultrareview (no args)
  • /ultrareview main
  • /ultrareview origin/main
  • /ultrareview <PR#> (where the PR exists on origin)

Tried variants cover the full surface documented in v2.1.86+ release notes.

Environment

  • Claude Code: 2.1.119
  • OS: macOS (Darwin 25.1.0)
  • Shell: zsh
  • Repo: private, HTTPS origin on github.com
  • Branch under review: a 13-commit feature branch diverged from main
  • Target PR: a live Draft PR (base=main, head=feature branch)

Local verification — all healthy

$ git merge-base main <feature-branch>
<commit>                            # succeeds

$ git remote -v
origin  https://github.com/<owner>/<repo>.git (fetch)
origin  https://github.com/<owner>/<repo>.git (push)

$ git config --get branch.main.remote    # origin
$ git config --get branch.main.merge     # refs/heads/main
$ git symbolic-ref refs/remotes/origin/HEAD    # refs/remotes/origin/main

$ gh repo view --json name,owner
{"name":"<repo>","owner":{"login":"<owner>"}}    # gh authenticated

Nothing in the local environment suggests a broken remote.

Expected

/ultrareview should detect origin on https://github.com/... and
proceed with the cloud review, either on the working diff or the
specified PR.

Actual

The command returns immediately with a "no GitHub remote" / "no GitHub
project context" style failure. All four argument shapes produce the
same class of error.

Workaround

Fell back to a local multi-agent review flow. No cloud review was
possible on this repo in this session.

Related issues

  • #49458 — similar symptom shape but the reported error is about

merge-base with main, which succeeds in our case

  • #49534 — feature request to add directory validation
  • #49510 — commands not visible despite eligibility
  • #50029 — empty findings on large repos (different failure mode)

None of the above are exact matches: in our case the command is
visible, quota is available, merge-base does resolve, and the
remote is a standard HTTPS GitHub origin — yet detection still fails.

Note

The exact error string from the CLI was not captured verbatim in the
failing session. Following the reproduction above on any similarly
configured HTTPS-origin repo with a live PR should reproduce it; happy
to capture the precise output on request.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗