service (v2): serve --service daemon keeps using old OPENCODE_API_KEY after the key is rotated (401 with no hint) #42690

Activity

1. github-actions

   assigned

   nexxeln

   on Aug 15, 2026
2. opencode-agent

   added

   2.0

   on Aug 15, 2026
3. nexxeln commented on Aug 18, 2026

   

   nexxeln

   on Aug 18, 2026

   Contributor

   More actions

   The background service may be using outdated environment credentials. Restart it with opencode2 service restart.
4. aleks-mariusz commented on Oct 12, 2026

   

   aleks-mariusz

   on Oct 12, 2026

   Last edited by aleks-mariusz

   More actions

   Just hit this as well, and the failure mode is nasty to debug. I launch opencode through a liteLLM CLI wrapper (lite opencode) that injects a fresh short-lived (24h) API token into the child env on every run. Since the shared background service captures its env once at spawn, once that token expired every subsequent launch silently routed through the stale daemon and failed with an "Expired Key" 401 — even though the wrapper was handing over a perfectly valid new token. Re-login didn't help; only killing the daemon did. So this isn't just a manual key-rotation edge case: any short-lived-credential workflow triggers it deterministically, with no hint in the error that a stale server env is the cause.

   Update — a working solution exists: PR #52107 added opencode service set disabled true (merged 2026-09-29, shipping in current releases), which disables the background service entirely and makes the CLI default to private standalone servers. Running that one command fixed my case permanently: every launch now spawns a private server with the current env, so there's no daemon to hold onto a stale token. For anyone else landing here on rotating/short-lived credentials, that toggle is the workaround that ships today. The complementary fix would still be what this issue asks for (env mismatch detection, respawn-or-inherit), since users who want the shared service shouldn't have to choose it vs. fresh credentials.
5. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   More actions

   Thanks for the clear write-up and for tracking down the cause.

   This comes from how the shared background service is designed. opencode2 reuses the running serve --service process as long as its version matches. That process keeps the environment it was started with, so a rotated OPENCODE_API_KEY in a new shell doesn't reach it until it's restarted (opencode2 service restart). Since the service is doing what it was built to do, I've filed this as a feature request: show a clear hint when a provider returns 401 and the request went through a long-running service that may hold an outdated credential. For example, the CLI could warn when its own key differs from the service's, or the error could mention the service and suggest restarting it. Maintainers will consider it.

   Related issues:

   • bug(v2): stale stored credential silently overrides provider options.apiKey; auth.json edits ignored after one-time import; no non-interactive key rotation #58394: a stored credential silently overrides a rotated key from config, which also gives a 401
   • providers: stale wellknown API-key wiring in the shared service sends an empty key after auth login/logout #54645: the shared service keeps stale API-key wiring after auth login/logout, which also gives a 401
   • service: restart leaves stale daemon and duplicated MCP servers running #42270, service (v2): restart spawns serve --service in a silent retry loop, forcing manual process kill #37239: other background service lifecycle problems