[BUG] /ultrareview fails with "no GitHub remote" on properly configured HTTPS origin (v2.1.119)
Summary
/ultrareview fails with a "no GitHub remote detected" style error on a
repository that has a properly configured HTTPS origin, a validmerge-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.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗