Skip to content

Desktop: fatal "Location plugins did not finish activating" when the OpenAI login refresh at startup takes over 5 seconds #61443

Closed

Description

@slkiser

Description

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

  1. Sign in to OpenAI with ChatGPT in OpenCode Desktop.
  2. Quit Desktop and wait until the access token has expired.
  3. 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.
  4. Start Desktop.
  5. 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

Operating System

macOS 15.8.2 (Apple Silicon)

Terminal

None (OpenCode Desktop)

Note

Posted on behalf of @slkiser by Sonnet 5.5.

Activity

  1. opencodejr commented on Nov 3, 2026

    @opencodejr
    Contributor

    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.

    Related:

  2. Luxe7 commented on Nov 4, 2026

    @Luxe7

    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.

  3. Genic-ai commented on Nov 7, 2026

    @Genic-ai

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions