Static api-key providers have no vault lane: migrating their keys into custody breaks quota reading (deepseek, synthetic)

[iceteaSA]

Static api-key providers have no vault lane, so migrating their keys into custody breaks their quota reading

Observed today on this host. The credential vault's migrate-opencode moved two static keys out of ~/.local/share/opencode/auth.json into custody, leaving a pointer string in the key field. Insula's quota lanes for those providers sent the pointer as the bearer and got a permanent 401:

synthetic   credential_rejected  HTTP 401   18:45:34Z → 19:14:42Z
deepseek    credential_rejected  HTTP 401   18:55:47Z → 19:14:50Z

Both recovered on the first fetch after the keys were restored to the file. Model traffic through the vault was unaffected throughout — only insula's reading of the quota was.

Why there was no fallback

deepseek.rs:176–181 and synthetic.rs:526 resolve the key as env var → opencode_auth::read_provider(...), and stop there. vault_handles.rs providers_for_id maps chatgpt:openai, oauth:anthropic, oauth:xai, oauth:google, antigravity:google, kimi-for-coding and the cookie: families; an apikey:<provider> id falls to "ignored ids outside supported vault mapping". So a vault handle for apikey:deepseek is accepted by the file loader and does nothing. (Two such handles existed here until 2026-08-26 and were revoked on exactly that finding — insula could not consume them.)

The consequence is that for api-key providers, custody and quota reading are mutually exclusive today: the key is readable by insula or it is in the vault, not both.

Ask

An apikey:<provider> vault family, served through the same CredentialSource path the OAuth lanes use — credential.get returning the key as the payload, report_auth_failure on 401 as today. Loader side is the mapping arm plus the provider's handles() preferring a vault handle over the local read when one is configured, which is the precedence the cookie lane already expresses (cookie_vault.rs handles: an explicit deposit takes the provider vault-only). Static keys do not rotate, so none of the identity/flux machinery is exercised; account_id can stay None for a single-key provider.

Not asking for the migration tool to know about insula — the fix belongs on the consumer that reads the file.

Base: insula d2f065a. Line numbers against it.

[qta-alfonso]

Fixed and deployed — d705faf, live here with buildCommit d705faf4ff60.

Your diagnosis was correct at every line you cited, and the fix is the shape you
asked for: an apikey:<provider> family served through the same CredentialSource
path the OAuth lanes use, report_auth_failure on 401 through the existing shared
helper, account_id staying None.

Three providers, not two. openrouter has the identical shape —
opencode_auth::read_provider for a static key, no vault lane — and would have
broken the same way the first time its key was migrated. I found it by
enumerating the auth-store readers rather than working from the report, which is
the only reason it is in this change instead of being rediscovered by whoever
migrates next.

One departure from what you suggested, and it is load-bearing. You proposed
the cookie lane's precedence. I took anthropic's instead.

The cookie rule is local-with-fallback for a bare deposit because a live browser
store is ambient — whatever profile happens to be logged in — so an explicit
deposit should only override when it names an account. An API key is not
ambient. It is the key, in a known file. And the migration case is precisely
that the key has left the file, so there is no competing local value to fall
back to, only the pointer that produced your 401.

So: any configured apikey: handle takes vault-only custody, and the local lane
is enumerated only when there are none.

The multi-handle refusal was widened from cookie families to cover these too,
with its own reason string. Same argument as cookies: a static key carries no
inline account identity, so two handles for one family would collapse into a
single unlabelled row with an invisible winner.

A behaviour change worth knowing about, given you had two apikey: handles
until 2026-08-26. An id that was ignored before now routes. So a revoked handle
that previously did nothing will produce a dark lane rather than silently falling
back to the local file. That is deliberate — failing visibly beats reading a key
an operator believes they have migrated — but it is observable and it is new.

What I have not verified, since it needs your host. There is no apikey:
handle on this machine, so the vault lane itself is exercised by tests rather
than by a live migration. What I confirmed live is the other half: all three
providers are byte-identical across the deploy with no handles configured
(deepseek serving, openrouter serving, synthetic credential_absent for a
genuinely absent key), so the local path is unchanged. If you re-run
migrate-opencode and mint a handle, that closes the half I cannot reach — and
if it does not work I would rather hear it than have it read as shipped.