English | 简体中文
dsh-vendor-login
Sign in to AI coding plans that have no API key at all — Claude Pro/Max/Team, ChatGPT Plus/Pro, GitHub Copilot, SuperGrok — with your own subscription account, straight from the dsh settings UI. Run each vendor's plan on its included quota instead of paying by token.
Vendors that do hand out API keys are deliberately not covered: configure those with an apiKeyEnv on dsh's Models page.
⚠️ These OAuth tokens are issued for each vendor's own clients. Reusing them in a third-party harness is a grey area — possible ToS violations, rate limits, or bans. This plugin drives the vendors' own OAuth/device-code flows and tokens stay on your machine. Whether to use it is your call.
Supported vendors
| Vendor | Sign in with | Why there is no API key |
|---|
Anthropic (anthropic) | OAuth — loopback port 53692, or paste back the code | Pro/Max/Team quota works only via Claude sign-in; ANTHROPIC_API_KEY bills against Console separately |
OpenAI (openai-codex) | OAuth — loopback port 1455 | ChatGPT Plus/Pro quota works only via "Sign in with ChatGPT"; the API platform bills separately |
GitHub Copilot (github-copilot) | Device code — github.com/login/device | Copilot issues no API keys; third parties get device-code OAuth only |
xAI (xai) | Device code — auth.x.ai | SuperGrok / X Premium+ quota is OAuth-only; console.x.ai credits are a separate track |
Requirements
-
dsh 0.1.2-rc.1 or newer (dsh on PATH) and pnpm on PATH. That release added the Models-page extension slots this plugin renders into; on anything older it registers nothing and no sign-in appears.
On an older dsh, install the 0.1.x line instead — same vendors, same flows, and the sign-in lives in its own card under Settings → Plugins rather than in the Models page:
dsh plugin --profile web add dsh-vendor-login@^0.1.1
-
The web profile — the sign-in only appears in the dsh Web UI.
-
A browser for authorization. The two loopback flows need ports 53692 and 1455 free on this machine; the two device-code flows listen nowhere, so the browser can be anywhere.
Install
dsh plugin --profile web add dsh-vendor-login
Then restart dsh web. From source: pnpm install && pnpm build, then dsh plugin --profile web add -w ..
Use
Open Settings → Models. Every vendor below has its own provider card there, and this plugin adds a sign-in area to the bottom of each one:
- Click the card's sign-in button and finish the authorization in your browser.
- If a flow asks you to paste back a code or pick an account, do it right in that card.
- On success that vendor's models appear in the model picker immediately — the plugin writes the route into
llm-pi-ai for you.
Provider cards pi-ai ships that this plugin does not cover get no sign-in area at all — they are API-key providers, and their card's own key field is the way to configure them.
Sign out deletes the stored credential locally; it does not revoke anything on the vendor side — do that from the vendor's account page. A route you have customized since (your own baseURL, apiKeyEnv, models edits) survives sign-out.
Configuration
Which providers get a sign-in area is controlled by vendors under the vendor-login namespace, defaulting to all four vendors above. There is no settings card for it — edit it in the profile's settings file:
vendors: [anthropic, openai-codex, github-copilot, xai]
Entries must be provider ids that pi-ai ships a login flow for; anything else shows an inline error instead of a dead button.
Notes & limitations
/plugin/vendor-login/* has no authentication of its own — unlike /api, which sits behind apiproxy. What stands in for it is a cross-site check: requests are rejected unless Sec-Fetch-Site/Origin say they came from dsh's own page, and every POST must be application/json (the one content type a page cannot post cross-site without a preflight). That closes drive-by sign-out and drive-by flow-starting from any page you happen to have open. It is not authentication: binding webServer beyond localhost still exposes these routes to anyone who can reach the port, and the plugin warns at startup when you do.- A login lives in an open connection: refreshing the page mid-login restarts that flow.
- One attempt per vendor at a time; a second window gets rejected with
ALREADY_IN_FLIGHT.
- xAI may gate its OAuth surface by plan tier — some standard SuperGrok accounts can complete login but get HTTP 403 on inference (example). If so, use a
console.x.ai API key via the Models page instead.
Found a bug, or did a vendor's login policy change? Open an issue.
License
MIT
