[BUG/UX] 'Pull request status couldn't be checked' warning fires on every non-GitHub remote (GitLab/Bitbucket/Gitea/self-hosted)

Summary

The "Pull request status couldn't be checked and may be out of date" warning fires on every Claude Code interaction when working in a repo whose origin remote points to a non-GitHub host (self-hosted GitLab CE in my case, but the same applies to Bitbucket, Gitea, sr.ht, Codeberg, etc.). The warning is purely cosmetic for these users — gh simply can't introspect the remote — but it reads as a real failure that needs investigation.

This is distinct from #12346 (umbrella request for GitLab integration). I'm NOT asking you to support GitLab. I'm asking you to detect that the remote isn't GitHub and suppress the GitHub-specific UI element gracefully, instead of surfacing a warning the user can't resolve.

Reproduction

cd /path/to/any/non-github-repo
git remote -v   # confirms origin points to gitlab.example.com or similar
# Open Claude Code → the PR-status warning fires immediately

gh from the same cwd correctly identifies the situation:

$ gh repo view
none of the git remotes configured for this repository point to a known GitHub host.
To tell gh about a new GitHub host, please use `gh auth login`

So the data needed to suppress the warning is already available.

Expected behaviour

When the current repo's origin (or all remotes) point to a non-GitHub host:

1. Don't attempt the GitHub PR-status check (or do it and fail silently)
2. Don't surface the warning in the status bar
3. Optionally: show a one-time hint that GitHub-specific features are unavailable for this repo, then never again

Why this matters / the broader principle

Source-code hosting is a competitive space — GitHub, GitLab (cloud + self-hosted CE), Bitbucket, Gitea, sr.ht, Codeberg, Forgejo all have meaningful adoption. Self-hosted Git is especially common in regulated industries, homelabs, governments, and orgs avoiding supply-chain risk concentration.

Claude Code's UX baseline shouldn't assume one platform. It's fine to have GitHub-only features (that's a reasonable scoping decision), but those features should fail gracefully and silently on non-GitHub remotes — not surface warnings that imply the user has a problem to fix.

Concretely, I'd love to see this same principle applied across the surface:

• PR status check (this issue)
• /review and --from-pr (per closed #52604)
• Any future gh-backed feature

Context

I'm running an 8-repo self-hosted GitLab CE substrate (gitlab.home.therileys.team). Each Claude Code session shows this warning constantly. The substrate's release pipeline doesn't use gh at all — it drives the GitLab API directly via curl + a PAT in our wrapper. Works great. The warning is the only noise.

Related

• #12346 (umbrella GitLab integration request — different ask)
• #38179 (Bitbucket — same shape of problem)
• #52604 (docs already noted --from-pr is GitHub-only — closed)

Thanks for considering!