feat: GitHub Enterprise source control connector

[JorrinKievit]

Closes #5087

What Changed

I solely use GitHub Enterprise, and noticed it was missing here. Figured it wouldn't be that big of a change to support, since they both go through the gh CLI anyway. I haven't recorded a video yet because of privacy company reasons. But can try to record a video later with blurred out data. Also if you don't agree, or this is too risky of a change, feel free to close it :D

Rest of this is AI:

• Discovery — SourceControlCliDiscoverySpec gains an optional expandInstances hook, so a single CLI probe can emit several rows. gh auth status --json hosts produces one github row plus one github-enterprise:<host> row per enterprise host. Every other provider keeps its existing one-row behavior.
• Detection — .ghe.com hosts and github-containing hostnames classify as enterprise. For hostnames that look like nothing in particular (git.acme.internal), the GitHub spec implements the existing refineUnknownRemote hook — the same escape hatch GitLab already uses — and claims a remote whose host matches an authenticated gh host.
• CLI targeting — repo-less gh calls (repo view, repo create) have no remote to infer a host from, so GitHubCli.execute sets GH_HOST when a host is supplied. In-repo calls keep resolving the host from the git remote.
• Threading — host flows through lookup, clone, and publish. Publishing to github-enterprise without a host fails with a clear message rather than silently targeting github.com.
• UI — one "GitHub Enterprise" card; when several hosts are authenticated a secondary radio row picks between them. Matches the radio-card pattern used everywhere else in settings rather than introducing a dropdown.
• Consumers — PR URL parsing, PR template detection, command palette, add-project targets, and the mobile icon all handle the new kind.

Also fixes a latent bug the reclassification exposed: GitManager's PR-template lookup was gated on kind === "github", so a github.acme.com remote would have silently stopped finding .github/pull_request_template.md once it moved to the enterprise kind.

Why

gh already talks to enterprise hosts. The app just never asked it which ones. Today a GHES or GHEC-data-residency remote lands in the unknown bucket, so PR listing, PR creation, publish, and clone are all unavailable to anyone whose work repos live on a company instance — even though the CLI underneath supports them fully.

Separate kind rather than an optional host on github: people are commonly authenticated against github.com plus one or more enterprise hosts at the same time, and discovery rows and settings entries are keyed by kind, so a single github row cannot represent them. This is also the shape Cursor uses — GitHub and GitHub Enterprise as distinct connections, several enterprise connections allowed.

UI Changes

There is no meaningful "before" for these screens — the enterprise host does not appear at all today, so the before state is its absence. After:

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

🤖 Generated with Claude Code

---

Note

Medium Risk
Touches source-control discovery, gh CLI host targeting, and repository lookup/publish paths; contract discovery items now require id, but the change is well-tested and scoped to enterprise GitHub rather than core auth.

Overview
Introduces github-enterprise as a separate source-control kind so users authenticated to github.com and one or more enterprise hosts each get their own discovery row, clone/publish target, and readiness state.

Discovery expands the gh auth probe via expandInstances: one github row plus github-enterprise:<host> per non-github.com host, with stable id and optional host on discovery items. Unknown remotes can be refined to enterprise when the remote host matches an authenticated gh host.

Server / CLI: optional host on lookup, clone, and publish (required for enterprise without host → clear error). GitHubCli sets GH_HOST for host-scoped calls, adds searchRepositories, and derives enterprise clone URLs when repo create prints no URL. Enterprise bare repo names resolve through search with explicit ambiguity handling. PR templates in stacked git actions apply to github-enterprise as well as github.

Clients (web command palette, publish wizard with per-host radios, settings list keyed by id, mobile add-project) use shared AddProjectRemoteTarget / label/readiness helpers and pass host into repository lookup.

Shared: remote URL heuristics split github.com from .ghe.com / github-in-hostname enterprise; PR URL parsing accepts PR links on any host, not only github.com.

^{Reviewed by Cursor Bugbot for commit d4ca396. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add GitHub Enterprise as a supported source control provider

• Introduces github-enterprise as a new SourceControlProviderKind across contracts, server, and client, enabling repository lookup, clone, and publish workflows against self-hosted GitHub Enterprise instances.
• Extends the GitHub CLI integration to forward a host via GH_HOST env var and adds searchRepositories for resolving bare repo names on enterprise hosts.
• Discovery via gh auth status now emits distinct provider rows per authenticated enterprise host, surfacing them in the Add Project and Publish Repository dialogs.
• The Publish Repository dialog lists available enterprise hosts, shows per-host authentication readiness, and passes the selected host to the publish action.
• Broadens GITHUB_PULL_REQUEST_URL_PATTERN to match PR URLs on any host, not just github.com.
• Risk: detectSourceControlProviderFromRemoteUrl now classifies non-github.com GitHub-style hosts as github-enterprise instead of github, which is a breaking change for any code that assumed github.com-only classification.

^{Macroscope summarized d4ca396.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 0c66b113-e177-4a86-ae11-2f48f3d7ed47

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Reviewed the Effect service changes (GitHubCli, GitHubSourceControlProvider, SourceControlProvider*, registry/discovery). Service definition order, make/layer exports, namespace imports, environment-based dependency acquisition, and Schema.TaggedErrorClass usage all look consistent with the conventions. One error-attribute safety issue noted inline.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Needs human review

2 blocking correctness issues found. This PR introduces a new feature (GitHub Enterprise source control connector) with significant new logic and UI flows. Additionally, two high-severity unresolved review comments identify potential bugs in repository resolution and host selection logic that warrant human attention.

^{You can customize Macroscope's approvability policy. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 17f7304. Configure here.}

[macroscopeapp]

🟠 High sourceControl/GitHubSourceControlProvider.ts:234

resolveRepositoryReference clones the wrong repository when an enterprise search for a bare name like core returns only fuzzy matches (e.g. owner/core-documentation). pickRepositorySearchMatch falls back to results[0] when no result's repo-name segment exactly equals the query, so resolveRepositoryReference silently resolves to an unrelated repo instead of reporting that core was not found. Consider returning _tag: "none" when no exact repo-name match exists, rather than falling back to the first search result.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/server/src/sourceControl/GitHubSourceControlProvider.ts around line 234:

`resolveRepositoryReference` clones the wrong repository when an enterprise search for a bare name like `core` returns only fuzzy matches (e.g. `owner/core-documentation`). `pickRepositorySearchMatch` falls back to `results[0]` when no result's repo-name segment exactly equals the query, so `resolveRepositoryReference` silently resolves to an unrelated repo instead of reporting that `core` was not found. Consider returning `_tag: "none"` when no exact repo-name match exists, rather than falling back to the first search result.

[JorrinKievit]

Tightened in d4ca396, though not quite to _tag: "none".

Accepting a bare name at all is the feature here — enterprise users type core, not team-a/core — so refusing everything without an exact repo-name match would remove the reason the search path exists. What was actually wrong is narrower: ranking between near matches. results[0] was search relevance standing in for a decision only the caller can make.

So: exactly one exact match wins; a sole near match still resolves; anything else fails with the candidates listed. widget against Sollit/widget-service + Sollit/mywidget now errors instead of silently taking the first, which is the case your example describes. The old test asserting that arbitrary pick is replaced by two tests covering both branches.

[macroscopeapp]

Sorry, I'm unable to act on this request because you do not have permissions within this repository.

[macroscopeapp]

🟠 High components/GitActionsControl.logic.ts:469

resolveSelectedEnterpriseHost returns a fallback host without persisting it, so a stale selectedHost silently retakes priority on the next call. When the selected host becomes unready, the function returns a ready fallback; but on a later discovery pass where the original host becomes ready again, the unchanged selectedHost causes the result to switch back to the original host automatically. In the publish dialog this can change currentPublishProvider.host while the user is on a later wizard step, so submission may target the originally-selected host even though the UI previously fell back to a different one. The fallback should become the persisted selection, or stale selections must not regain priority once they've been superseded.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/web/src/components/GitActionsControl.logic.ts around line 469:

`resolveSelectedEnterpriseHost` returns a fallback host without persisting it, so a stale `selectedHost` silently retakes priority on the next call. When the selected host becomes unready, the function returns a ready fallback; but on a later discovery pass where the original host becomes ready again, the unchanged `selectedHost` causes the result to switch back to the original host automatically. In the publish dialog this can change `currentPublishProvider.host` while the user is on a later wizard step, so submission may target the originally-selected host even though the UI previously fell back to a different one. The fallback should become the persisted selection, or stale selections must not regain priority once they've been superseded.