feat(llm): re-add ChatGPT and Copilot on their sanctioned surfaces

[EtienneLescot]

Tracking PR — no changes yet. Opened to hold the design and the checklist for putting the ChatGPT and GitHub Copilot providers back, on the surfaces their vendors actually sanction.

What was removed, and why

release/1.8.0 ships without openai-oauth (ChatGPT) and copilot-proxy (GitHub Copilot). Removed in fix/release-1-8-0-review.

Both reached a user's subscription by presenting the vendor's own OAuth client ID and an editor User-Agent against endpoints reserved for first-party clients:

	client ID we shipped	endpoint	identifying headers
ChatGPT	app_EMoamEEZ73f0CkXaXp7hrann (Codex CLI)	chatgpt.com/backend-api	chatgpt-account-id
Copilot	Iv1.b507a08c87ecfe98 (Copilot editor plugin)	api.github.com/copilot_internal/v2/token → api.individual.githubcopilot.com	User-Agent: GitHubCopilotChat/0.26.7, Editor-Version: vscode/1.96.2

That was in a signed installer distributed via the Microsoft Store and winget, so the exposure landed on our users' GitHub and OpenAI accounts, not just on us. GitHub states plainly that copilot_internal is for its officially supported clients and that using it as a generic model provider violates the Copilot license agreement (community#178117).

Hiding the UI would not have been enough — the constants had to leave the binary.

The sanctioned replacements

GitHub Copilot → Copilot SDK

@github/copilot-sdk, public preview since April 2026. Setup docs.

• Register our own OAuth App (Settings → Developer Settings → OAuth Apps → New OAuth App), enable Device Flow. Self-service, free, no waitlist.
• User authorises; we store their gho_ / ghu_ token (fine-grained PATs also work) in the existing safeStorage blob.
• Requests bill to that user's Copilot subscription, under their own rate limits.
• We own token storage, refresh and expiry — the SDK does not manage the OAuth lifecycle.

⚠️Do not try to keep the old wire path with a new client ID. Our own client ID does not work against copilot_internal — that endpoint only accepts VS Code's, which is precisely why every third-party tool on that path borrows it (hermes-agent#16551, opencode#19338). The SDK is the whole point.

ChatGPT → codex app-server

codex-rs/app-server — the JSON-RPC 2.0 surface behind OpenAI's own VS Code extension.

• We spawn the official Codex binary and speak JSON-RPC over stdio (WebSocket exists but the README marks it experimental and unsupported — do not use it).
• initialize, then thread/start / turn/start / turn/interrupt.
• No client ID ships at all: auth is inherited from the user's own codex login, so their ChatGPT plan is consumed by Codex itself.
• clientInfo.name identifies us to OpenAI's Compliance Logs Platform — set it honestly to openscreen. This is the opposite of the header spoofing we just deleted.

Work

Neither is a header swap: both are agent runtimes (threads/turns/items), while the current provider path is OpenAI-shaped /chat/completions via LangChain. Expect a real adapter for each, and prefer two PRs over one.

• Register the OpenScreen OAuth App; document the client ID and callback URL in the repo (the client ID is public, the secret is not — device flow needs no secret)
• Copilot provider on @github/copilot-sdk, with token storage/refresh in LlmConfigStore
• Codex provider driving codex app-server over stdio, with clientInfo.name = "openscreen"
• Detect Codex CLI: the provider is a detected/not-detected state in settings, not an API-key form. Needs a UX decision — see below
• Re-widen ProviderDefinition["authKind"] (narrowed to "api-key" in the removal) and restore the corresponding provider-card pills
• Restore the i18n keys deleted with the device-challenge screen (pillOAuth, startLogin, openLoginPage, … — 14 keys × 13 locales)
• Update electron/ai-edition/provider-registry.test.ts, which currently asserts these two providers are absent and that no provider points at a first-party-only host. It should keep failing for copilot_internal / chatgpt.com/backend-api — only the "api-key only" assertion should relax

Open questions

1. Codex CLI dependency. Requiring an external binary the user installs and logs into separately is a different UX from pasting a key. Do we detect-and-offer, or hide the provider entirely when Codex is absent?
2. Preview risk. The Copilot SDK is public preview. Acceptable for a provider that is opt-in and not the default?
3. Scope. Which OAuth scopes does the SDK actually need? The docs list token types but not scopes — determine empirically and write it down.

Not blocked on this

The eight API-key providers (Claude, OpenAI, Gemini, Mistral, OpenRouter, MiniMax ×2, OpenAI-compatible) are untouched and cover the same use case for anyone with a key. This is about supporting subscriptions people already pay for — worth doing properly, not worth rushing.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

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: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 90a30baf-61c7-48b0-92dc-ad63e0420b73

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/providers-copilot-sdk-codex-app-server

---

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.}