Recorded in the README's "Differences from Claude Code". Filing as a scope decision rather than a defect.
Current behaviour
Discovery reads ~/.cache/opencode/cross-session/agents/, and delivery targets http://127.0.0.1:<port>. Two sessions can reach each other only if they share a filesystem view of that directory and can reach each other's loopback address. In practice that means one machine.
This matches Claude Code's same-machine path, including the consequence that a containerised session and a host session cannot see each other. What is missing is Claude Code's other two routes: sessions on another of your machines, and cloud sessions, both of which travel through Anthropic servers over a Remote Control connection.
Why this is not simply a missing feature
Claude Code's cross-machine delivery depends on infrastructure that has no opencode equivalent: an account-scoped relay, plus an identity model that knows which machines are "yours". Reproducing it means either running a relay or depending on a third-party one, which changes the plugin from "local IPC, nothing leaves the machine" into a networked service. That is a real change in the security story and should be an explicit decision, not a quiet addition.
Prior art
opencode-cross-session-messaging on npm (by kinminghao, unrelated to this repo, see #1) describes itself as "local file IPC or cross-device relay via HTTP polling". Whatever is decided here, their relay design is worth reading first.
Options
- Stay same-machine. Document it as the boundary and close this. The tunnel/VPN answer below covers most real use.
- Support an explicitly configured peer. Let a user point a session at another machine's opencode server URL, reachable over Tailscale, a VPN, or an SSH tunnel. No relay, no third party, and it composes with
opencode serve --hostname. Cheapest meaningful step.
- Build or adopt a relay. Closest to Claude Code, and by far the most work and the most responsibility.
Option 2 is the one worth doing if this is wanted; it stays honest about the trust model while covering "my laptop and my desktop".
Note
Option 2 interacts with #3: if delivery moves to a receiver-owned unix socket, a remote peer needs a different transport, so decide the ordering before implementing either.
Recorded in the README's "Differences from Claude Code". Filing as a scope decision rather than a defect.
Current behaviour
Discovery reads
~/.cache/opencode/cross-session/agents/, and delivery targetshttp://127.0.0.1:<port>. Two sessions can reach each other only if they share a filesystem view of that directory and can reach each other's loopback address. In practice that means one machine.This matches Claude Code's same-machine path, including the consequence that a containerised session and a host session cannot see each other. What is missing is Claude Code's other two routes: sessions on another of your machines, and cloud sessions, both of which travel through Anthropic servers over a Remote Control connection.
Why this is not simply a missing feature
Claude Code's cross-machine delivery depends on infrastructure that has no opencode equivalent: an account-scoped relay, plus an identity model that knows which machines are "yours". Reproducing it means either running a relay or depending on a third-party one, which changes the plugin from "local IPC, nothing leaves the machine" into a networked service. That is a real change in the security story and should be an explicit decision, not a quiet addition.
Prior art
opencode-cross-session-messagingon npm (bykinminghao, unrelated to this repo, see #1) describes itself as "local file IPC or cross-device relay via HTTP polling". Whatever is decided here, their relay design is worth reading first.Options
opencode serve --hostname. Cheapest meaningful step.Option 2 is the one worth doing if this is wanted; it stays honest about the trust model while covering "my laptop and my desktop".
Note
Option 2 interacts with #3: if delivery moves to a receiver-owned unix socket, a remote peer needs a different transport, so decide the ordering before implementing either.