You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Stale per-directory provider state after external auth.json change: ProviderModelNotFoundError with misleading "Did you mean" until POST /global/dispose #50647
Provider state is cached per directory (InstanceState.make in provider.ts) and built once from Auth.all() at first use. auth.json is re-read live by the Auth service, but nothing watches the file — when it changes on disk from another process (TUI/CLI login, manual edit), already-cached directories keep the old snapshot. Prompts in those directories then fail with:
ProviderModelNotFoundError: Model not found: opencode-go/glm-5.3-flash. Did you mean: glm-5.3-flash?
The Did you mean suggestion is misleading: it comes from the models.dev catalog (which has the model), while the actual failure is that s.providers["opencode-go"] was never merged into that instance's state because the auth entry didn't exist when the state was built (mergeProvider: const match = database[providerID]; if (!match) return / auth loop skipped).
Directories first used after the auth change work fine — so it looks like a per-project/model problem when it's really cache staleness. POST /global/dispose fixes it immediately.
Found while debugging getpaseo/paseo#1925 (same error surfaced through Paseo).
Repro
Start a server: opencode serve --port 4599
Use directory A (builds its provider state), e.g.:
From another process, add that provider's key to ~/.local/share/opencode/auth.json (e.g. opencode auth login, or insert "<provider>": {"type": "api", "key": "..."} manually).
Repeat step 2 with the same directory A → ProviderModelNotFoundError with a Did you mean: <exact model> suggestion.
Same prompt in a fresh directory B (first use after the change) → works.
curl -X POST http://localhost:4599/global/dispose → directory A works again.
Expected behavior
Auth changes should be visible to running servers: watching auth.json and calling disposeAllInstances (the path already used by PUT /global/config when changed) would fix it, or provider state should re-merge auth on read.
Environment
opencode:1.18.29 (long-running opencode serve process; installed CLI now1.18.32 — same code at v1.18.29 and dev)
OS: macOS (darwin)
Provider: opencode-go (key present in auth.json; opencode models lists the model)
Notes
Symptom also reported (and closed as not-planned) against an integration: bug: cannot use opencode-go getpaseo/paseo#1925 — Paseo sends a correct {providerID, modelID} payload; the failure is server-side staleness.
Activity
github-actions commentedon Sep 22, 2026
This issue might be a duplicate of existing issues. Please check:
/connectare not applied to a running server (SAP AI Core, GitHub Copilot), and SAP multi-line keys are stored truncated #46354: Describes the same root cause as "Bug C" — a running server caches provider/credential state and does not invalidate it whenauth.jsonchanges out-of-band (e.g. viaopencode auth loginin a separate process). That issue explicitly proposes the same fix (watchauth.json, invalidate cached state, or re-read auth on each provider resolution).auth.jsonnot attached to LLM requests on a runningopencode serveinstance — a related manifestation of stale credential state in a long-running server.thdxr commentedon Oct 11, 2026
Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (
opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊