desktop: supervisor respawns a live local service every ~60s (reason: 'missing'), aborting every tool call #61061
Description
Summary
The desktop supervisor repeatedly declares its live local background service missing and respawns it every ~60 seconds. Each respawn kills any tool call in flight (Tool execution interrupted), so the session becomes unusable while the app looks healthy. Quitting and reopening the app did not clear it; a full OS reboot did.
Environment
- opencode version: 2.2.5 (desktop app, bundled CLI
2.2.5-arm64) - OS: Darwin 25.2.0 arm64 (macOS, Apple silicon)
- Terminal: Unavailable: desktop app, not a terminal session
- Shell:
/bin/zsh - Install/channel: release build, updater reported
Update for version 2.2.5 is not available (latest version: 2.2.5)and stateup-to-date - Active plugins: 22 local plugins auto-loaded from
~/.config/opencode/plugins/*.ts
Reproduction
Not reproduced on demand; it appeared after ~10 hours of app uptime with a session attached to the local background service.
- Work in a desktop session served by the local background service.
- The app's
main.logbegins logging, every ~60 s:starting v2 background service→v2 CLI background service starting { reason: 'missing' }→v2 CLI background service ready { probed: false, url: 'http://127.0.0.1:<port>' }. - Every tool call in the session fails instantly with
Tool execution interrupted; each failure arrives with a tool-catalog reload, which alternates between two catalog variants (with and without MCP-server tools).
Expected Behavior
The supervisor should see the healthy running service (it never stops answering; a fresh GET /api/info on its loopback URL returns 401 i.e. alive) and not respawn it. Tool calls should complete.
Actual Behavior
12 respawns in 18 minutes, each killing in-flight tool calls. The service itself was never unhealthy from the outside: no crash, and the process kept listening on its loopback port throughout.
Excerpt from ~/Library/Application Support/ai.opencode.desktop/logs/<launch-timestamp>/main.log (one log directory per app launch; truncated noise removed):
[2026-11-01 13:52:11.381] [info] (main) starting v2 background service
[2026-11-01 13:52:17.442] [info] (main) v2 CLI background service starting { reason: 'missing' }
[2026-11-01 13:52:22.839] [info] (main) v2 CLI background service ready {
runningVersion: '2.2.5',
probed: false,
url: 'http://127.0.0.1:49374',
hostname: '127.0.0.1',
port: '49374'
}
[2026-11-01 13:53:15.631] [info] (main) starting v2 background service
[2026-11-01 13:53:21.697] [info] (main) v2 CLI background service starting { reason: 'missing' }
[2026-11-01 13:53:27.065] [info] (main) v2 CLI background service ready {
runningVersion: '2.2.5',
probed: false,
url: 'http://127.0.0.1:49374',
hostname: '127.0.0.1',
port: '49374'
}
grep -c "starting v2 background service" on that launch's log: 15 total, 12 of them with reason: 'missing', all between 13:52 and 14:10. grep -o "reason: '[a-z-]*'" yields only 'missing'.
Additional Context
- No crash: each launch's
crash.logcontains only(crash) crash reporter started { path: '.../Crashpad' }. No stack traces, no Crashpad reports. - Not resources: 80 % system memory free during the loop;
ulimit -n= 1048576,kern.maxfilesperproc= 61440; the service's fd count was normal. - Not our plugins:
grep -rnE "process\.exit|server\.stop|restart-opencode|\.kill\(" plugins/*.tsreturns no matches, so no local plugin stops or restarts the service. - Workarounds tried: quitting and reopening the app did not help (the loop resumed under the new launch); a full macOS reboot cleared it, and the service then logged exactly one start for the new launch.
- Diagnosability gap:
~/.local/share/opencode/log/opencode.logis truncated at every start, so the server-side reason the supervisor concluded "missing" is destroyed by the very restart this bug triggers. Only the desktopmain.logsurvives. Keeping one rotatedopencode.logwould make this class of bug actionable. - Possibly related: service: relaunch fails with "Managed service port already in use" when previous background service has not exited #54267 (relaunch fails with "Managed service port already in use"), desktop: background shell reports Shell.NotFoundError after the local service restarts #57977 (background shell reports
Shell.NotFoundErrorafter the local service restarts), desktop: background service spawn fails "port in use" on Windows/WSL2 mirrored networking — app stuck at logo, error not logged #55907 (background service spawn fails "port in use" on Windows/WSL2) — all involve the supervisor spawning a service that has not exited, but none describes a repeatedreason: 'missing'respawn of a healthy service on macOS.
Activity
opencodejr commentedon Nov 1, 2026
Thanks for the detailed logs and checks. I can't reproduce this here: it needs the desktop app on macOS running for many hours, and the trigger isn't known yet. My sandbox is Linux-only and has no desktop build.
From the code, the pattern in your
main.logmatches one specific path. The desktop reconnects (starting v2 background service,probed: false), and about 6 s later the client gives up after three/api/infoprobes in a row each go unanswered for 2 s. It then treats the service as gone (reason: 'missing'), stops it and starts a new one, which interrupts any tool call that is running. So the service was probably alive but slow to answer those probes, even though your own outside check got a quick401. Something was also making the desktop reconnect about every 60 s.A maintainer with a Mac will need to look at this. If it happens again, these would help most:
~/.local/share/opencode/log/opencode.log(it is cleared on every start, as you noted).event stream disconnectedlines in that launch'srenderer.log, to show what triggers the reconnect every minute.opencode-cli serve --service) kept the same PID across the respawns.Related issues, most likely first:
reason: 'missing'loop, caused by snapshot work blocking/api/info(closed as fixed before 2.2.5)