[Bug]: OpenCode update reports "still needs an update" after a successful upgrade because verification reads the running server version#13010

Triage

Confirmed on main at 5a61f50cc. This is not a duplicate of #5629, #3550, or #8280. Those share the "Provider still needs an update" toast, but the update command there did not actually update the binary T3 Code later probed. Here opencode upgrade is the right command, it exits 0, and opencode --version is already the new build. Only the version used for verification is stale.

For a local OpenCode install (Server URL empty), post-update verification calls refreshInstance, which runs checkOpenCodeProviderStatus:

1. opencode --version starts a new process and parses the on-disk version (OpenCodeProvider.ts around the --version probe).
2. Inventory is loaded through OpenCodeServerOwner.withServer. If the owned child is still running, that handle is reused. It is only closed after OPENCODE_SERVER_IDLE_TTL ("30 seconds") once nothing is borrowing it, and the verification probe itself is a borrower, so it resets that timer. A live turn keeps the old process until the turn ends and the idle timeout fires (OpenCodeServerOwner.ts).
3. The handle's version is whatever /global/health returned when that process was spawned (verifyOpenCodeServerVersion in startOpenCodeServerProcess). It is not read again on the next borrow. opencode upgrade replaces the binary; the running process keeps the old code.
4. On a successful inventory, that startup version overwrites the CLI probe (version = inventoryExit.value.version). The snapshot, ~/.t3/caches/opencode.json, and the version advisory all follow the old server. behind_latest makes ProviderMaintenanceRunner record status: "unchanged", and the client shows "Provider still needs an update" / "OpenCode still appears outdated."

That overwrite came from #8480, which started reporting the serving process instead of the CLI. That matches an external server, and it matches a local server at spawn time. It is wrong for the window after a successful upgrade of a T3-owned helper.

The native update path is doing the right thing on this install. isOpenCodeNativeCommandPath matches a real path under ~/.opencode/bin/opencode, and the command that runs is the resolved binary plus upgrade (OpenCodeDriver.ts). The cached ~/.local/bin/opencode upgrade is that branch, not the old npm guess. #9325 (which closed #5629) only selects the installer that owns the binary. It does not restart or ignore a stale owned opencode serve. #3550 was closed not_planned on a Codex/Bun hypothesis. #8280 was a Claude/Homebrew hang where the suggested upgrade was already a no-op. None of those change this path.

The reported self-heal matches the owner: once the old child is idle long enough to be replaced, the next health check is the new binary and the advisory clears. Refreshing after that idle period, or restarting T3 Code, is a valid workaround. The install is already updated.

A fix should not kill a helper that a turn is still borrowing. After opencode upgrade exits 0, verification for a T3-owned local server should treat the CLI probe as the installed version when it is newer than the cached server version, or restart the owned server only when this probe is the sole borrower and then re-read /global/health. An in-flight turn can keep the old process until it goes idle.

Related OpenCode V2 / externally managed server case, with a distinction from this issue's original T3-owned updater reproduction.

On 14 October 2026 (AEDT), T3 Code Nightly 0.0.46-nightly.20261013.3042 on macOS 26.7.1 was connected to an authenticated loopback server at http://127.0.0.1:4096. The installed Homebrew CLI reported 2.0.28, but /api/info on the launchd-owned server reported 2.0.27. That process had started on 13 October 2026 at 09:56:26 AEDT. Repeated model turns failed with ConnectionRefused while the server's HTTP API stayed reachable.

A direct LiteLLM request and a fresh 2.0.28 standalone process succeeded. A CLI request against the same old server also failed after 85.98 s. Restarting only that external service, with current sessions idle, loaded 2.0.28 and recovered the same endpoint/model/worktree. This demonstrates installed/serving version divergence and recovery after process replacement; it does not prove a 2.0.27 bug, because restart and version change happened together.

The installed V2 code chooses probeOpenCodeServer when serverUrl is set, and checkOpenCode2 uses that serving version. The successful runtime probe is memoized until refresh, and OpenCode2Server.withConnection retains its successful external connection. That is a different path from the V1 inventory overwrite described above. I did not reproduce a failed Update now verification or the original toast, and #18561 correctly keeps external-server version authoritative.

The useful related diagnostic would be to distinguish the locally installed CLI from the serving process when they are on the same host, and explain that upgrading the binary does not replace a user-owned server. Any restart must respect external ownership and active sessions.

Detailed controls and the independently verified hidden V2 plugin-load failure. The underlying model transport failure is not established as a T3-only defect; the initial network trigger remains unproven.

Confirmed again on 16 October 2026 (AEDT), this time with the post-update warning visible. This extends my earlier external-server report.

Environment: macOS 26.7.1 arm64, T3 Code 0.0.46-nightly.20261015.3176, OpenCode V2 installed through Homebrew opencode-v2. T3's OpenCode instance has binaryPath: "opencode" and an authenticated external serverUrl: "http://127.0.0.1:4096". A user launchd service owns that server.

Observed before repair:

• opencode --version: opencode v2.0.30.
• brew list --versions opencode-v2: opencode-v2 2.0.30. The Homebrew executable symlink points into the 2.0.30 Cellar directory.
• Authenticated GET /api/info: version: "2.0.29", PID 21562.
• lsof confirms PID 21562 still has the 2.0.29 Cellar executable mapped.
• T3 shows OpenCode v2.0.29, an update badge, and "Update command completed, but T3 Code still detects an outdated provider version." Its suggested command is brew upgrade opencode-v2.
• Running opencode upgrade manually selects brew and says "OpenCode upgrade skipped: 2.0.30 is already installed".

The two versions are real: the installed CLI is current while the external serving process is old. Reporting the serving version is correct for runtime compatibility. The missing step is explaining that reinstalling/upgrading the CLI cannot replace this independently managed process.

There were active OpenCode runs in other T3 threads. After explicit approval to interrupt them, I restarted only the external service:

After repair, the same authenticated endpoint reports version: "2.0.30", PID 46128. A fresh CLI request through that same endpoint and litellm/deepseek-v4.1-flash exited 0 and returned the requested OPENCODE_2030_OK. No T3 restart or provider configuration change was needed. The refreshed T3 settings UI was not independently verified.

Suggested handling: distinguish installed CLI and serving versions where both can be established; show "CLI updated; external server restart required" rather than repeatedly offering the same installation command. Keep the external server authoritative, account for a remote server potentially being on another host, and require explicit consent before interrupting active runs. The service name above is local configuration, not something T3 should assume.

#18561 addresses the T3-owned V1 helper case and explicitly leaves V2 unchanged, so this external V2 update/restart guidance remains relevant.

Model: gpt-6.1-sol, high reasoning. Harness: Codex through T3 Code.