fix: keep claude-cli identity for GitHub Copilot (PR #976)

[Vasanthdev2004]

Summary

Fix for PR #976 — GitHub Copilot whitelists claude-cli but may not whitelist openclaude-cli. This change keeps the upstream-compatible identity for GitHub Copilot connections.

Changes

• Added getAPIProvider() === 'github' to the requiresCompatibilityIdentity check in src/utils/http.ts
• GitHub Copilot now keeps using claude-cli identity (whitelisted)
• Kimi Code keeps using claude-cli identity (already handled)
• All other providers use openclaude-cli identity (new branding)

Why

Without this fix, PR #976 will break GitHub Copilot connections because:

1. getAPIProvider() returns 'github' for Copilot
2. shouldUseFirstPartyAuth() returns false (not 'firstParty')
3. getProviderApiUserAgent() would send openclaude-cli/0.11.0
4. Copilot might not whitelist openclaude-cli

Testing

After applying:

1. Set OPENAI_BASE_URL=https://api.githubcopilot.com and GITHUB_TOKEN=<token>
2. Run any query — should work with claude-cli identity
3. Check logs for User-Agent: claude-cli/...

Related

• Fixes: PR Route API User Agents by Actual Provider Target #976
• Author: @jatmn

[gnanam1990]

Thanks for flagging the Copilot identity concern and putting up a focused fix — the routing split itself is clean and the tests pass locally (bun run build, bun test src/utils/http.test.ts src/utils/userAgent.test.ts all green).

I can't take this in its current form, for two reasons.

1. The Copilot identity change needs empirical proof, not an assumption.
openclaude is an independent community fork, and the entire point of the rebrand is to stop presenting the Anthropic claude-cli identity to external providers. Pinning Copilot back to claude-cli re-introduces exactly that fingerprint. The PR description says Copilot "may not whitelist openclaude-cli" and the code comment itself reads "...may not whitelist openclaude-cli — keep compatibility until confirmed." That is the open question stated as the justification — we'd be perpetuating the upstream identity on something explicitly not yet confirmed.

Separately, our own Copilot path doesn't appear to gate on the User-Agent at all: src/services/api/openaiShim.ts:99-104 sends Copilot-Integration-Id: vscode-chat / Editor-Version / Editor-Plugin-Version (mirrored in deviceFlow.ts and cache-probe.ts), and those are hard-applied to Copilot requests at openaiShim.ts:1827. So the premise that Copilot whitelists by the claude-cli UA string has no supporting evidence even in our own code.

Could you either: (a) provide a concrete repro — set OPENAI_BASE_URL=https://api.githubcopilot.com with a real Copilot token, send one request with openclaude-cli/... and one with claude-cli/..., and paste the HTTP status code + response body for each (a 401/403 on openclaude-cli vs 200 on claude-cli would settle it), or cite an authoritative Copilot API doc/issue requiring the UA; or (b) rework so Copilot uses the openclaude identity (and, if a header is genuinely required, set the appropriate Copilot integration header rather than the Anthropic CLI UA). If the repro shows Copilot really does reject openclaude-cli, I'm happy to revisit with that evidence.

2. Branch scope. This PR targets main but carries the six commits from #976, which is still open with changes requested and explicitly blocked pending the moonshot/KimiCode confirmation in its own description. Merging this would pull #976 in ahead of that. Please rebase so this contains only the Copilot change (and let's land it on top of #976 once #976 is unblocked), and add a test asserting the github provider emits the expected identity so the new branch is covered.

Appreciate the work here — happy to move quickly once there's a repro or the reworked approach.