CI monitoring reports a misleading gh-auth error when the PR isn't in the current directory's repo

Status Open
Maintainer reply None cached
Activity 1 comment · opened Jul 20, 2026

Summary

The CI monitoring panel resolves the PR (and its checks) from the repository of the current working directory. When the current branch/repo has no matching PR, the panel falls back to:

CI checks unavailable — Check that gh is installed and authenticated.

…and greys out Auto-fix CI and Auto-merge when ready. But gh is installed and authenticated, and CI monitoring works fine when gh is pointed at the repository that actually holds the PR. The panel misattributes a "no PR found for the current repo" situation to an authentication problem, which sends you off debugging the wrong thing.

Steps to reproduce

  1. Open Claude Code with the working directory set to repo A, whose current branch has no open PR.
  2. Have the PR you're actually working on live in a different repository, B.
  3. The CI monitoring panel shows "CI checks unavailable — Check that gh is installed and authenticated".
  4. In a terminal, gh pr checks <number> -R B succeeds and shows the CI status — proving gh is fine and the PR/checks are reachable.

A concrete setup where this always happens

A "meta-repo" layout: the workspace root is a git repo that only versions orchestration/specs, and each code project is a separate nested git repo in a subfolder, each with its own remote, ignored by the root repo. Claude Code runs at the root, but every code PR lives in one of the nested sub-repos, which the panel never inspects. The panel only ever sees the root repo (which has no code PRs), so CI monitoring is permanently "unavailable".

It isn't limited to that layout — it's any time the PR isn't in the cwd's repo (e.g. launching from a parent directory, or a repo whose PR was opened from a fork).

Suggestion

  • Use a distinct message for "no PR found for the current branch/repo" vs. "gh is not installed/authenticated" — they point to completely different fixes.
  • Optionally, let the user associate or configure the target repo for CI monitoring, or detect nested git repositories under the working directory.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗