Skip to content

[FEATURE]: Cross-project session event bus + a documented plugin-safe way to subscribe to it #45549

Closed as not planned

Description

@Nikit-04ka

Feature hasn't been suggested before.

  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

[FEATURE]: Cross-project session event bus + a documented plugin-safe way to subscribe to it

(drafted after building a subagent-monitoring plugin on Desktop v1.18.23 / Windows 11; complements #38604)

Problem

There is currently no working path for a plugin (or any local client) to observe session activity across all of a user's projects:

  1. The plugin event hook is dead in the Desktop app — tracked in Desktop app: local plugins load and register but their hooks (tool.execute.before, event) are never invoked #38604. In our repro the hook receives zero calls while tasks run (seen: {}).
  2. Subscribing from inside the plugin via the SDK hits version drift: the documented surface exposes client.event.list() per current docs, but the runtime client here only ships client.event.subscribe(). Feature-detecting both works, but this is an undocumented contract that can silently break again.
  3. Whatever subscription method is used, /event only delivers server.connected / server.heartbeat — no session.created, session.updated, message.part.updated, no tool events — even while agents are actively running in known project directories. This holds both for the unscoped stream and for { query: { directory } } variants.
  4. The only channel that works at all is polling client.session.list({ query: { directory } }) separately for every project directory — and discovering those directories requires scraping the Desktop app's internal state files (%APPDATA%/ai.opencode.desktop/opencode.global.dat), which is unsupported and will break silently.

Net result: we built a live subagent tree dashboard (localhost SSE page showing task → @explore/@general subagents → tools) and ~80% of its plumbing exists solely to work around the missing event access.

Field observations (reproducible)

  • Desktop v1.18.23, Windows 11; single NodeService core process hosts all workspaces (verified: one API listener, one app instance).
  • Plugin loaded globally from ~/.config/opencode/plugins/; visible in UI as active (matches Desktop app: local plugins load and register but their hooks (tool.execute.before, event) are never invoked #38604).
  • Hook probe instrumented to count every received event by type across restarts and multiple real agent runs: event hook — 0 invocations ever; SDK stream — server.* only; session.list polling — returns sessions when scoped to the right directory, empty otherwise.
  • SDK client keys confirmed at runtime: event.subscribe present, event.list absent (docs say otherwise).

Proposal

  1. A global scope for the event stream, e.g. /event?scope=all (or X-Scope: global), delivering session.* / message.part.updated / tool events for every directory served by that core, without requiring callers to know every workspace path.
  2. Pin down and document one SDK subscription entry point usable from plugins (event.subscribe vs event.list — today they diverge between docs and runtime builds), ideally with a stable signature and an explicit promise of shape stability.
  3. Carry parent lineage on session events so consumers can build subagent trees without cross-referencing lists: session.created already has info.parentID, but idle/status does not (session.status event should include parentID to distinguish subagent sessions #30043), and list endpoints lack a parentID filter (v2: add parentID filter to session list #34936). Standardizing this would make subagent observability nearly free.
  4. (Stretch) any mechanism for a plugin/UI contribution to render out-of-band output (panel, toast, sidecar page) so monitors like ours don't need to bootstrap their own HTTP server on a random port (today: port-collision races between opencode instances).

Related

Happy to contribute a PR for the global-scope flag if pointed at the right dispatch site — we have a real-world consumer (the dashboard plugin) to validate against.

Activity

  1. Nikit-04ka commented on Oct 21, 2026

    @Nikit-04ka
    Author

    Update after testing on Desktop 2.1.2 (Windows 11):

    Most of this request is now covered by the v2 plugin API — confirming from a real consumer:

    • input.event.subscribe(...) in the v2 plugin input delivers the full cross-project bus: session.created/updated/renamed, session.execution.started/completed/failed, session.tool.called/progress/success/failed, session.reasoning.*, session.text.*, each tagged with location.directory. A live subagent-tree dashboard plugin now runs purely off this stream. Thank you!

    Three follow-ups that would save the next plugin author a day of debugging:

    1. Docs lag: the plugins page (updated Oct 20) still describes the v1 shape — a named-export function + client.event.list(). On v2 that silently doesn't work: client is absent from the plugin input, event.list doesn't exist at runtime. The actual v2 contract — default export { id, server } (PluginModule) and the namespaced input.event.subscribe — is only discoverable by reading the published types. A migration note on the plugins page would fix this for everyone.
    2. The legacy event hook still doesn't fire on Desktop 2.1.2: returning { event: async ({ event }) => ... } from the plugin produces zero invocations across multiple agent runs (matches Desktop app: local plugins load and register but their hooks (tool.execute.before, event) are never invoked #38604). Either it should fire, or its removal from the supported surface should be documented.
    3. 2.0.x transitional behavior: with default { id, setup } on CLI 2.0.28, setup is invoked without the documented input (no client, no directory). If that path is meant to be supported, it should receive the same input as server; if not, worth a release note.

    Happy to close this issue if you consider the bus part done — or to keep it open as the tracking item for the docs/migration fixes above. The dashboard plugin is available as a test consumer either way.

  2. opencodejr commented on Oct 28, 2026

    @opencodejr

    Thanks for the detailed write-up and for building the dashboard plugin.

    This report is about OpenCode v1 (Desktop v1.18.23). v1 only gets fixes for critical bugs such as data loss, security problems, or crashes with no workaround. Feature requests and enhancements like a global event scope or changes to the SDK subscription surface are unlikely to be added there.

    The plugin event hook not firing in Desktop is already tracked in #38604. Related:

    Please consider upgrading to v2 (the @opencode/cli package, opencode command). It's a separate implementation with a different plugin system, so the v1 event hook and /event behaviour described here don't apply directly. If cross-project session observability is still missing for you on v2, a new issue describing it against v2 would be very welcome. If you think something here is critical in v1, please reply and explain why.

  3. opencodejr commented on Oct 29, 2026

    @opencodejr

    Closing this as not planned. It's a feature request for OpenCode v1 (Desktop v1.18.23), and v1 only gets fixes for critical bugs. We didn't hear back that this is critical or that it also happens on v2.

    The Desktop plugin event hook not firing is still tracked in #38604.

    If you move to v2 and still can't watch session activity across projects from a plugin, please open a new issue for v2. Thanks again for the detailed write-up.

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

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions