You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(tui): replace 500ms sidebar poll with persistent WebSocket (#200)
The TUI sidebar polled the server plugin every 500ms over localhost HTTP.
The TUI runner and server runner are separate Bun contexts in the same
process, so each poll opened a fresh loopback TCP connection (Bun's fetch
isn't pooled to our server) — ~10ms of client work twice a second, idle,
forever. That was the entire source of idle TUI CPU: a few percent on fast
machines, ~20% on slower ones, additive per sidebar plugin.
Replace the poll with a single persistent WebSocket. The RPC server moves
from node:http to Bun.serve, keeping all HTTP request/reply routes unchanged
and adding a /ws endpoint; the server pushes each queued notification over
it the instant it's queued. isTuiConnected is now exact socket liveness
instead of a 3s poll-drain window, so server-initiated dialogs route to the
TUI reliably. Bearer-token auth in the hello, per-session scoped delivery,
backlog replay on (re)connect, auto-reconnect with port rediscovery. The
client keeps a property-read-only session watcher (no network at idle) to
re-scope the socket on session switch.
Deletes the dead poll path (pending-notifications handler, consumeTuiMessages).
Pi is unaffected (it does not import the RPC server/client).
A patch release fixing high idle CPU from the TUI sidebar.
4
+
5
+
## Fixes
6
+
7
+
-**High idle CPU from the TUI sidebar (#200).** The sidebar polled the plugin every 500ms over a localhost connection. Because the TUI and the plugin run in separate runtimes inside the same process, each poll opened a brand-new loopback connection, so an idle session kept burning CPU continuously (a few percent on fast machines, noticeably more on slower ones, and additive when other sidebar plugins were also installed). The sidebar now holds a single persistent WebSocket to the plugin and receives updates the instant they happen, instead of polling. Idle CPU drops back to baseline. Thanks to @null-axiom for the report and the cross-plugin cross-check that pointed at the shared mechanism.
8
+
9
+
As part of this, the plugin's detection of whether a TUI is connected is now based on the live connection itself rather than a recent-poll timeout, so server-initiated dialogs (`/ctx-status`, `/ctx-recomp`, the upgrade prompt) route to the TUI reliably instead of depending on timing.
"Local embeddings work on OpenCode Desktop again (#195): /ctx-embed no longer fails with 'Unsupported device: cpu' on the Desktop app.",
34
+
"Fixed high idle CPU from the TUI sidebar (#200): it now uses a single persistent connection to the plugin instead of polling, so an idle session no longer burns CPU.",
0 commit comments