TUI startup is blocked by GitHub Copilot model fetch timeout #21296

This issue description was prepared with AI assistance using OpenCode and the github-copilot/gpt-5.4 model, and reviewed before filing.

Summary

TUI startup currently waits on provider.list() during bootstrap. For GitHub Copilot, that path includes a request to the remote /models endpoint. If that endpoint is slow or unreachable, startup is delayed until the hardcoded timeout is hit.

The request does fall back to the existing model list after failure, but the timeout still happens on the startup path, which makes TUI responsiveness depend on Copilot network conditions even before the user opens any provider or model UI.

What happens

During TUI bootstrap, sdk.client.provider.list() is included in the blocking requests:

• packages/opencode/src/cli/cmd/tui/context/sync.tsx:370
• packages/opencode/src/cli/cmd/tui/context/sync.tsx:377-385

That request reaches the server /provider route, which calls Provider.list():

• packages/opencode/src/server/routes/provider.ts:54

Inside provider initialization, plugin provider.models(...) hooks are executed:

• packages/opencode/src/provider/provider.ts:1250-1264

For the GitHub Copilot plugin, that hook calls CopilotModels.get(...), which fetches the remote models endpoint:

• packages/opencode/src/plugin/github-copilot/copilot.ts:50-57
• packages/opencode/src/plugin/github-copilot/models.ts:108-121

Current fetch logic:

const data = await fetch(`${baseURL}/models`, {
  headers,
  signal: AbortSignal.timeout(5_000),
})

Default base URL for GitHub.com:

https://api.githubcopilot.com/models

When this request is slow or blocked, startup waits for the timeout and logs:

ERROR ... service=plugin.copilot error=The operation timed out. failed to fetch copilot models

Why this seems problematic

This fetch appears to be best-effort metadata enrichment rather than something strictly required to render the initial TUI state.

The plugin already handles failure by falling back to the existing provider model definitions:

log.error("failed to fetch copilot models", { error })
return Object.fromEntries(Object.entries(provider.models).map(([id, model]) => [id, fix(model)]))

So the current behavior is functionally resilient, but the timeout still impacts startup latency.

Expected behavior

TUI startup should not be blocked on a remote GitHub Copilot model refresh.

A failure to refresh Copilot models should ideally not delay the app becoming ready.

Possible approaches

Some options that seem worth considering:

• move Copilot model refresh off the blocking startup path
• use the fallback/static model set during bootstrap and refresh later
• refresh only when provider/model selection UI is opened
• cache the last successful /models response
• make the timeout configurable if startup blocking remains necessary

Regression context

This behavior looks related to the recent Copilot model sync changes:

• 1fcfb69bf feat: add new provider plugin hook for resolving models and sync models from github models endpoint (falls back to models.dev)
• 10ca1ace6 tweak: add abort signal timeout to the github copilot model fetch to prevent infinite blocking

The second change improves failure behavior versus hanging indefinitely, but it still leaves startup exposed to a 5s wait.

Reproduction

1. Configure GitHub Copilot auth
2. Start TUI in an environment where api.githubcopilot.com/models is slow, blocked, or unreliable
3. Observe that startup is delayed while the request waits for timeout
4. Observe the timeout log from plugin.copilot

Impact

This does not appear to break provider loading outright, since fallback behavior exists.

The main issue is startup responsiveness:

• TUI can feel slow to become ready
• startup latency depends on external Copilot network health
• the delay happens even if the user never opens provider or model selection