›_ Claude Code Issues
Claude Code Issues / #95997

Desktop app: auto-merge is hardcoded to github.com, and the PR bar requires manual binding, on GitHub Enterprise Cloud with data residency (*.ghe.com)

Status Fixed / completed
Maintainer reply None cached
Workaround ✓ Mentioned in description ↑
Activity 0 comments · opened Sep 22, 2026 · closed Sep 22, 2026

Environment

  • Claude desktop app: 2.2553.1 (macOS 26.7)
  • gh CLI: 2.100.0, authenticated to <tenant>.ghe.com (gh auth status shows an active account on that host)
  • Repo remote: git@<tenant>.ghe.com:<org>/<repo>.git
  • This is a GitHub Enterprise Cloud with data residency tenant (*.ghe.com), not github.com and not a self-hosted GHES instance.

Expected

The desktop app should surface PR/CI feedback (checks, review state, mergeable status) and support the same PR automation (auto-merge, auto-fix) for a repo hosted on a *.ghe.com tenant as it does on github.com.

Actual

Tested against two separate open PRs on the same *.ghe.com tenant, to separate what's consistently broken from what's PR-specific.

  1. The PR bar never auto-binds, even when checking out a branch that has an open PR. git checkout <branch-with-open-PR> followed by an internal status query still reports no PR bound to the session — binding only happens when the session itself runs gh pr create or pushes to a branch with an open PR, per the app's own tooling. Confirmed on two different PRs (#A and #B in this writeup). An internal bind_pr tool exists specifically to cover this gap and names "GitHub Enterprise host" as one of its motivating cases (alongside fork remotes and PRs opened elsewhere) — which suggests the maintainers are aware auto-detection can miss Enterprise-hosted PRs, though I have not directly compared against equivalent github.com behavior (switching to a branch with an open github.com PR) to confirm this is GHE-specific versus a general auto-detection limitation.
  2. Once manually bound via bind_pr, the underlying data plane works correctly — check counts, review decision and mergeable state were all fetched accurately for both PRs tested. So PR binding and status querying are not blocked by the *.ghe.com host once bound.
  3. Auto-merge ("Fusion automatique quand prêt") is shown disabled (grayed out) in the CI popover for both PRs tested, consistently — and this is not caused by repo or branch-protection configuration. GET /repos/<org>/<repo> on the tenant returns allow_auto_merge: true, and GET /repos/<org>/<repo>/branches/main/protection shows no merge-queue requirement or setting that would otherwise block auto-merge. GitHub's native auto-merge is fully available on this repo; the app still grays it out. This matches an internal tool description stating the feature is "(github.com only)" — an explicit, unconditional host restriction, not a config-dependent one. This is the one finding that reproduced identically across both PRs regardless of their check state.
  4. The CI-checks popover display is inconsistent between the two PRs — not a confirmed systematic bug. For PR A (multiple checks across several workflows: 2 passing, 6 skipped), the popover showed "CI checks unavailable" despite an internal status query returning complete, accurate check data for that same PR. For PR B (a single skipped check), the popover displayed the check status correctly ("Ignoré · 1"). I could not reproduce the "unavailable" state on the second PR, so this does not look like a blanket ghe.com limitation — it may correlate with check volume/type, or be a transient/caching issue unrelated to the host. Flagging as an open question rather than a confirmed root cause.
  5. "Auto-fix CI and address comments" tracks the CI-checks display state rather than being an independent host restriction. On PR A (checks showing "unavailable"), this checkbox was grayed out; on PR B (checks displaying correctly), it was enabled/interactive. This suggests it's gated by whether check data successfully rendered in the popover (finding 4), not by the host itself — unlike auto-merge (finding 3), which stayed disabled on both PRs regardless of check-data state.
  6. "Auto-archive after merge or close" works normally on both PRs — enabled and toggleable in the UI. Not part of any gap.
  7. Raw gh CLI works fine against the tenant when host-aware. gh pr view --json ... and gh pr checks both succeed on <tenant>.ghe.com, correctly resolving the host from git remote.
  8. gh api <path> without an explicit host silently targets github.com. gh api repos/<org>/<repo>/pulls/<n>/comments returns 404 Not Found; GH_DEBUG=api confirms the request goes to https://api.github.com/... instead of the tenant. Passing --hostname <tenant>.ghe.com (or GH_HOST=<tenant>.ghe.com) fixes it. Untested whether any internal comment-fetching path is affected by the same default-host behavior.
  9. No explicit errors in desktop app logs. Searched ~/Library/Logs/Claude/main.log and main1.log for gh, ghe.com, "GitHub App", PR/CI keywords — no matches. Whatever causes finding 4 is silent; nothing is logged when the CI popover fails to fetch checks.
  10. Worktree cleanup is a separate, likely unrelated gap. git worktree prune --dry-run reports several orphaned worktrees created under .claude/worktrees/ that were never pruned automatically. Noted since it was in scope of this investigation, but not clearly tied to the ghe.com issue.

Root cause hypothesis

Two distinct issues, of differing confidence:

  • Auto-merge (finding 3): confirmed hardcoded to github.com. Reproduced identically on two separate PRs; matches the app's own internal tool documentation.
  • PR-bar auto-detection (finding 1): confirmed not to trigger from a branch checkout alone on this *.ghe.com tenant, requiring manual bind_pr. The app's own bind_pr tool description names "GitHub Enterprise host" as a case it exists to cover, alongside fork remotes and PRs opened elsewhere — but I have not directly A/B tested this against a github.com repo, so I can't state with certainty whether github.com auto-binds on a plain branch switch where GHE doesn't, or whether both hosts share the same "only binds after gh pr create/push from this session" behavior. Worth a maintainer confirming the intended behavior on github.com.
  • CI-checks display and the auto-fix checkbox (findings 4-5): inconsistent, not confirmed as host-related. They may share a root cause with each other (auto-fix gating on check-data availability), but the check-data availability issue itself needs more repro data (varying check count/workflow structure, retrying the same PR over time) before pinning it on *.ghe.com specifically.

Workarounds

  • PR tracking: manually bind the PR by URL (via the app's "bind" affordance) instead of relying on auto-detection.
  • Auto-merge: not available on any Enterprise host; merge manually.
  • CI check status: if the popover shows "unavailable", fall back to gh pr checks --hostname <tenant>.ghe.com.
  • Raw API calls: always pass --hostname <tenant>.ghe.com or set GH_HOST=<tenant>.ghe.com.
  • Auto-archive-on-close: works normally, no workaround needed.

Links

---
🤖 Generated with Claude Code

View original on GitHub ↗

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Same class of failure, ranked by community engagement — this issue is one of many, so it may not appear in the visible list: Authentication & login failures

Browse all Claude Code issue topics →