anomalyco / anomalyco/opencode

[FEATURE]: Two running opencode sessions have no way to communicate

Open
#38,965 0 comments 0 reactions 1 assignee View on GitHub

@rekram1-node is already working on this.

Since Jul 26, 2026.

Dominant language
TypeScript
Stars
209k
Forks
27.5k
PR merge metrics
PR metrics pending

Description

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

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.