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
{{ message }}
Repository navigation
[FEATURE]: expose more v2 session APIs to plugins #47229
This recreates #35443, which was automatically closed after 60 days of inactivity.
Describe the enhancement you want to request
While porting a plugin from the v1 plugin API to the v2 plugin API, I ran into a small gap in the public session runtime.
The v2 plugin context already covers prompt, command, interrupt, wait, and compact (compact landed in #52385). Two session APIs that already exist elsewhere in opencode are still not available to plugins:
These are useful for plugins that coordinate work around the current session. For example, a queue plugin may need to run a shell command in session context, or check if the current run is still active before sending the next item (wait covers the blocking case, active covers the pollable check).
Thanks for recreating this and for the clear use case!
To restate it: you'd like the v2 plugin context to expose two session operations that already exist elsewhere in opencode. One is context.session.shell(...), to run a shell command in a session's context. The other is context.session.active(...), a non-blocking check for whether a session is still running, alongside the existing prompt, command, interrupt, wait and compact.
I checked the current dev code. The plugin session domain in packages/core/src/plugin/host.ts has neither operation, so a plugin can't do this today. Core already tracks active executions and runs session shell commands, so this would mean exposing existing functionality to plugins. Maintainers will consider it.
Activity
opencodejr commentedon Oct 28, 2026
Thanks for recreating this and for the clear use case!
To restate it: you'd like the v2 plugin context to expose two session operations that already exist elsewhere in opencode. One is
context.session.shell(...), to run a shell command in a session's context. The other iscontext.session.active(...), a non-blocking check for whether a session is still running, alongside the existingprompt,command,interrupt,waitandcompact.I checked the current
devcode. The pluginsessiondomain inpackages/core/src/plugin/host.tshas neither operation, so a plugin can't do this today. Core already tracks active executions and runs session shell commands, so this would mean exposing existing functionality to plugins. Maintainers will consider it.Related issues:
activedelivery: "queue"onsession.shell, which may matter ifshellis exposed to plugins