dsh-event-relay

In DeepSeek Harness, the browser-to-host direction is transactional HTTP: the frontend asks, the host replies. The reverse—host-side events such as a setting change, a finished build, or an incoming notification reaching the browser UI in real time—has no natural push path. Polling adds latency and burns resources; one EventSource or WebSocket per plugin quickly exhausts the browser's roughly six concurrent connections per domain, queuing every other request behind them. dsh-event-relay was built to close that gap.

Under the hood the plugin registers a single shared SSE route, /relay/events, on the host. Every subscribing plugin in a browser tab rides the same one connection. The host calls publish(topic, payload) to emit JSON messages; the server filters by hierarchical topic (subscribing to kanban also receives kanban/change) and only pushes what the current tab actually listens for. When the stream re-opens, a synthetic __relay/open message lets consumers resynchronise anything missed during downtime. The payload field is fully optional: carry complete state, or send a bare topic as a doorbell and let the consumer refetch its own truth. Both styles are first-class.

Any DSH host-side plugin that needs the browser UI to react the instant something changes on the host should consider this relay. It does not replace Cordis as the host event system—it simply carries messages across the plane boundary—with zero external dependencies and nothing to wire beyond installing the package. dsh-granular-settings already uses it to broadcast doorbell-only change notifications for scoped settings, making it a working reference for the pattern.