Skip to content

[Bug]: OpenCode sessions fail after upgrading or downgrading the OpenCode binary - driver chosen from stale version #27758

Closed

Description

@hamishnorton

Before submitting

  • 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

  1. 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).
  2. Enable the OpenCode provider in T3 Code settings, leaving Server URL blank so T3 spawns the server. The provider shows "Authenticated", v2.2.4.
  3. 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.

Activity

  1. hamishnorton commented on Oct 30, 2026

    @hamishnorton
    Author

    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:

    1. 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.
    2. 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".
    3. 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.
    4. 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.

  2. 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
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