Running multiple coding agents in parallel is useful—until those agents need to coordinate.
One session may be reviewing a repository while another is implementing a change in a different terminal or worktree. Without a communication layer, the usual solution is manual: copy a conclusion from one window, paste it into another, and repeat whenever context changes.
opencode-plugin-peers brings Claude Code–style cross-session messaging to OpenCode. It is modeled after Claude Code's cross-session messaging workflow, allowing independent OpenCode sessions on the same machine to discover and send plain-text messages to one another.
The workflow it recreates
The goal is simple: treat each OpenCode session as an independent peer while still giving sessions a reliable way to coordinate.
With the plugin installed, sessions can:
- discover available peers with
list_agentsor/peers - send a message with
send_message - address root sessions and child sessions independently
- receive messages even while the target session is busy
- retain queues, delivery outcomes, and sender outboxes across restarts
- control inbound behavior with
accept,auto,hold, orrefuse
This makes multi-terminal, multi-repository, and multi-worktree workflows feel much closer to a coordinated group of coding agents instead of isolated windows.
Why cross-session messaging matters
Imagine three OpenCode sessions running at the same time:
- One session investigates a failing test.
- A second session updates the implementation in another worktree.
- A third session reviews documentation and compatibility concerns.
The investigation session can send its findings directly to the implementation session. If the implementation session is busy, the message is still delivered through the plugin's local messaging layer. Durable queues and outboxes help preserve delivery state across restarts, so coordination is not tied to a single uninterrupted process.
The important distinction is that the sessions remain independent. The plugin does not merge their conversation history or share hidden context. It provides a focused communication channel: plain-text messages between known local peers.
Local by design
opencode-plugin-peers keeps transport on the local machine:
- Unix-domain sockets on macOS and Linux
- loopback TCP on Windows
It does not provide remote messaging, file transfer, or shared conversation history. Those boundaries keep the plugin focused and make its behavior easier to reason about.
Installation
opencode plugin -g opencode-plugin-peers
The current npm release is 0.2.2 and requires:
- OpenCode 1.18.0 or later
- Node.js 18 or later
After installation, use /peers to inspect discoverable sessions, or let an OpenCode agent use list_agents and send_message as part of its workflow.
Inbound controls and security
Messages from peers should be treated as untrusted input. Processes running as the same operating-system user share the local trust boundary, so a message should not automatically be treated as a trusted instruction.
For sensitive projects, consider conservative settings such as:
peerPermissions: "ask"-
inboundPolicy: "hold"or"refuse"
These controls let you decide whether inbound messages are accepted automatically, held for review, or refused. The repository README documents the full behavior and security model.
Try it
- GitHub: jkrandom-sudo/opencode-plugin-peers
- npm: opencode-plugin-peers
Feedback is especially welcome for multi-worktree coordination, busy-session delivery, restart recovery, permission UX, and Windows behavior.
Disclosure: This article was prepared with AI assistance and reviewed before publication.
Top comments (0)