GitHub Copilot: Enterprise sign-in impossible, and inference host is pinned to api.githubcopilot.com

[ivseb]

The GitHub Copilot provider pins two things that are not actually constant, which makes it unusable on GitHub Enterprise and sends non-Individual tokens to the wrong host.

Branch with the change:
main...ivseb:feat/copilot-enterprise

(Opening this as an issue rather than a PR — pull request creation is rejected on this repo, same as #78.)

The two problems

1. The inference host is not always api.githubcopilot.com. Copilot routes Individual, Business and Enterprise subscribers to different hosts. The host is carried in the Copilot token itself as proxy-ep=proxy.<tenant>.githubcopilot.com, and the token-exchange response can also name it directly — CopilotTokenResponse.endpoints.api is already declared in GitHubCopilotAuthService.ts but never read. Today baseURL is hardcoded, so anything other than an Individual subscription talks to a host its token does not belong to.

2. Enterprise deployments serve OAuth and token exchange from their own domain. DEVICE_CODE_URL, ACCESS_TOKEN_URL and COPILOT_TOKEN_URL all point at github.com / api.github.com, so on a GitHub Enterprise Server or GHE.com account sign-in cannot complete at all.

What the branch does

Resolves the inference host per request, most authoritative source first:

1. endpoints.api from the token response (declared, previously unused)
2. the proxy-ep field inside the token — survives a restart, since the token is persisted
3. the configured deployment, else the existing github.com default

This is applied inside getCopilotFetch() rather than the constructor, because the OpenAI SDK pins baseURL at construction time — before any token exists, and it would never pick up a host change on refresh.

Adds an optional githubCopilotEnterpriseDomain setting (a field next to the existing custom client ID, empty = github.com). Device-flow and token-exchange URLs are derived from it, and it handles both Enterprise conventions, which differ:

Deployment	Token exchange
github.com	https://api.github.com/copilot_internal/v2/token
GHE.com (Enterprise Cloud, data residency)	https://api.<domain>/copilot_internal/v2/token
GitHub Enterprise Server (self-hosted)	https://<host>/api/v3/copilot_internal/v2/token

Input is normalized, so pasting https://github.acme.com/ or github.acme.com both work.

Defaults are unchanged. An empty domain reproduces the previous URLs exactly, so existing Individual setups are byte-for-byte unaffected — the only behavioural change for them is that the host now comes from their own token instead of a constant, which resolves to the same value.

Verification

npm run typecheck clean, eslint clean on the five touched files, production build succeeds. URL construction and proxy-ep extraction checked for github.com, GHES and GHE.com.

What I have not done: run it against a live Enterprise instance. The endpoint shapes follow GitHub's documented conventions (/api/v3 for GHES, api. subdomain for GHE.com), but they are not yet confirmed end-to-end. I do have access to a GitHub Enterprise Server instance and I'm happy to test the branch there and report back before you take any of it — just say the word and I'll do that first.

Tests

Same situation as #78: there are no *.test.ts files in this repository, so I couldn't extend the suite. normalizeEnterpriseDomain(), copilotEndpoints() and apiBaseFromCopilotToken() are exported as pure functions specifically so they're trivial to unit test — happy to write those if you tell me where they should live to match your private tree.

Smaller thing spotted nearby

CopilotTokenResponse.endpoints was typed but never read. The branch now uses it as the first-choice host; if it was left unused deliberately, drop that line and the proxy-ep fallback still covers every case I could find.

[ivseb]

Quick status before you spend any time on this: I am validating the branch against our own GitHub Enterprise Server instance first — real device flow, real token exchange, and an actual completion — and I will report back here either way, including if the endpoint shapes turn out to be wrong.

Please treat the branch as a proposal under test until then rather than something ready to take.

[ivseb]

Field-tested now, on a real .ghe.com Enterprise tenant: sign-in completes and chat works end to end. The device flow reaches the enterprise host, token exchange succeeds against api.<domain>/copilot_internal/v2/token, and inference lands on the proxy-ep host carried in the token. That closes the "not confirmed end-to-end" caveat in the original post — the endpoint shapes hold in practice, not just on paper.

Two fixes came out of the testing and are on the branch:

• Settings never reached the auth service. loadFromSettings() runs once at plugin load and the settings UI only wrote to the settings object, so sign-in kept going to the public host no matter what was configured. This is pre-existing and also affects the custom client ID field, which never took effect either.
• The enterprise host field was missing from the onboarding path. ModelConfigModal has its own sign-in button, so a first-time user could not configure a deployment before signing in.

Also made the device code selectable inline rather than only in a Notice — the Notice dismisses on click, taking the code with it.

---

Separately: /embeddings does work on Copilot

While testing the above I looked into the FEATURE-1204 open question in src/ui/settings/constants.ts:

// Note: github-copilot excluded — Copilot API does not support /embeddings endpoint (FEATURE-1204 open question)

It does support it. Verified on the same tenant: the catalogue lists embedding models, the connection test returns vectors, and a semantic index build over real notes completes.

The 400 that presumably motivated the exclusion is real and reproducible — but its cause is the request, not the route:

the gateway rejects input as a bare string and accepts it as an array.

That turns out to be a bug wider than Copilot. embedBatchViaSdk has always sent an array; testEmbeddingViaSdk sends input: 'test'. OpenAI accepts either, so the difference is invisible there — but against any strict OpenAI-compatible gateway the Test button fails on a request the indexer would have got right, reporting a broken endpoint to a user whose setup is fine. Reachable today with a custom provider, without Copilot being involved at all.

Branch: main...ivseb:feat/copilot-embeddings

Two commits, deliberately separable:

1. fix(embeddings): send the connection-test input as an array — one line plus a comment. Stands alone, applies to main, needs none of the Copilot work. Worth taking regardless of what you think of the rest.
2. feat(copilot): enable GitHub Copilot as an embedding provider — stacks on the enterprise branch because it needs getApiBaseUrl().

The second one is small, because the embedding machinery was never the blocker: EMBEDDING_PROVIDERS is read in exactly one place, to populate the provider dropdown. It is a UI filter, not an engine restriction. Beyond re-adding the provider, it needs a fetchEmbeddingModels branch reading capabilities.type from the same listModels() the chat side calls (the chat mapping drops that field, so it could not be reused), and the same getApiBaseUrl() + getCopilotFetch() pair the chat provider already uses.

No static Quick Pick entry on purpose — embedding ids differ per tenant, and a wrong guess would aim the test at a model that does not exist and then read the 404 as an endpoint failure. Fetch reads the real catalogue.

Small thing spotted alongside: GitHubCopilotAuthService.getCopilotHeaders() carries the comment "for embedding requests etc." and has no callers — looks like this path was started once and left unfinished.

Happy to split the embeddings work into its own issue if you would rather keep this one scoped to Enterprise auth — say the word and I will move it.

npm run typecheck clean, eslint clean on the touched files, production build succeeds. Same tests situation as before: no *.test.ts in this repo, so I could not extend the suite, but the pure helpers are exported and trivial to cover if you tell me where they should live.