bug(v2): stale stored credential silently overrides provider options.apiKey; auth.json edits ignored after one-time import; no non-interactive key rotation #58394

Activity

1. opencode-agent commented on Oct 23, 2026

   

   opencode-agentBot

   on Oct 23, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed write-up!

   In short, you'd like rotating a provider key to be straightforward and visible: a warning (or configurable precedence) when a stored credential overrides provider.<id>.options.apiKey, and a non-interactive way to replace a stored key, e.g. auth login --api-key, an overwrite flag on auth import, or an in-place update. Maintainers will consider it.

   Some context from the current code:

   • A stored credential winning over options.apiKey is intended. The model resolver drops the config key whenever a credential exists, and the docs describe options.apiKey as for use when you're not using auth. The silent part, with no warning that the two disagree, is a fair point.
   • auth.json is only read by the one-time legacy import. After that the credential table is the source of truth.
   • opencode auth logout takes [target] [credential], and target is the integration. A credential ID passed alone ends up in the target slot. This should work without a terminal:

     opencode auth logout <provider> <credential-id>

     You can then add the new key back. Non-interactive key entry for that step is what [FEATURE]: Support non-interactive API-key login via auth login #57492 covers.

   Related issues:

   • [FEATURE]: Support non-interactive API-key login via auth login #57492: non-interactive API-key login via opencode auth login
   • Provider API key cannot be rotated in place; Edit silently keeps the expired key #58043 (with PR fix(server): allow credential.update to rotate the stored value in place #58066): rotating a stored provider key in place; credential.update currently drops the new value
   • service (v2): serve --service daemon keeps using old OPENCODE_API_KEY after the key is rotated (401 with no hint) #42690: the background serve --service keeps using an old key after rotation
   • providers: stale wellknown API-key wiring in the shared service sends an empty key after auth login/logout #54645: stale API-key wiring in the shared service after auth login/logout
   • bug(v2): SAP AI Core unusable with valid saved credentials — apiKey/serviceKey mismatch blocks authentication #56126: SAP AI Core apiKey/serviceKey mismatch with saved credentials
2. skywalker-35 commented on Nov 11, 2026

   

   skywalker-35

   on Nov 11, 2026

   More actions

   Independently hit this on v2.2.6 (Windows) and can confirm all three problems, plus one extra finding.

   Symptom that made it hard to diagnose: my opencode.jsonc had

   "minimax-cn": {
     "options": {
       "apiKey": "{env:MINIMAX_API_KEY}",   // fresh, valid key — verified 200 via raw curl
       "baseURL": "https://api.minimaxi.com/anthropic/v1"
     }
   }

   but the TUI kept failing with the provider's misleading error insufficient balance (1008). Packet-captured the outgoing request: opencode was sending a completely different, stale sk-cp-... key — the stored credential — and the remote then reported a billing error instead of an auth error, which sent me down a completely wrong path (tested streaming, cache_control, tools, max_tokens... everything, because the same key worked fine via curl).

   Extra finding beyond auth.json: on v2.2.6 there is a second credential mirror, ~/.local/share/opencode/account.json ("version": 2, with accounts / active maps). Editing/deleting entries there does not take effect either while the real source of truth is the credential table in ~/.local/share/opencode/opencode.db. Same silent-override behavior: stored row beats provider.<id>.options.apiKey, with zero warning that the two disagree.

   Non-interactive workaround that worked for me (since no CLI rotation path worked): back up the db, then

   DELETE FROM credential WHERE integration_id = 'minimax-cn';

   then restart the opencode process. After that the {env:...} config key is picked up again and requests succeed. (Full restart of the running instance is required — the server keeps the old key in memory.)

   What would fix this UX-wise, roughly in order of value:

   1. Warn (or fail loudly) at startup when a stored credential and options.apiKey disagree, naming which one wins.
   2. A non-interactive rotation command, e.g. opencode auth login <provider> --api-key <key> / opencode auth logout <provider> that targets the db table.
   3. Log which credential source (db row vs env vs config) was used for each provider request — one line is enough; it would have cut my debugging from hours to minutes.