OpenCode 2.0.3 provider inventory times out in T3 Code Nightly

[mustafaerpek]

What happened

OpenCode initially connected successfully after installing T3 Code. Later, the integration became unavailable. The last working version and triggering change are unknown.

Settings → Providers detects OpenCode v2.0.3 but displays:

Failed to load OpenCode provider inventory: Timed out waiting for OpenCode server start after 30000ms.

No models are available.

Diagnosis

The enabled provider uses binary path opencode with an empty server URL. T3 attempts to start a local OpenCode server.

Logs confirm two server launches followed by status checks lasting approximately 31 seconds. The installed Nightly bundle waits for stdout containing opencode server listening before checking server health.

Separately, an existing OpenCode service accepted its configured credentials but returned HTML for /global/health and /provider, where T3 expects JSON. This service was not proven to be one of the timed-out child processes.

The evidence suggests startup/API incompatibility. It does not establish which change caused the previously working integration to fail.

Steps to reproduce

Observed on this installation; not reproduced on a clean machine:

1. Use T3 Code Nightly with OpenCode CLI 2.0.3.
2. Enable OpenCode with binary path opencode and an empty server URL.
3. Refresh provider status in Settings → Providers.
4. Observe the timeout after approximately 30 seconds and an empty model list.

Version

Desktop: 0.0.41-nightly.20260914.1722
Triage CLI: 0.0.40, launched using bunx t3 triage

Environment

macOS, Darwin 27.0.0, arm64. Triage Node v26.8.2. OpenCode CLI 2.0.3. Nightly desktop with a local backend.

Evidence

2026-09-14T20:05:22.784Z:
  serve --hostname=127.0.0.1 --port=57673
2026-09-14T20:05:53.850Z:
  serve --hostname=127.0.0.1 --port=57727

Status-check durations: 31079 ms, 31071 ms
Provider cache: installed=true, version=2.0.3, status=error, models=[]

Authenticated requests to existing service:
GET /global/health: 200, text/html
GET /provider: 200, text/html

Screenshots show the timeout and detected version. Credentials and home directory paths are omitted.

Related issues

PR #7863 and PR #7600 proposed OpenCode 2 support; both closed without merging.

Issue #2337 reports a similar health-check symptom on Windows. A shared root cause has not been established. No confirmed duplicate was found.

Fix applied or workaround

None. No settings were modified or services started or restarted during investigation.

Filed by

Prepared by Codex, GPT-6, via T3 Code triage.

[mustafaerpek]

[arthur-albuquerque]

I am having the same issue

[amihos]

Confirming same failure on OpenCode v2.0.9 (Linux) with local background service healthy via opencode api get /api/info.

Root-cause evidence from this machine:

• opencode serve --hostname=127.0.0.1 --port=39715 prints:
  server listening on http://127.0.0.1:39715
  (no opencode prefix)
• t3code apps/server/src/provider/opencodeRuntime.ts on main waits for OPENCODE_SERVER_READY_PREFIX = "opencode server listening" via parseServerUrlFromOutput(), so it never matches V2 output and hits Timed out waiting for OpenCode server start after 30000ms.
• V2 OpenAPI has no /global/health (only /api/info + /api/*); unauthenticated /global/health returns 401/HTML, so verifyOpenCodeServerVersion (client.global.health) also looks V1-era.
• V2 CLI: agent list gone (agents now under debug agents), debug skill gone (debug only has agents, config, paths), so loadInventoryFromCli (models --verbose / agent list / debug skill) will also fail on V2.

So the 30s timeout is a V1/V2 startup-string + API contract mismatch, not slowness. Happy to provide redacted logs if needed.

[00xmario]

Same issue

I think OpenCode 2 will be supported with Orchestrator v2

[nafiskabbo]

Confirming duplicate on T3 Code 0.0.42 (CLI via npx, Nightly desktop server running locally) + OpenCode CLI 2.0.10, macOS darwin arm64.

Root cause (verified locally): T3 waits for stdout starting with opencode server listening (apps/server/src/provider/opencodeRuntime.ts:80, parsed in parseServerUrlFromOutput). OpenCode v2 prints server listening on http://127.0.0.1:<port> instead — no opencode prefix — so the match never fires and the check hits the 30s timeout.

Evidence on this machine:

• ~/.t3/caches/opencode.json: installed=true, version=2.0.10, status=error, Timed out waiting for OpenCode server start after 30000ms, models=[]
• server.trace.ndjson: consecutive checkOpenCodeProviderStatus spans of ~31s (31208ms, 31174ms, 31051ms, 31073ms)
• Manual repro: opencode serve --hostname=127.0.0.1 --port=<port> on v2.0.10 prints server listening on ...; after downgrading to 1.18.31 it prints opencode server listening on ..., matching T3's expectation.

Workaround applied here: bun i -g opencode-ai@1.18.31, then refresh Settings → Providers → OpenCode. Still present on main (same prefix string).

Triage via opencode session (Muse Spark 1.3 Free).

[paperbenni]

Any info on when Orchestrator v2 will be released? OCv1 is pretty much deprecated at this point. OC2 even overrides its binary name. I am not messing around with overriding that just for t3 code. I'd love to try it at some point, but it's just not worth breaking herdr+oc2 on my servers for

[LAG-4]

Confirming this is still present on current main (1de563c14, Sept 21) with OpenCode CLI v2.0.11, and extending the root-cause picture: the startup string is only the first of several v1-only assumptions, so a prefix-only fix would just move the failure downstream.

Still v1-only on main:

• apps/server/src/provider/opencodeRuntime.ts:15 imports @opencode-ai/sdk/v2 (the v1-line SDK despite the name), :42 gates on MINIMUM_OPENCODE_VERSION = "1.14.19", :81 waits for "opencode server listening".
• apps/server/package.json:30 pins "@opencode-ai/sdk": "^1.3.15".

Beyond the startup string (all verified against a local v2.0.11 server):

• The 1.14.19 gate passes numerically for 2.x, so users get confusing downstream errors instead of a clear "unsupported" message.
• GET /global/health doesn't exist on v2 (it's GET /api/info, auth required); unauthenticated it returns 401 with an empty body.
• Every other call T3 makes is v1-shaped and fails on v2: provider.list, app.agents, app.skills, command.list, session.create ({title, permission}), session.prompt/promptAsync ({sessionID, model, parts}), session.command, session.abort, session.children, session.status, session.summarize, session.messages, session.fork, permission.reply, question.reply, event.subscribe — plus the CLI inventory path (models --verbose / agent list / debug skill), which commenters above have shown is also reorganized on v2.
• v2 replacements live under /api/* with different shapes: location-scoped sessions, inbox-based prompting with event-stream progress, forms instead of questions, session.interrupt instead of session.abort, one-shot session.generate. The supported client is the new @opencode/client package (OpenCode.make({ baseUrl })), not @opencode-ai/sdk (whose latest, 1.18.x, still targets the v1 API).
• Packaging note: on npm, opencode-ai@latest is the v1 line (1.18.31) while @opencode/cli@latest is the v2 line (2.0.11). T3's auto-install (npm install opencode-ai) therefore still lands v1 — which is why fresh auto-installs work while anyone with a v2 binary (curl/brew/upgrade path) breaks.

Minimal repro on current main/nightly:

1. opencode --version → 2.x (any install path that yields v2).
2. Enable the OpenCode provider with default binary path and empty server URL.
3. Settings → Providers → Refresh provider status.
4. Timed out waiting for OpenCode server start after 30000ms, empty model list. (v2 prints server listening on … with no opencode prefix, plus an auto-generated server password … line when no password is configured.)

Workaround (confirming nafiskabbo's): pin the v1 line, e.g. npm i -g opencode-ai@1.18.31, then refresh.

@juliusmarminge could you have a look at this

Happy to help verify a version-routed fix (detect v1 vs v2 at connect and speak the matching API) against v2.0.11 here.

[ripperonin]

Opencode has switched to v2 as default for over a week now, and still remains broken in t3 code

[nafiskabbo]

Any update on it? Will it get fixed? Or we should make changes locally?

[AshutoshGitMirror]

Any update on it? Will it get fixed? Or we should make changes locally?

As per julius rewrite is underway, one pertinent observation—non-codex/claude-code providers often get less developer time in this project.

[dmeyerhoff]

Still reproduces on OpenCode 2.0.15 (Homebrew, opencode-v2) with T3 Code 0.0.42 stable on macOS arm64 — same signature as above, for anyone tracking by version:

• opencode serve --hostname=127.0.0.1 --port=<p> prints server listening on http://127.0.0.1:<p> (and a server password <pw> line when no password is configured); the opencode server listening prefix T3 waits for is absent from the 2.0.15 binary (strings count: 0).
• ~/.t3/caches/opencode.json: status: "error", Timed out waiting for OpenCode server start after 30000ms, empty model list.
• ~/.t3/userdata/logs/server.trace.ndjson: consecutive checkOpenCodeProviderStatus spans of ~31s, interrupted at the 30s timeout.
• OpenCode itself is healthy throughout: opencode service status and opencode api get /api/info both succeed (the CLI authenticates with the password from its config, which T3 never supplies).

No fix needed on this issue beyond what's already scoped — just confirming 2.0.15 and +1 for #13008 / #12643.

[eduardozf]

This may affect more users now: OpenCode’s current install instructions use npm install -g @opencode/cli, which installs v2 as the opencode executable. On my Linux machine, opencode resolved to v2.0.15, and T3 timed out loading the provider inventory as described here.

Pointing T3 to an isolated OpenCode v1.15.13 installation made the provider available again. Since users following the current OpenCode instructions can hit this, could T3 detect v2 and show a clear compatibility message until v2 support lands? I also saw the draft v2 support PR.

[Dhruv2mars]

Reproduced on T3 Code Nightly 0.0.43-nightly.20260924.2200 (desktop, macOS arm64) with OpenCode v2.0.16. The app's update check reports Up to Date.

With the OpenCode provider enabled, binary path opencode, and no server URL, Settings → Providers reports:

Failed to load OpenCode provider inventory: Timed out waiting for OpenCode server start after 30000ms.

The installed binary starts a server in under a second. Its stdout begins server listening on http://127.0.0.1:PORT, while this Nightly still waits for opencode server listening. Its /global/health route also returns the web UI (200 text/html); the v2 API uses /api/* routes and requires authentication. This confirms the incompatibility remains in the current Nightly. Pointing the same T3 Code instance at a separate OpenCode v1.18.32 binary made provider inventory and an in-app test turn work, so the v2 binary itself is healthy.

I understand #12643 is the draft native v2 integration. No separate fix is needed for this comment; I wanted to add the 0.0.43/v2.0.16 reproduction.

[Narayan201120]

Verified end to end on OpenCode 2.0.16 (Windows, Bun binary) and fixed on a branch; linking it here as reference since #13605/#13606 were closed toward this thread: Narayan201120/t3code branch fix/opencode-2x-provider-inventory.

What was confirmed with live probes against a real 2.x server:

• The 30s timeout is the readiness banner. 2.x prints server listening on ..., T3 Code waits for opencode server listening, so the match never fires while the server runs fine.
• 2.x prints a generated server password ... line right after the banner, often in a later stdout chunk. Any fix must capture it after readiness, not just at the ready line, or health checks fail auth.
• Old routes (/global/health, /provider) serve the web UI as text/html on 2.x. Working v2 surface used here: /api/info for version, /api/provider for the configured set, /api/model for the catalog, plus /api/agent, /api/skill, /api/command, all with the existing Basic auth scheme.
• A freshly spawned 2.x server answers list calls with empty catalogs for roughly 4 to 8 seconds after its banner (0 models, then the full 708-model registry). An empty model catalog means still warming up, so the fix retries briefly before accepting it. Without this, first load shows no providers and only a manual refresh heals it.
• Windows note: killing the spawned shim can orphan the real server process, which keeps holding its port. Seen while testing; separate issue.

Scope of the branch: spawn detection, password capture, per-server v1/v2 detection with fallback only on the incompatibility signal, and v2 status plus inventory (models, skills, commands) through @opencode/client. Live sessions still use the v1 SDK and need their own migration, which looks like what #12643 covers. Focused suites pass (the one failure is the pre-existing Windows XDG path assertion), typecheck is clean, and a live run showed authenticated status with 9 providers and 708 models.

[nafiskabbo]

Any update on when it can get supported on Nightly versions?