Feature hasn't been suggested before.
Describe the enhancement you want to request
Two opencode sessions open in different windows on the same machine cannot talk to each other. Coordinating them means the human copying text between windows.
This comes up whenever work spans two contexts that each deserve their own session — one on the source repo and one on config, or one driving a long build while another investigates something related. Today the only channel is the person sitting between them.
The existing subagent messaging primitives do not apply: there is no parent/child relationship between two top-level sessions, so there is nothing to authorize against and no dispatch to carry a handle.
Suggested behaviour
An explicit mutual-consent handshake — one side mints a short-lived token, the other consumes it — establishing a durable bidirectional allow between two session ids. After that, either side can send.
Design points that seem load-bearing:
- Address by session id, not slug. Session slugs carry no uniqueness guarantee.
- Consent must be durable and revocable by either side, and survive a restart.
- An idle peer still has to receive. A session not currently taking a turn needs waking, which means something polling outside the run loop — and that something needs the per-session context, which is not available at layer-build time.
- Peer content is untrusted. It should render as clearly-marked external context, escaped at the sink, and never be treated as instruction.
- Bounded: rate limit, inbox cap, dedup.
Version
v1.18.5
Additional context
PR #38944 implements this behind an experimental flag. It builds on the subagent messaging primitives in #38963/#38964 but is a distinct topology — no parent/child, hence the consent handshake.
Feature hasn't been suggested before.
Describe the enhancement you want to request
Two opencode sessions open in different windows on the same machine cannot talk to each other. Coordinating them means the human copying text between windows.
This comes up whenever work spans two contexts that each deserve their own session — one on the source repo and one on config, or one driving a long build while another investigates something related. Today the only channel is the person sitting between them.
The existing subagent messaging primitives do not apply: there is no parent/child relationship between two top-level sessions, so there is nothing to authorize against and no dispatch to carry a handle.
Suggested behaviour
An explicit mutual-consent handshake — one side mints a short-lived token, the other consumes it — establishing a durable bidirectional allow between two session ids. After that, either side can send.
Design points that seem load-bearing:
Version
v1.18.5
Additional context
PR #38944 implements this behind an experimental flag. It builds on the subagent messaging primitives in #38963/#38964 but is a distinct topology — no parent/child, hence the consent handshake.