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
Desktop: fatal "Location plugins did not finish activating" when the OpenAI login refresh at startup takes over 5 seconds #61443
When OpenCode Desktop starts and the saved ChatGPT/OpenAI login has expired, the built-in OpenAI plugins refresh it while plugins activate. If that refresh takes longer than 5 seconds, /api/provider and /api/model return 503 and the window shows a fatal error:
ServiceUnavailableError: Location plugins did not finish activating
Activation finishes about 2 seconds later in the background (credential updated integrationID=openai, then provider.updated / model.updated), but the window stays on the error until Desktop is restarted. The next start works because the token is fresh.
From the 2.2.5 build it looks like:
each plugin-dependent request waits at most 5 seconds for Location plugin activation, then fails with 503;
ChatGPTPlugin, OpenAIPlugin and OpenAIContextCapsPlugin await integration.connection.resolve(...) during activation, which refreshes the expired token;
plugins activate one after another, so every later plugin waits behind the refresh.
Possible fixes: the window could wait or retry instead of treating this 503 as fatal, or the OpenAI plugins could refresh the token after activation or on first use.
Related: #57204 (same error on ACP session/resume).
Logs from the failing start (Desktop main/renderer and server, trimmed):
14:58:13.752 v2 CLI background service ready
14:58:19.058 GET /api/provider 503 (5060 ms)
14:58:19.060 GET /api/model 503 (5062 ms)
14:58:19.088 fatal renderer error: ServiceUnavailableError: Location plugins did not finish activating
14:58:20.730 credential updated integrationID=openai
14:58:20.858 provider.updated / model.updated
Plugins
opencode-quota (local build). Its setup takes about 5 ms and runs after the built-in OpenAI plugins; the error is the same with a slow token refresh and no slow plugin work.
OpenCode version
Desktop 2.2.5 (bundled CLI 2.2.5)
Steps to reproduce
Sign in to OpenAI with ChatGPT in OpenCode Desktop.
Quit Desktop and wait until the access token has expired.
Make the token refresh slow. I held the reply to POST https://auth.openai.com/api/accounts/oauth/token for 8 seconds in a test harness; a slow network does the same.
Start Desktop.
The window shows "Location plugins did not finish activating". With no delay it starts normally.
Screenshot and/or share link
ServiceUnavailableError: Location plugins did not finish activating
at GSt (oc://renderer/assets/main-DH32_HOX.js:54:33442)
at i (oc://renderer/assets/main-DH32_HOX.js:43:62924)
at async oc://renderer/assets/main-DH32_HOX.js:66:77815
at async Promise.all (index 1)
at async o (oc://renderer/assets/main-DH32_HOX.js:879:22920)
at async oc://renderer/assets/main-DH32_HOX.js:879:22264
Thanks for the detailed report and logs. I couldn't reproduce this here: the fatal screen only shows in the Desktop window, and this sandbox can't run OpenCode Desktop or sign in to ChatGPT.
What I found in the code on 2.2.5 and on current dev (ce8ca30):
The server waits at most 5 seconds for plugins to finish starting and then answers 503 Location plugins did not finish activating. That timeout looks deliberate.
The app's main provider/model loader already retries on that 503, so the fatal error probably comes from another place that loads providers and models without retrying. One candidate is the Desktop first-launch onboarding, which loads them in a Promise.all without retrying. That would match Promise.all (index 1) in your stack trace, but I haven't confirmed it.
A maintainer with Desktop will need to confirm it. It would help to know whether this happened on a normal start or right after a fresh install or first launch.
I'd like to take the first-launch onboarding path. On dev 774a3dd, it syncs providers/models directly, while the regular loader already uses syncWhileBooting to retry plugin-startup 503s.
I checked the source's onboarding function with the real client data layer and controlled HTTP responses: the original fails on the first 503; reusing the existing retry policy continues to the draft after a successful retry. A 401 still fails immediately. This isn't a full Electron or live ChatGPT-login reproduction, so I haven't confirmed that the reported incident was during first-launch onboarding.
The patch reuses that retry policy without changing the server's five-second timeout, separate from #57011's server-side cache approach. Working on this with Codex assistance.
Same failure on the CLI, without Desktop and without any OpenAI login refresh. The trigger here is MCP.
Environment: 2.2.6, Linux, shared service disabled, so opencode debug agents and opencode models each start a private serve --stdio.
4-6 MCP servers configured plus one package plugin
both commands exit 1 with ServiceUnavailableError: Location plugins did not finish activating; --standalone behaves identically
OPENCODE_CONFIG_PROJECT_DISABLE=1 opencode debug agents passes 3/3; removing mcp.servers also makes it pass
server log (http.span from request start): location services booted 0.43-0.96s, plugins loaded 0.55-0.96s, MCP connected 3.76-3.99s, 503 at 5.4-6.1s
the MCP phase is a fixed ~3.8s: 1 server 3.78s, 6 servers 3.76-3.99s, unchanged with stdio vs remote servers and with timeout.startup at 1000/5000/60000ms
sequential runs on an idle machine: 7/10 and 9/10 pass; under parallel load 0-1/3. So it is load-dependent, not deterministic
That means the 5s budget is already consumed by MCP catalog setup plus cold start before user plugin work even begins, which matches the "plugins activate one after another" observation.
Request: make the deadline configurable (experimental.* or mcp.timeout.activation), or exclude the MCP catalog phase from the plugin-activation deadline, or scale it with mcp.timeout.startup. That would cover both this CLI case and the Desktop case above.
Activity
opencodejr commentedon Nov 3, 2026
Thanks for the detailed report and logs. I couldn't reproduce this here: the fatal screen only shows in the Desktop window, and this sandbox can't run OpenCode Desktop or sign in to ChatGPT.
What I found in the code on 2.2.5 and on current
dev(ce8ca30):Location plugins did not finish activating. That timeout looks deliberate.Promise.allwithout retrying. That would matchPromise.all (index 1)in your stack trace, but I haven't confirmed it.A maintainer with Desktop will need to confirm it. It would help to know whether this happened on a normal start or right after a fresh install or first launch.
Related:
session/resumeLuxe7 commentedon Nov 4, 2026
I'd like to take the first-launch onboarding path. On dev 774a3dd, it syncs providers/models directly, while the regular loader already uses syncWhileBooting to retry plugin-startup 503s.
I checked the source's onboarding function with the real client data layer and controlled HTTP responses: the original fails on the first 503; reusing the existing retry policy continues to the draft after a successful retry. A 401 still fails immediately. This isn't a full Electron or live ChatGPT-login reproduction, so I haven't confirmed that the reported incident was during first-launch onboarding.
The patch reuses that retry policy without changing the server's five-second timeout, separate from #57011's server-side cache approach. Working on this with Codex assistance.
Genic-ai commentedon Nov 7, 2026
Same failure on the CLI, without Desktop and without any OpenAI login refresh. The trigger here is MCP.
Environment: 2.2.6, Linux, shared service disabled, so
opencode debug agentsandopencode modelseach start a privateserve --stdio.ServiceUnavailableError: Location plugins did not finish activating;--standalonebehaves identicallyOPENCODE_CONFIG_PROJECT_DISABLE=1 opencode debug agentspasses 3/3; removingmcp.serversalso makes it passhttp.spanfrom request start):location services booted0.43-0.96s, plugins loaded 0.55-0.96s, MCPconnected3.76-3.99s, 503 at 5.4-6.1stimeout.startupat 1000/5000/60000msThat means the 5s budget is already consumed by MCP catalog setup plus cold start before user plugin work even begins, which matches the "plugins activate one after another" observation.
Request: make the deadline configurable (
experimental.*ormcp.timeout.activation), or exclude the MCP catalog phase from the plugin-activation deadline, or scale it withmcp.timeout.startup. That would cover both this CLI case and the Desktop case above.