provider: slow plugin setup disables all github-copilot models

Summary

When any plugin's setup() takes roughly 500 ms or longer, every github-copilot model ends up with enabled: false and disappears from /models and opencode models, even though the Copilot credential is connected. The state does not recover later: a long-running background service and ctx.model.reload() keep the models hidden.

Environment

opencode version: 2.1.1
OS: Windows 11, Microsoft Windows [Version 10.0.26300.9711] (win32 x64)
Terminal: Unavailable: terminal environment variables are not set (run from the OpenCode agent shell tool)
Shell: PowerShell 7 (pwsh)
Install/channel: latest
Active plugins: the minimal reproduction uses only the slow-setup plugin below. The issue was first observed with an internal organization plugin that performs network requests during setup().

Reproduction

Connect GitHub Copilot (/connect → GitHub Copilot, OAuth). Without plugins, opencode models --standalone lists the github-copilot/* models (38 for this account).

Create an isolated config with only one local plugin:

$XDG_CONFIG_HOME/opencode/plugins/slow-setup/package.json

{"name":"slow-setup","type":"module","exports":{".":"./index.mjs"}}

$XDG_CONFIG_HOME/opencode/plugins/slow-setup/index.mjs

export default {
  id: "slow-setup",
  async setup() {
    await new Promise((resolve) => setTimeout(resolve, 1000));
  },
};

Run opencode models --standalone from an empty directory with XDG_CONFIG_HOME pointing to that config.
Count the github-copilot/ lines.

Results (each line is a separate fresh --standalone run):

setup() delay	github-copilot models listed
0 ms	38
0 ms	38
500 ms	0
1000 ms	0
1000 ms	0
3000 ms	0

Expected Behavior

A plugin's slow setup() should not change which models another provider integration enables. Copilot models available to the connected account should stay enabled, or should become enabled once the integration finishes loading.

Actual Behavior

The github-copilot models are still present in the catalog, but all of them have enabled: false. A diagnostic ctx.model.transform registered after the slow plugin observed:

providers: ["github-copilot", "opencode", ...]
github-copilot enabled/status values: ["false/active"]

Without the slow plugin, the same transform observed ["true/active"].

GET /api/provider/github-copilot still returns the provider (activation: "auto"), and opencode auth list shows the credential as stored. The other provider (opencode, activation enabled) is unaffected.

Additional Context

Reproduced consistently on every run (see table). The threshold appears to be under 500 ms.
Recovery does not happen: in the long-running shared background service, the models stay hidden after ctx.model.reload() and after querying other locations.
Workaround: explicitly declaring a model in config makes that single model visible again:
```
{"providers":{"github-copilot":{"models":{"claude-sonnet-5.5":{"disabled":false}}}}}
```
Calling ctx.agent.list() or ctx.command.list() during setup does not trigger the issue. Only elapsed time does.
Two Copilot credentials (personal and organization) are stored for the github-copilot integration; one is active. The minimal reproduction was not tested with a single credential.

Thanks for the clear reproduction, I could confirm this.

I used a local mock of the Copilot /models endpoint instead of a real account. Setup: a fresh isolated config, one imported github-copilot OAuth credential pointing at the mock, and your slow-setup plugin as the only plugin. Then I ran opencode models --standalone and counted the github-copilot/ lines.

2.1.1: a 0 ms delay lists all 3 mock Copilot models; a 1000 ms delay lists none. Same result on every run.
Latest dev (0718864d, run from source): still happens. Without the plugin the models are listed; with slow-setup none are, even with a 0 ms delay. Startup from source is slower, which fits a startup timing problem rather than anything specific to your plugin.

The script below reproduces it. I only checked the models listing, not the long-running service or ctx.model.reload() case. Until this is fixed, your workaround of declaring the Copilot models you need under providers.github-copilot.models in config is the way to keep them visible.

Reproduction script (repro.sh)

#!/usr/bin/env bash
# Repro for #57495: a slow plugin setup() leaves all github-copilot models enabled:false.
# Uses a local mock of the Copilot /models API (no real account needed).
# OC: command to run opencode (default: opencode from PATH).
set -u
OC=${OC:-opencode}
ROOT=$(mktemp -d /tmp/opencode/r57495.XXXX)
PORT=${PORT:-18765}

# Mock Copilot API: GET /models returns 3 picker-enabled models.
cat >"$ROOT/mock.mjs" <<'EOF'
const model = (id, family) => ({
  id, name: id, version: id, model_picker_enabled: true,
  supported_endpoints: ["/chat/completions"],
  capabilities: { family, limits: { max_prompt_tokens: 100000, max_output_tokens: 8000, max_context_window_tokens: 128000 },
    supports: { tool_calls: true, streaming: true } },
})
Bun.serve({ port: Number(process.env.PORT), fetch(req) {
  const u = new URL(req.url)
  if (u.pathname === "/models") return Response.json({ data: [model("gpt-4.1","gpt-4.1"), model("claude-sonnet-4","claude-sonnet-4"), model("gpt-5-mini","gpt-5-mini")] })
  return new Response("not found", { status: 404 })
}})
EOF
PORT=$PORT bun "$ROOT/mock.mjs" & MOCK=$!
trap 'kill $MOCK 2>/dev/null' EXIT
sleep 0.5

run() { # $1 = delay ms
  local d=$1 H="$ROOT/h$d"
  mkdir -p "$H/config/opencode/plugins/slow-setup" "$H/data" "$H/state" "$H/cache" "$H/proj"
  if [ "$d" != "none" ]; then
    echo '{"name":"slow-setup","type":"module","exports":{".":"./index.mjs"}}' >"$H/config/opencode/plugins/slow-setup/package.json"
    echo "export default { id: \"slow-setup\", async setup() { await new Promise(r => setTimeout(r, $d)) } }" >"$H/config/opencode/plugins/slow-setup/index.mjs"
  fi
  export XDG_CONFIG_HOME=$H/config XDG_DATA_HOME=$H/data XDG_STATE_HOME=$H/state XDG_CACHE_HOME=$H/cache
  cat >"$H/cred.json" <<EOF
[{"id":"cop","integrationID":"github-copilot","label":"Copilot","active":true,
  "value":{"type":"oauth","methodID":"device","refresh":"gho_fake","access":"","expires":0,
           "metadata":{"apiEndpoint":"http://127.0.0.1:$PORT"}}}]
EOF
  (cd "${PROJ:-$H/proj}" && $OC auth import "$H/cred.json" >/dev/null 2>&1)
  local n
  n=$(cd "${PROJ:-$H/proj}" && $OC models --standalone 2>/dev/null | grep -c '^github-copilot/')
  echo "setup() delay=$d ms -> github-copilot models listed: $n"
}

for d in ${DELAYS:-0 1000 0 1000}; do run $d; done

Run it: bash repro.sh

I found a pitfall in the mock script above: each delay gets a new XDG home, but auth import uses the managed service's fixed port. In my runs, a later home hit “Managed service port 49375 ... already in use”; the import error was discarded, so counting zero models was not a valid reproduction. Use auth import --standalone and verify that import succeeds before comparing delays.

A controlled startup probe passes on current dev: Copilot discovery finishes while a Promise plugin holds activation, then the configured model catalog is built; the picker-enabled model remains visible. The Copilot test file passes 30 tests. This covers that ordering, not the original Windows scenario, and is not a production fix.

Could you share redacted server logs for 0 ms and 1000 ms runs using the same connected config, including any plugin activation failures?

Thanks both. Here are server logs from the same connected config, as requested.

Setup

OpenCode 2.1.1, Windows 11 (10.0.26300), real GitHub Copilot OAuth credential added through /connect (no auth import, so the managed-service port issue does not apply here).
Default data directory with the stored credential; isolated XDG_CONFIG_HOME containing only the slow-setup plugin; empty working directory.
OPENCODE_LOG_LEVEL=DEBUG opencode models --standalone --print-logs, run back to back.

Results

setup() delay	github-copilot models listed
0 ms	27
1000 ms	0

(The 0 ms count was 38 when I filed the issue yesterday; I don't know why it changed. Two Copilot credentials are stored for the integration, personal and organization, one of them active.)

Observations

No plugin activation failures, and no WARN or ERROR lines in either run.
Nothing about Copilot model discovery or the integration appears in the logs at all, even at DEBUG, so the logs don't show when discovery runs or whether it fails.
The only difference is timing: from loading plugin to provider.updated takes about 460 ms with a 0 ms delay and about 1470 ms with a 1000 ms delay.

Watcher subscribe/started lines are removed; usernames in paths are replaced with <user>. Nothing else is changed.

Server log, 0 ms delay (27 Copilot models)

timestamp=2026-10-21T05:56:04.037Z level=INFO run=c701492e message="spawning process" command="C:\\Program Files\\nodejs\\node_modules\\@opencode\\cli\\bin\\opencode.exe" args="[\"serve\",\"--stdio\",\"--port\",\"0\"]" cwd="C:\\Users\\<user>\\AppData\\Local\\Temp\\opencode\\r57495\\work" role=cli
timestamp=2026-10-21T05:56:04.161Z level=INFO run=8830512f message="cli starting" version=2.1.1 channel=latest local=false args="[\"serve\",\"--stdio\",\"--port\",\"0\"]" role=cli
timestamp=2026-10-21T05:56:04.605Z level=INFO run=8830512f message="location services booted" directory="C:\\Users\\<user>\\AppData\\Local\\Temp\\opencode\\r57495\\work" workspaceID=undefined durationMs=188 http.span=191 role=server
timestamp=2026-10-21T05:56:04.619Z level=INFO run=8830512f msg="loading plugin" id="C:\\Users\\<user>\\AppData\\Local\\Temp\\opencode\\r57495\\cfg\\opencode\\plugins\\slow-setup" entrypoint=file:///C:/Users/<user>/AppData/Local/Temp/opencode/r57495/cfg/opencode/plugins/slow-setup/index.mjs http.span=205 role=server
timestamp=2026-10-21T05:56:05.058Z level=DEBUG run=8830512f message="skill source loaded" source="directory:C:\\Users\\<user>\\AppData\\Local\\Temp\\opencode\\r57495\\cfg\\opencode\\skill" type=directory directories="[\"C:\\\\Users\\\\<user>\\\\AppData\\\\Local\\\\Temp\\\\opencode\\\\r57495\\\\cfg\\\\opencode\\\\skill\"]" skills=[]
timestamp=2026-10-21T05:56:05.061Z level=DEBUG run=8830512f message="skill source loaded" source="directory:C:\\Users\\<user>\\AppData\\Local\\Temp\\opencode\\r57495\\cfg\\opencode\\skills" type=directory directories="[\"C:\\\\Users\\\\<user>\\\\AppData\\\\Local\\\\Temp\\\\opencode\\\\r57495\\\\cfg\\\\opencode\\\\skills\"]" skills=[]
timestamp=2026-10-21T05:56:05.078Z level=INFO run=8830512f message=event event.id=evt_15d07f555001wUxwnR0MAa7yPq event.created=1792562165077 event.type=provider.updated event.location.directory="C:\\Users\\<user>\\AppData\\Local\\Temp\\opencode\\r57495\\work" event.location.workspaceID=undefined event.data={} http.span=664 role=server
timestamp=2026-10-21T05:56:05.093Z level=INFO run=8830512f message=event event.id=evt_15d07f565001UWqdXDJm9hxmOP event.created=1792562165093 event.type=model.updated event.location.directory="C:\\Users\\<user>\\AppData\\Local\\Temp\\opencode\\r57495\\work" event.location.workspaceID=undefined event.data={} http.span=679 role=server
timestamp=2026-10-21T05:56:05.097Z level=INFO run=8830512f message=event event.id=evt_15d07f568001ab7W8autzoiyLq event.created=1792562165096 event.type=agent.updated event.location.directory="C:\\Users\\<user>\\AppData\\Local\\Temp\\opencode\\r57495\\work" event.location.workspaceID=undefined event.data={} http.span=683 role=server
timestamp=2026-10-21T05:56:05.098Z level=INFO run=8830512f message=event event.id=evt_15d07f56a001SGHMGIxlZ5Yr1R event.created=1792562165098 event.type=command.updated event.location.directory="C:\\Users\\<user>\\AppData\\Local\\Temp\\opencode\\r57495\\work" event.location.workspaceID=undefined event.data={} http.span=684 role=server

Server log, 1000 ms delay (0 Copilot models)

timestamp=2026-10-21T05:56:05.701Z level=INFO run=c24ab1db message="spawning process" command="C:\\Program Files\\nodejs\\node_modules\\@opencode\\cli\\bin\\opencode.exe" args="[\"serve\",\"--stdio\",\"--port\",\"0\"]" cwd="C:\\Users\\<user>\\AppData\\Local\\Temp\\opencode\\r57495\\work" role=cli
timestamp=2026-10-21T05:56:05.820Z level=INFO run=b6e8b75d message="cli starting" version=2.1.1 channel=latest local=false args="[\"serve\",\"--stdio\",\"--port\",\"0\"]" role=cli
timestamp=2026-10-21T05:56:06.264Z level=INFO run=b6e8b75d message="location services booted" directory="C:\\Users\\<user>\\AppData\\Local\\Temp\\opencode\\r57495\\work" workspaceID=undefined durationMs=191 http.span=193 role=server
timestamp=2026-10-21T05:56:06.277Z level=INFO run=b6e8b75d msg="loading plugin" id="C:\\Users\\<user>\\AppData\\Local\\Temp\\opencode\\r57495\\cfg\\opencode\\plugins\\slow-setup" entrypoint=file:///C:/Users/<user>/AppData/Local/Temp/opencode/r57495/cfg/opencode/plugins/slow-setup/index.mjs http.span=206 role=server
timestamp=2026-10-21T05:56:07.717Z level=DEBUG run=b6e8b75d message="skill source loaded" source="directory:C:\\Users\\<user>\\AppData\\Local\\Temp\\opencode\\r57495\\cfg\\opencode\\skill" type=directory directories="[\"C:\\\\Users\\\\<user>\\\\AppData\\\\Local\\\\Temp\\\\opencode\\\\r57495\\\\cfg\\\\opencode\\\\skill\"]" skills=[]
timestamp=2026-10-21T05:56:07.724Z level=DEBUG run=b6e8b75d message="skill source loaded" source="directory:C:\\Users\\<user>\\AppData\\Local\\Temp\\opencode\\r57495\\cfg\\opencode\\skills" type=directory directories="[\"C:\\\\Users\\\\<user>\\\\AppData\\\\Local\\\\Temp\\\\opencode\\\\r57495\\\\cfg\\\\opencode\\\\skills\"]" skills=[]
timestamp=2026-10-21T05:56:07.746Z level=INFO run=b6e8b75d message=event event.id=evt_15d07ffc2001NfufZZ5i6qWjye event.created=1792562167746 event.type=provider.updated event.location.directory="C:\\Users\\<user>\\AppData\\Local\\Temp\\opencode\\r57495\\work" event.location.workspaceID=undefined event.data={} http.span=1675 role=server
timestamp=2026-10-21T05:56:07.760Z level=INFO run=b6e8b75d message=event event.id=evt_15d07ffd0001UVRWhX7SUkPoO6 event.created=1792562167760 event.type=model.updated event.location.directory="C:\\Users\\<user>\\AppData\\Local\\Temp\\opencode\\r57495\\work" event.location.workspaceID=undefined event.data={} http.span=1689 role=server
timestamp=2026-10-21T05:56:07.762Z level=INFO run=b6e8b75d message=event event.id=evt_15d07ffd2001qWTd0540Q3uFMt event.created=1792562167762 event.type=agent.updated event.location.directory="C:\\Users\\<user>\\AppData\\Local\\Temp\\opencode\\r57495\\work" event.location.workspaceID=undefined event.data={} http.span=1691 role=server
timestamp=2026-10-21T05:56:07.763Z level=INFO run=b6e8b75d message=event event.id=evt_15d07ffd3001tGGjHeqACrUDAi event.created=1792562167763 event.type=command.updated event.location.directory="C:\\Users\\<user>\\AppData\\Local\\Temp\\opencode\\r57495\\work" event.location.workspaceID=undefined event.data={} http.span=1692 role=server

If there's a log scope or flag that traces Copilot discovery, tell me and I'll rerun with it.

Thanks—your real-OAuth runs rule out the mock script’s import problem. There isn't a separate discovery trace flag in 2.1.1: this path logs failures, but not successful discovery, even at DEBUG.

I prepared a diagnostic branch on current dev. With OPENCODE_LOG_LEVEL=DEBUG and --print-logs, it reports:

syncing GitHub Copilot models
synced GitHub Copilot models, with usable-model and picker-enabled counts
explicit no-OAuth or connection-changed skip/discard messages

It logs no tokens, endpoint URLs or account identifiers and leaves model availability unchanged. Existing Copilot provider/catalog tests pass (31 tests); bun run check also passes (Node 22.16 with NODE_OPTIONS=--experimental-strip-types). I haven't reproduced your Windows/two-credential scenario.

If you can run that branch against the same connected config, those discovery lines for each delay would distinguish a response with zero picker-enabled models from models being disabled later. This is diagnostic instrumentation, not a fix; I haven't established the root cause.

Thanks, this was exactly the right instrumentation. I ran your diagnostic commit against the same connected config, and the result changes the picture.

Setup

Upstream 681156c82f from anomalyco/opencode plus only the patch from your commit 04005cc7 (applied on top; nothing else taken from the fork). One local deviation: I removed the @silvia-odwyer/photon-node entry from patchedDependencies, because bun install (1.4.4, Windows) failed to apply that patch. It is unrelated to providers.
Server: bun run src/index.ts serve --print-logs from packages/cli, OPENCODE_LOG_LEVEL=DEBUG, using a copy of my 2.1.1 database (OPENCODE_DB) with the real Copilot OAuth credential. Client: released 2.1.1 opencode models --server ... from an empty directory. Isolated XDG_CONFIG_HOME with only slow-setup.
The active credential is my personal GitHub account. An organization credential is also stored but inactive.

Results (four fresh server starts, alternating)

setup() delay	Copilot sync result	Catalog built	github-copilot models listed
0 ms	`models=21 pickerEnabled=0`	before sync finished	27
1000 ms	`models=21 pickerEnabled=0`	after sync finished	0
0 ms	`models=21 pickerEnabled=0`	before sync finished	27
1000 ms	`models=21 pickerEnabled=0`	after sync finished	0

Key log lines (timestamps only):

0 ms:    43.603 syncing GitHub Copilot models
         43.838 provider.updated
         44.121 synced GitHub Copilot models models=21 pickerEnabled=0
         44.128 provider.updated
1000 ms: 50.364 syncing GitHub Copilot models
         50.856 synced GitHub Copilot models models=21 pickerEnabled=0
         51.630 provider.updated

Interpretation

Discovery succeeds in every run. For this account, the Copilot /models response contains 21 models and none with model_picker_enabled: true.
With a slow plugin, the catalog is built after discovery, so the real response is applied and every model is disabled. With a fast startup, the catalog is built first from the bundled models.dev list (27 entries), so models appear that the account's response doesn't mark as picker-enabled.
So the plugin delay doesn't break discovery. It decides which of two inconsistent states you see. I haven't tested whether the 27 models listed in the fast case actually work with this account.

That leaves two questions I can't answer from here:

Is treating model_picker_enabled: false as disabled correct when an account has zero picker-enabled models? It may be an account or policy setting on GitHub's side, but then a message would help more than an empty list.
Should the startup catalog keep showing the models.dev list when it disagrees with the account's actual response? The order shouldn't change what users see.

I haven't checked the inactive organization credential.

Update with the root cause, which turned out to be different from the title.

The active credential is a Copilot Free account (copilot_internal/user: copilot_plan: individual, access_type_sku: free_limited_copilot, endpoint api.individual.githubcopilot.com). The plugin delay only decides whether the catalog is built before or after Copilot discovery. It doesn't cause the problem.

What /models returns for this account (41 entries, queried with the same OAuth credential OpenCode uses)

model_picker_enabled is false for all 41 models.
policy.state is enabled for claude-haiku-4.5, gpt-4.1, gpt-4.1-2025-04-14, gpt-5.6-luna, gpt-6-luna, mai-code-1.1-flash; disabled for the premium models; absent for legacy and embedding models.

What actually works (one short request each)

Model	`policy.state`	Direct API	OpenCode 2.1.1 (declared in config)
`gpt-4.1`	enabled	works (`/chat/completions`)	works
`claude-haiku-4.5`	enabled	`model_not_supported`	`model_not_supported`
`gpt-5.6-luna`	enabled	`model_not_supported` (`/responses` and `/chat/completions`)	`model_not_supported`
`gpt-6-luna`	enabled	`model_not_supported` (`/responses` and `/chat/completions`)	`model_not_supported`

So a Copilot Free account can use at least gpt-4.1 through this integration, but OpenCode hides it because model_picker_enabled is false. Neither flag on its own predicts what is usable: policy.state: enabled also covers models GitHub then rejects.

Resulting behavior

Discovery finishes first (slow startup): every Copilot model is disabled, including the one that works.
Catalog built first (fast startup): the bundled models.dev list is shown, and those models fail with model_not_supported.
Workaround: {"providers":{"github-copilot":{"models":{"gpt-4.1":{"disabled":false}}}}} makes gpt-4.1 visible and usable in both cases.

Suggestions

Don't treat model_picker_enabled: false as unavailable on its own, at least when policy.state is enabled. An account where every model ends up hidden is a strong signal that the filter is wrong.
When a connected integration ends up with zero enabled models, tell the user instead of showing a silently empty list.
Avoid showing the static models.dev list for Copilot once the account's actual response is known, so startup timing can't change the result.

Feel free to retitle the issue (for example "github-copilot: Copilot Free accounts get no usable models").

Correction to my previous comment: GitHub's plan documentation says that on Copilot Free and Copilot Student, "access to models is available through auto model selection only". So model_picker_enabled: false on every model is intended for this plan, not a filtering mistake.

My first suggestion (don't treat model_picker_enabled: false as unavailable when policy.state is enabled) therefore doesn't hold up: GitHub rejects most of those models anyway, and gpt-4.1 working looks like an undocumented leftover. I also tested gpt-5.6-luna-free-auto and mai-code-1.1-flash; both return model_not_supported.

The other two points still apply:

When a Copilot account has no picker-enabled models, OpenCode should say so, for example that Copilot Free only supports auto model selection, instead of showing an empty list.
Startup timing shouldn't decide whether the static models.dev list (unusable models) or the account's real result (no models) is shown.

Thanks for testing the diagnostic branch and checking the plan restriction. I kept model_picker_enabled: false authoritative.

The first Copilot refresh currently runs in the background, so plugin activation can finish with the static models.dev catalog before discovery completes. This verified patch completes that refresh during activation. The catalog after activation therefore follows the account response regardless of unrelated plugin setup time. Discovery failures retain the existing fallback/warning; startup now waits for the existing 5-second fetch timeout. Account-switch refresh is unchanged.

All 33 Copilot provider/catalog tests pass (76 assertions), including two regressions that fail with the original background refresh. bun run check and pre-push checks both pass (34/34 tasks). I haven't reproduced the Windows/two-credential environment. GitHub rejected PR creation with a CreatePullRequest permission error, so the tested patch is available on the fork.

The empty-state explanation remains open. The current available-model list cannot distinguish zero picker-enabled models from failed discovery or local filtering. I propose an optional provider availability reason, no_picker_models, set only after successful nonempty discovery with zero picker-enabled entries, tied to the source connection and cleared on account changes or later selectable results. The provider-specific picker could then explain that no selectable models are exposed, with a link to the plan restrictions, instead of the generic empty message. It would neither infer a plan nor enable rejected models. Would this small provider-status/UI design fit the intended approach?

Navigation Menu

Repository navigation

provider: slow plugin setup disables all github-copilot models #57495

Summary

Environment

Reproduction

Expected Behavior

Actual Behavior

Additional Context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

provider: slow plugin setup disables all github-copilot models #57495

Description

Summary

Environment

Reproduction

Expected Behavior

Actual Behavior

Additional Context

Activity

opencode-agent commented on Oct 20, 2026

Dante-dan commented on Oct 20, 2026

vRune4 commented on Oct 21, 2026

Dante-dan commented on Oct 21, 2026

vRune4 commented on Oct 23, 2026

vRune4 commented on Oct 23, 2026

vRune4 commented on Oct 23, 2026

Dante-dan commented on Oct 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions