Repository navigation
upgrade: long-running serve from previous version keeps running after auto-update (404 on /api/status, service exits) #49664
Description
Summary
After an auto-update (autoupdate: true, 2.0.5 → 2.0.7), the previously running background serve process is not stopped. The stale process keeps reconnecting to the new installation: /api/status returns 404, service registration data appears missing/overwritten, and the background service exits. Killing the stale process restores normal startup.
Environment
- opencode version: 2.0.7 (upgraded from 2.0.5)
- OS: macOS (Darwin 27.0.0, arm64)
- Terminal: Ghostty, TERM=xterm-256color
- Shell: /bin/zsh
- Install/channel: latest (npm
@opencode/cli),autoupdate: true - Active plugins:
/Users/zhangxiaokang/Workspace/opencode2-quota
Reproduction
- Start opencode's background service (e.g.
opencode serve) and leave it running. - Keep that process alive, then install / auto-update to a newer version (here 2.0.5 → 2.0.7).
- Observe the previous-version
serveprocess continuing to run and reconnect to the updated on-disk state. - Use the service / open a session.
Expected Behavior
- An upgrade should terminate or cleanly hand off the long-running
serveprocess from the previous version, or otherwise prevent a stale process from reconnecting against the new installation. - The background service should stay healthy after the upgrade.
Actual Behavior
- The old process logs repeated reconnection attempts and
/api/statusreturns 404. - Service registration data appears lost / overwritten ("service registration file …", "background service exited").
- The background service exits and opencode appears broken until the stale process is killed manually.
Additional Context
- Frequency: occurred once, immediately after the upgrade, only while a stale previous-version
serveprocess was still alive. Killing that process recovered startup instantly; not reproducible when only a single current-version process is running. - Workaround: terminate all stale opencode processes before/after upgrading, or restart the service after the upgrade.
- Related but separate: this environment also overrides the data location via the
OPENCODE_DBenv var; that caused a different symptom (sessions appearing missing due to the wrong DB being opened by a non-interactive start), not the 404/registration failures described here.
Activity
github-actions commentedon Sep 18, 2026
This issue might be a duplicate of existing issues. Please check:
serveprocess alive that holds the service lock while the new version is installed, causing the new version's startup to fail. That issue is now closed, so if you are hitting this on v2.0.7, it may be a regression or a related but distinct edge case worth noting here.Server process exited with code 130in the log.opencodejr commentedon Oct 28, 2026
Thanks for the detailed report. I reproduced this on 2.0.5 → 2.0.7:
/api/status. That endpoint doesn't exist in 2.0.7, so it gets a 404. It then stops the 2.0.7 service and starts a 2.0.5 one again, overwriting the service registration.This restart logic is in the old 2.0.5 code, so it can only be avoided by stopping old processes after an upgrade from 2.0.5 or earlier, as you did.
I then ran the same steps on the latest release, 2.2.0, with 2.1.4 as the leftover old version. Newer clients now reuse the running service even when its version differs, so the service was never swapped back and forth. I couldn't run the latest
devfrom source here, but it has the same behaviour. This looks already fixed for upgrades between current versions.The script below reproduces it in a temporary
HOME. The bot will close this issue in 1 day unless you reply that it still happens, for example when upgrading from 2.1.x or later.opencodejr commentedon Oct 29, 2026
Closing this as completed, since we haven't heard back in the last day.
To recap: I reproduced the service swapping back and forth when upgrading from 2.0.5 to 2.0.7 while an older 2.0.5 process was still running. The health endpoint changed between those versions, so the old process saw a 404 on
/api/statusand restarted its own service. With the same steps on the latest release (2.2.0), the service was not replaced: newer clients reuse the running service even when its version differs. So this is most likely fixed, and the fix should also be in the next release. For upgrades from 2.0.5 or earlier, stopping old opencode processes after the upgrade avoids it.If it still happens for you on 2.1.x or later, please comment here or open a new issue with the versions involved and the service log. Thanks again for the detailed report!