dsh-gemini-oauth-bridge

Usage

1. Click 登录 Google 账号 (Log in with Google) and finish the flow in your browser. The plugin temporarily listens on 127.0.0.1:51121 for the loopback callback — this exact redirect URI is registered for the Antigravity client and the port cannot change. Port conflicts are reported explicitly.
2. After login the page shows the account, project ID, tier, and model list.
3. Register the bridge as a DSH provider in ~/.dsh/settings.yaml (port matches your DSH web URL, default 3080):

llm-pi-ai:
  providers:
    gemini-oauth:
      api: openai-completions
      baseURL: http://127.0.0.1:3080/gemini-oauth-bridge/v1
      apiKeyEnv: GEMINI_OAUTH_API_KEY
      models:
        - id: gemini-3.1-pro-high
        - id: gemini-3.7-flash-high

4. Pick the models in the model selector. Step 3 is usually unnecessary: logging in and refreshing the model list write this block automatically (the baseURL port follows the address you use to open the DSH UI). On DSH ≥ 0.2 the plugin edits the llm-pi-ai entry through the settings service — the same path the DSH Models page uses — so the refreshed model list is hot-applied to the running process and persisted into the active profile's cordis.patch.yml; no restart is needed. Older DSH versions get the legacy ~/.dsh/settings.yaml write, which takes effect at the next restart. DSH refuses a provider profile that declares no credential, so the plugin also provisions the matching GEMINI_OAUTH_API_KEY entry in ~/.dsh/.credentials.yaml (mode 0600) with the fixed placeholder dsh-gemini-oauth-bridge — an existing entry is never overwritten, and the bridge accepts any bearer token. To use your own key instead, set it through the Models page; to add local auth to the bridge itself, set "apiKey": "some-string" in ~/.dsh/gemini-oauth-bridge.json — requests must then carry Authorization: Bearer .

Local state

~/.dsh/gemini-oauth-bridge.json (mode 0600, contains OAuth tokens — treat as a secret):

Field	Meaning
tokens	access/refresh tokens and expiry
email / project / tier	login account and registration result
models	upstream model cache (refreshable from the UI)
modelCaps	per-model contextLength / maxCompletionTokens read from the upstream catalog
modelsUnavailable	ids the upstream catalog marks disabled, with the upstream explanation shown when such a model is requested
trustedHosts	extra host:port authorities the browser-trust fence accepts (for non-loopback deployments); loopback is always accepted
signatures	thoughtSignature replay cache (by tool-call id, cap 800)
apiKey	optional local auth for the bridge endpoint
apiConfig	optional upstream overrides (generateBase / loadBase / onboardBase); defaults match CLIProxyAPI: generation via daily, registration via prod