Session handoff: let one session trigger another #36972

What would you like OpenCode to be able to do?

I'd like one session to be able to automatically notify/trigger another session to start working, without the user manually switching to that session and pasting a message.

Concrete use case: In Desktop, with two sessions open in tabs, I ask session A to write a news article. When A finishes, I'd like A (or the system) to tell session B: "the script is ready, start producing the video from it" — and B should automatically begin, the same way it would if I'd typed that message into B myself.

What would this enable?

• Session chaining / pipeline workflows: A hands off to B, B hands off to C — without human glue in between.
• Specialized-agent collaboration: e.g. a "writer" session → an "animator" session → a "reviewer" session, each with its own agent/runner config, triggered sequentially from one upstream action.
• Less manual tab-switching: for users who keep multiple purpose-built sessions open (write / render / review), this removes copy-paste friction between them.
• Feature parity baseline: at least one other AI-coding agent (ClawX) ships automatic inter-session notification; would be a natural fit for OpenCode's multi-session model.

What's the current situation?

Right now OpenCode sessions are fully isolated contexts. The only paths to "notify B from A" are:

1. Manual file handoff — A writes to a file, the user switches to B and types "read @news-script.md and start". Works, but the user still has to manually switch to B and type the trigger. Feels like a workaround, not automation.
2. HTTP Server API — POST /session/:id/prompt_async can inject a message into B programmatically. Powerful, but requires running opencode serve --port N, fetching session IDs via /session, and the caller (A's bash tool or an external script) to know the HTTP endpoint and the target session ID. Not exposed as a first-class action in the TUI/Desktop, so not "automatic" from the user's seat in a session.

Neither is one click from inside a session.

What might the API look like?

A few non-exclusive options:

• Slash command: /handoff <session-title-or-id> "message" — sends message into the target session to execute. A could run /handoff B "use news-script.md to produce the video".

• Tool exposed to agents: a notify_session / trigger_session tool so the agent itself can fan out to or queue work in another session. E.g.

  {
    "target": "video-producer",
    "message": "Start producing the video from news-script.md."
  }

• First-class "handoff" primitive: a session can hand off to another by title/alias instead of ID, since IDs aren't user-visible in the session list.

• The receiving session should accept the message as if the user typed it (including ACLs like the TUI), rather than only via the external prompt_async API which a session can't call from inside its own agent loop.

Why is the Server API not enough?

It is enough for external orchestration scripts, but not for "in-session automation":

• A session has no first-class way to call into another session — it'd have to shell out curl/Invoke-RestMethod to its own server, know the target ID, and handle auth.
• The target session ID is not part of the user's vocabulary (they see titles/filenames, not GUIDs in the session list).
• Desktop users don't necessarily want to run a separate opencode serve or think about ports.

This issue is a feature request to make inter-session handoff a first-class action in the TUI/Desktop, with or without the HTTP plumbing underneath.

Environment

• OpenCode Desktop v1.17.20 on Windows
• Multiple sessions split across tabs, each session a distinct agent context