Sign up
View stargazersSign up

[Bug]: OpenCode Update now still reports outdated when configured localhost server runs older binary#22869

opened20d agobyIintrepid37

Before submitting

  • Searched existing issues. Related: #13010 (closed), but that report uses Server URL empty / T3-managed helper, whereas this reproduction uses a nonempty loopback Server URL / independently running OpenCode server.
  • Included reproducible steps and sanitized terminal evidence.

Area

apps/server — OpenCode provider update and post-update verification; Settings → Providers UI.

What happened

The OpenCode Update now button reports:

Update command completed, but T3 Code still detects an outdated provider version.

The updater successfully installed the latest @opencode/cli (2.1.2), but the independently running OpenCode server continues to report its old version (2.0.32). The provider row remains outdated even after an update attempt. The Update button still appears not to work in the UI; this is not a verified working end-to-end flow.

Steps to reproduce

  1. On Linux, install OpenCode 2 via npm in a user-global prefix (@opencode/cli).
  2. Launch an independent opencode serve --hostname=127.0.0.1 --port=<port> and leave it running on the old version.
  3. In T3 Code Settings → Providers, enable OpenCode and set Server URL to http://127.0.0.1:<port> and Binary path to the installed npm package's binary.
  4. When an update is available, click Update now. The npm update succeeds and replaces the installed binary.
  5. The existing server process is not restarted and continues reporting the old version. T3 marks the update as unchanged/outdated and offers to update again.

Sanitized evidence (captured while investigating)

ProbeObserved version
T3 Settings → Providers OpenCode row2.0.32
Configured OpenCode CLI, --version2.1.2
npm-installed @opencode/cli package2.1.2
Running opencode serve executable from /proc/<pid>/exe --version2.0.32
Saved T3 provider advisorybehind_latest, current 2.0.32, latest 2.1.2

On Linux, /proc/<pid>/exe for the long-lived server pointed to a deleted/replaced executable from the prior npm installation. The user-global CLI path pointed to the newly installed executable. This confirms the install updated while the server process remained on the previous version.

The update command in the provider advisory was an npm global install of @opencode/cli@latest into the configured user prefix. The success exit code alone did not mean the long-lived server had reloaded.

Expected behavior

  • After a successful CLI upgrade, verify the installed CLI version separately from the running server version.
  • If the installed CLI is current but the configured localhost server is still older, say “CLI updated; restart the configured server to apply” rather than claiming the package is still outdated.
  • Do not automatically terminate a separately managed server with potentially active agent sessions.
  • Once that server has been safely restarted, recheck and display its new runtime version.
  • For truly remote servers, do not assume a locally installed CLI is the same installation as the remote server.

Environment

  • T3 Code server on Ubuntu Linux aarch64, T3 runtime 0.1.1 when observed.
  • OpenCode 2, installed as npm-global @opencode/cli.
  • Separate OpenCode server bound to loopback, configured via nonempty Server URL.
  • The update is not fixed in the user's running T3 setup.

Workaround

After an npm update, restart the separately managed OpenCode server at a safe time when sessions can be interrupted, then refresh provider status. This applies the updated binary, but it is not a fix for the update button's misleading result.

  • #13010 — older, closed issue with the same stale-running-server class but a T3-owned helper and empty Server URL.
  • #22741 — different root cause: Vite+ shim picks an installation other than the one updated.

No passwords, tokens, personal chat contents, machine-specific usernames, or private paths included.

Ffearandesire18d ago
Synced from GitHub

Windows/Nightly confirmation and verified workaround

This also occurred on Windows 11 x64 with T3 Code Nightly 0.1.2-nightly.20261022.3541. It matches this issue's nonempty Server URL / independently running server case. Adding evidence here after checking related issues and PRs, including the open fix #22839.

The important Windows detail is that the configured npm CLI and the running server were separate executables from different installations. The server was using a desktop-bundled OpenCode 2.0.32 executable, while the configured npm CLI was already 2.1.3. This case does not require Linux's deleted-but-still-running executable behavior.

Configuration and observed behavior

  • T3 Nightly desktop, connected to its local Windows backend.
  • OpenCode provider enabled.
  • Binary path: %APPDATA%\npm\opencode.cmd, resolving to @opencode/cli.
  • Server URL: http://127.0.0.1:<port> (nonempty; port redacted consistently).
  • Running server executable: %APPDATA%\ai.opencode.desktop\cli\2.0.32-x64\opencode-cli.exe serve --service.
  • The user reported that pressing the provider's update button did not clear the outdated state.

After that update attempt, direct checks showed:

CheckResult
Configured CLI --versionopencode v2.1.3
Installed @opencode/cli package version2.1.3
npm registry's latest @opencode/cli at investigation time2.1.3
Live configured server GET /api/infoversion: 2.0.32
T3 provider snapshotready, version 2.0.32
T3 version advisorybehind_latest, current 2.0.32, latest 2.1.3, canUpdate: true

The provider advisory targeted an npm global install of @opencode/cli@latest into the configured npm prefix. The service continued running its older desktop-bundled executable.

Reproduction conditions

  1. Have an independently managed OpenCode 2 server running an older version.
  2. Configure T3's OpenCode Server URL to that server and Binary path to an npm-managed CLI. In this Windows case, the server executable came from the desktop installation, and the CLI came from npm.
  3. Use T3's provider update action to update the npm CLI while the independent server remains running.
  4. Compare the configured CLI's --version with the server's /api/info.
  5. Observe that T3's advisory continues to use the old server version and offers another local CLI update.

This was investigated in place after the reported update attempt. A fresh, isolated downgrade-and-upgrade reproduction was not performed.

Evidence and diagnosis

Relevant trace spans for the update attempt ended with exit._tag: Success:

text
1ProviderMaintenanceRunner.runCommand
2ProviderMaintenanceRunner.runCommandAndVerify
3ProviderMaintenanceRunner.updateProvider
4ws.rpc.server.updateProvider

These are trace span outcomes, not a separate capture of the install command's shell exit code. The direct CLI/package/server probes above establish the version mismatch.

The installed server bundle was inspected. The same relevant branches are present on upstream main at 22840ab943b8418744b48223411e46ba4fdcef1a:

Those are pinned upstream references, not a claim that this commit is the exact source commit of the installed nightly.

The update action and version check therefore refer to different installations. The expected distinction is “installed CLI is current; configured server is still older and needs its own update/restart”. Restarting an arbitrary external server automatically would risk interrupting work.

Workaround and verification

After confirming there were no active OpenCode runs in T3 and backing up the OpenCode databases/configuration, the supported restart command was run through the updated npm CLI:

powershell
1& "$env:APPDATA\npm\opencode.cmd" service restart
2& "$env:APPDATA\npm\opencode.cmd" api GET /api/info

Verified results:

  • Restart exited successfully.
  • The same loopback endpoint reported version: 2.1.3.
  • Its listening process now used %APPDATA%\npm\node_modules\@opencode\cli\bin\opencode.exe.
  • T3 initially retained the old cached version. After Refresh provider status, the UI showed 2.1.3; a subsequent provider snapshot independently confirmed version: 2.1.3, status: ready, and advisory status: current.
  • Existing session IDs remained present, database checks passed, and configuration/credential files and T3 settings were unchanged. T3 itself was not restarted.

This verifies the workaround, not a fix to T3's update action. The subsequent isolated evaluation of #22839 is below.

Related reports: #13010 concerns the T3-managed helper/empty Server URL case; #22741 concerns Vite+ shim routing. This Windows incident matches #22869 instead.

No raw logs, databases, credential files, screenshots, personal names, machine names, home-directory paths, session identifiers, or actual port values are attached.

Follow-up: PR comparison and proposed fix

Tested #22839 at 4538f0068417bd568f051ecb106becaf7bdaaf0d in an isolated Linux/WSL checkout. Its 33 focused tests passed. Two additional characterization cases also passed, demonstrating that its advisory follows the installed CLI:

Installed CLIRunning serverAdvisory after refresh
2.1.32.0.32current, currentVersion 2.1.3
2.0.322.1.3behind_latest, currentVersion 2.0.32

An added regression for the web success notification failed: it displays “New sessions will use the updated provider.” instead of the PR's server-restart instruction. Source inspection also found that Settings only displays updateState.message for failed/unchanged updates. Thus #22839 corrects post-command verification, but a current CLI can still hide an outdated configured server without visible guidance.

PR #23859 proposes a different fix for the same underlying bug: use the existing manual-only capability whenever Server URL is configured, including loopback. The advisory stays tied to the running server, names the latest version, and explains how to update/restart the server through its owning app or tool, then refresh status. T3-managed local instances retain automatic CLI updates. The PR credits #22839 and documents the tradeoffs, including configured loopback servers that happen to share the local CLI installation.

Both external-server regressions failed on main before the fix and pass after it. The final seven driver tests and vp run check:changed pass. Claude Fable 5.1 independently reviewed the design; its missing-version-message finding was reproduced and fixed. These checks used isolated fixtures, not the patched desktop UI or a live server upgrade.

Investigated and written with GPT-6 Astra through the Codex harness in T3 Code. Submitted directly using the repository's reporting guidance; a full npx t3 triage session was not launched. Implementation and testing by the same model/harness; adversarial review by Claude Fable 5.1 through the Claude Agent harness.