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
[Bug]: OpenCode sessions fail after upgrading or downgrading the OpenCode binary - driver chosen from stale version #27758
I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
Install OpenCode 2.x (tested 2.2.4 via curl -fsSL https://opencode.ai/v2/install | bash), log in with opencode auth login (GitHub Copilot).
Enable the OpenCode provider in T3 Code settings, leaving Server URL blank so T3 spawns the server. The provider shows "Authenticated", v2.2.4.
Start a thread on any OpenCode model (e.g. github-copilot/...) and send a message.
Expected behavior
T3 spawns opencode serve, verifies the version, and the turn runs.
Actual behavior
The run fails after ~7s with "Provider session failed to open".
T3 spawns opencode serve 5 times, and SIGTERMs each ~70ms after it reports server listening. The failing span is opencode.global.health inside verifyOpenCodeServerVersion (called from OpenCodeRuntime.startServerAttempt):
OpenCodeRuntimeError
at opencode.global.health
at verifyOpenCodeServerVersion
at OpenCodeRuntime.startServerAttempt
at OpenCodeRuntime.startOpenCodeServerProcess
at OpenCodeAdapterV2.openSession
[cause]: Error: Request is not supported by this version of OpenCode Server (Server responded with text/html)
OpenCode 2.x has no /global/health route. The request falls through to the web UI and returns 200 text/html, which the SDK response interceptor turns into the error above. I checked 2.0.18, 2.0.32, 2.1.0, 2.1.4, 2.2.0, 2.2.3 and 2.2.4: all return HTML for /global/health. 1.19.5 returns {"healthy":true,"version":"1.19.5"}.
The settings-page probe (probeOpenCodeServer) tries /api/info before /global/health, so the provider reports healthy and authenticated while every session fails. The compatibility manifest marks >=2.0.18 as supported and recommends it, and the settings warning on 1.x says to upgrade to it, which leads users straight into this failure.
Impact
Blocks work completely
Version or commit
T3 Code (Beta) 0.1.5 desktop. OpenCode 2.2.4.
Environment
macOS 26 (Darwin 25.6.0), Apple Silicon. OpenCode installed to ~/.opencode/bin, on PATH via ~/.local/bin symlink. Local spawned server (Server URL blank).
Logs or stack traces
See the stack trace under Actual behavior (from server.trace.ndjson).
Screenshots, recordings, or supporting files
No response
Workaround
Downgrade to OpenCode 1.x (curl -fsSL https://opencode.ai/install | bash). T3 shows a "Limited support" warning, but 1.19.5 passes the /global/health check.
Correction: my original diagnosis was wrong. OpenCode 2.x works fine with T3's OpenCode 2 driver. The bug is that T3 picks the driver from a stale detected version.
What happened:
T3 detected OpenCode 1.19.5, then I upgraded the binary to 2.2.4. The provider settings page showed v2.2.4 with no warning.
A new thread still went down the 1.x path (OpenCodeAdapterV2.openSession -> verifyOpenCodeServerVersion -> /global/health) against the 2.2.4 binary. 2.x has no /global/health, so it failed with "Server responded with text/html".
I downgraded the binary back to 1.19.5 without restarting T3. This time the session went down the 2.x path (OpenCode2Server.connectTo -> server.info / /api/info) against the 1.x binary and failed with SchemaError: Expected a valid JSON string.
I reinstalled 2.2.4 and a turn on github-copilot/... completed normally.
So whichever driver T3 chose doesn't track the binary that's actually installed when the server is spawned. A version change to the binary (upgrade or downgrade) leaves sessions failing until the driver selection catches up. Expected: re-detect the version when spawning, or fall back to the other driver when the readiness check fails, instead of retrying the same driver 5 times and reporting "Provider session failed to open".
Ignore the workaround in the original report. Downgrading to 1.x causes the same failure in the other direction.
changed the title [-][Bug]: OpenCode 2.x sessions never open - verifyOpenCodeServerVersion calls /global/health, which v2 serves as HTML[/-][+][Bug]: OpenCode sessions fail after upgrading or downgrading the OpenCode binary - driver chosen from stale version[/+]on Oct 30, 2026
Activity
hamishnorton commentedon Oct 30, 2026
Correction: my original diagnosis was wrong. OpenCode 2.x works fine with T3's OpenCode 2 driver. The bug is that T3 picks the driver from a stale detected version.
What happened:
OpenCodeAdapterV2.openSession->verifyOpenCodeServerVersion->/global/health) against the 2.2.4 binary. 2.x has no/global/health, so it failed with "Server responded with text/html".OpenCode2Server.connectTo->server.info//api/info) against the 1.x binary and failed withSchemaError: Expected a valid JSON string.github-copilot/...completed normally.So whichever driver T3 chose doesn't track the binary that's actually installed when the server is spawned. A version change to the binary (upgrade or downgrade) leaves sessions failing until the driver selection catches up. Expected: re-detect the version when spawning, or fall back to the other driver when the readiness check fails, instead of retrying the same driver 5 times and reporting "Provider session failed to open".
Ignore the workaround in the original report. Downgrading to 1.x causes the same failure in the other direction.
[-][Bug]: OpenCode 2.x sessions never open - verifyOpenCodeServerVersion calls /global/health, which v2 serves as HTML[/-][+][Bug]: OpenCode sessions fail after upgrading or downgrading the OpenCode binary - driver chosen from stale version[/+]