Repository navigation
Description
Description
Desktop 2.1.2 on macOS logs event stream disconnected once per second for the entire session (11768 lines in one run) and event stream connected exactly zero times.
The cadence is mechanical: gaps between consecutive lines are 1001-1004 ms (median 1002 ms), and the three full hours 17:00/18:00/19:00 logged 3588 / 3584 / 3583 lines. It does not depend on user activity.
What I could rule out:
- The server is healthy. Running the same opencode-cli serve binary standalone, the server.connected first frame arrives in 21 ms, then a heartbeat every 15 s, and the server keeps the stream open for well over 25 s.
- The request hits the right endpoint. ~/.local/share/opencode/log/opencode.log contains 509 http.url=/api/event responses with status 200 and 0 for /global/event - so this is not the /global/event vs /api/event mismatch.
- In one run the server log ends like this: 4 seconds after accepting two SSE requests, mcp transport error repeats, command.updated repeats, all 27 watchers log watcher stopped within the same millisecond, and that process never logs anything again. The client starts its 1 Hz reconnect loop at exactly that moment.
So the connection is accepted, kept for a few seconds, then torn down together with that server-side reload, and the client never receives server.connected. It then retries at a fixed 1 s interval forever.
Two related problems make this impossible to diagnose from user reports:
- packages/app/src/runtime/server/client.tsx:99-103 passes an object into console.info, so renderer.log only ever contains [object Object] - the actual ClientError reason is discarded.
- packages/client/src/solid/connection.ts:158-162 increments attempt but never uses it to grow the delay, so the reconnect wait is constant.
Plugins
./plugins/context-guard, ./plugins/oc-bridge, billion-context - all three are ruled out: the remote SSE has a 5 s backoff and the single-instance lock keeps inactive instances offline.
OpenCode version
Desktop 2.1.2 (~/Library/Application Support/ai.opencode.desktop/cli/2.1.2-arm64/opencode-cli, --version reports 2.1.2), channel latest.
Steps to reproduce
- Open desktop 2.1.2 on any project.
- Do nothing for a minute.
- Count both lines in the renderer log:
grep -c "event stream disconnected" ~/Library/Application\ Support/ai.opencode.desktop/logs/*/renderer.log
grep -c "event stream connected" ~/Library/Application\ Support/ai.opencode.desktop/logs/*/renderer.logObserved: about 60 disconnected per minute, connected always 0. All 26 runs between 2026-10-14 and 2026-10-21 match, across 2.0.29 through 2.1.2.
- Compare with the server log for the same run id:
grep -a "run=<same run id>" ~/.local/share/opencode/log/opencode.log | tail -20Observed tail (local time 20:47):
20:47:49.764 GET /api/event -> 200
20:47:49.769 GET /api/event -> 200
20:47:53.409 WARN mcp transport error server=codegraph "MCP server process exited"
20:47:53.410 WARN mcp transport error server=chrome-devtools "MCP server process exited"
20:47:53.41x INFO event command.updated (repeating)
20:47:53.41x INFO watcher stopped (all 27 watchers at once)
20:47:53.4xx nothing further for this run
Screenshot
No response
Operating System
macOS 27.0.1(arm64)
Terminal
Electron;oc://renderer
Activity
opencode-agent commentedon Oct 21, 2026
Thanks for the detailed report and logs. I couldn't reproduce this here: it needs the desktop app on macOS and the server process it starts for itself, and my sandbox can't run that. It will need a maintainer with that setup.
A few things from the current code that may help:
renderer.logwill never containevent stream connected. The desktop app's logger only passes theevent stream disconnectedmessage through, so a count of 0 doesn't mean the stream never connected.reconnectDelay) by design. Still, a steady ~1002 ms gap means each attempt fails almost immediately, not by timing out (that would take about 3 s per cycle). That fits your observation that the desktop's server process stops logging after the MCP errors and watcher shutdown, and the client keeps retrying it.[object Object].These would help: does the app actually stop working (sessions not updating, prompts failing) during these runs? And is the
opencode-cliprocess still running (ps aux | grep opencode-cli) once the disconnect loop starts?