Investigate messaging between agent sessions across harnesses #66

New issue

Open

opened 2026-10-11 16:52:26 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-10-11 16:52:26 +01:00

Contributor

Primary goals:

Name the coordination problem — what two sessions on one machine need to tell each other (what each holds, what each has committed, what to leave alone), and what goes wrong today when they cannot.
Record the one working example — how Claude Code sessions do it, what it depends on, and where it stops.
Map the other harnesses — what pi and codex sessions have today for discovering a peer and reaching it, which is nothing beyond files and the forge.
State the requirements a channel would have to meet — without picking a design.

Current state and specifics

A Claude Code session can list the other Claude Code sessions on the same machine (ListAgents: a name, whether it is busy, when it started) and send one a plain-text message (SendMessage); the text lands in the other session's conversation at its next tool round, wrapped so the receiving model knows it came from a peer and not from its user, and a reply comes back the same way. Delivery depends on both sessions running in a permission mode that lets peer messages through; a stricter mode holds them for the user to approve. The message is text, not an instruction: the receiving session reads it and decides, and the harness tells it to verify any claim before acting on it.

The example that prompted this: two sessions started on the same tracking issue a minute apart. The second found the first's worktrees and a commit already on one, listed the peer, and sent it a proposed split of the four child issues; the first agreed and the split held. Later the first noticed the second had overwritten a symlink that a memory file hands the owner as a relay path, said so, and it was fixed within a minute. None of that is possible when either session is pi or codex: neither has an inbox the other harness knows about, so the only shared surfaces are files on disk, worktrees, and forge comments, which a session reads only when it thinks to.

What the investigation should settle: which of those surfaces already carry enough of the signal (a worktree's existence, an in-flight note, an issue comment) and where they fall short; what a message is for that a file is not; whether discovery (who else is here) and delivery (telling them) are the same problem; and what the trust model is, since a peer's message is untrusted text in every harness.

Scope

In: the finding, written as a document in this repository's brainstorm tree. Out: building anything; changing how Claude Code's channel works, which is the harness's; the private deployment's model roster.

Two agent sessions working the same arc on one machine can coordinate only when both are Claude Code sessions; this investigates what the problem looks like across harnesses so a later change can decide whether and how to close the gap. Exploratory: the deliverable is a written finding, not code. Primary goals: - **Name the coordination problem** — what two sessions on one machine need to tell each other (what each holds, what each has committed, what to leave alone), and what goes wrong today when they cannot. - **Record the one working example** — how Claude Code sessions do it, what it depends on, and where it stops. - **Map the other harnesses** — what pi and codex sessions have today for discovering a peer and reaching it, which is nothing beyond files and the forge. - **State the requirements a channel would have to meet** — without picking a design. ### Current state and specifics A Claude Code session can list the other Claude Code sessions on the same machine (`ListAgents`: a name, whether it is busy, when it started) and send one a plain-text message (`SendMessage`); the text lands in the other session's conversation at its next tool round, wrapped so the receiving model knows it came from a peer and not from its user, and a reply comes back the same way. Delivery depends on both sessions running in a permission mode that lets peer messages through; a stricter mode holds them for the user to approve. The message is text, not an instruction: the receiving session reads it and decides, and the harness tells it to verify any claim before acting on it. The example that prompted this: two sessions started on the same tracking issue a minute apart. The second found the first's worktrees and a commit already on one, listed the peer, and sent it a proposed split of the four child issues; the first agreed and the split held. Later the first noticed the second had overwritten a symlink that a memory file hands the owner as a relay path, said so, and it was fixed within a minute. None of that is possible when either session is pi or codex: neither has an inbox the other harness knows about, so the only shared surfaces are files on disk, worktrees, and forge comments, which a session reads only when it thinks to. What the investigation should settle: which of those surfaces already carry enough of the signal (a worktree's existence, an in-flight note, an issue comment) and where they fall short; what a message is for that a file is not; whether discovery (who else is here) and delivery (telling them) are the same problem; and what the trust model is, since a peer's message is untrusted text in every harness. ### Scope In: the finding, written as a document in this repository's brainstorm tree. Out: building anything; changing how Claude Code's channel works, which is the harness's; the private deployment's model roster.