Skip to content

Desktop 2.1.2:event stream #57807

Open
Open

Description

@n10z

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

  1. Open desktop 2.1.2 on any project.
  2. Do nothing for a minute.
  3. 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.log

Observed: 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.

  1. Compare with the server log for the same run id:
grep -a "run=<same run id>" ~/.local/share/opencode/log/opencode.log | tail -20

Observed 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

  1. opencode-agent commented on Oct 21, 2026

    @opencode-agent
    Contributor

    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.log will never contain event stream connected. The desktop app's logger only passes the event stream disconnected message through, so a count of 0 doesn't mean the stream never connected.
    • The 1 s retry delay is a fixed constant (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.
    • You're right that the error reason is lost as [object Object].

    These would help: does the app actually stop working (sessions not updating, prompts failing) during these runs? And is the opencode-cli process still running (ps aux | grep opencode-cli) once the disconnect loop starts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions