feat(opencode): coordinator-messaging — sibling/coordinator subagent communication - #32517
feat(opencode): coordinator-messaging — sibling/coordinator subagent communication#32517iceteaSA wants to merge 32 commits into
Conversation
Sorry, something went wrong.
|
The following comment was made by an LLM, it may be inaccurate: The search results show that PR #32517 (the current PR) appears in all results, but the relevant related PRs are:
The current PR explicitly declares its dependencies on #32192 and #32425 (subagent-interrupt) in its description, and references #19215 (agent-team coordination) as the related issue. These are intentional stack dependencies, not duplicates. No duplicate PRs found |
Sorry, something went wrong.
…g, delivery errors)
The sender-echo markers duplicated information already shown by the message tool call itself (✉ Sent to parent / ✉ Replied to subagent sat right under the visible tool call), and the subagent's "Reply from parent" marker was written twice — once by the parent's reply branch and again by the subagent's own send path. Keep only the incoming markers: the parent sees "✉ Message from subagent", the recipient subagent sees "✉ Reply from parent", each once. Drop the now-unused marker direction field.
Experimental capability for a parent agent or human operator to steer, gracefully cancel, or hard-abort a specific running Task subagent mid-run, without affecting the parent or sibling subagents. Core: - Interrupt service (session/interrupt.ts): process-local registry holding one pending interrupt per child plus a terminal record; steer/cancel frame renderers and a visible-marker renderer, both with origin attribution (user vs parent); reason length-capped and XML-escaped at every sink (frames AND the visible marker). - The child consumes pending interrupts at the runLoop turn boundary: steer injects a <steer> frame and a visible "Steered by ..." marker and continues; cancel injects <cancel> + a visible marker, records a terminal, and force-breaks within a grace window. abortChild writes a visible "Aborted by ..." marker (model/agent derived from the child's latest user message), records a terminal, and cancels the BackgroundJob. Agent tools (gated by permission.interrupt): - task_steer / task_cancel / task_abort (origin=parent). Human paths: - POST /session/:id/interrupt (intent steer|cancel|abort, origin=user), restricted to subagent sessions, gated by the experimental flag, and rejecting non-running children. - TUI: esc on a subagent opens a Steer/Cancel/Abort menu, then a reason prompt; markers render as "... by user". Bound at the session route via a uniquely-named gather bucket (the keymap gather() caches by name). Visible interrupt markers render as a distinct "Interrupt" line (tagged via part.metadata.interrupt), not as user prose. Whole feature gated by OPENCODE_EXPERIMENTAL_SUBAGENT_INTERRUPT (off by default): agent tools, HTTP endpoint, and TUI affordance. Limitations: agent-driven steer/cancel applies to background children only (a foreground child blocks the parent turn); cancel is boundary-soft (use task_abort / Abort for a child stuck in a long tool call).
- interrupt.ts: remove defaultLayer (deleted at dev), fix node to object form - interrupt.test.ts: migrate from EventV2Bridge.defaultLayer to LayerNode.compile - task-interrupt.test.ts: migrate from Layer.mergeAll(defaultLayer) to LayerNode group/compile - task.test.ts: add Interrupt.node to test group (registry gained the dep)
…r before adding inbox markers
…dation, fire-and-forget only
…ow + gating verification
|
Automated PR Cleanup Thank you for contributing to opencode. Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions. This PR was closed because it matched the following cleanup criteria:
PRs created within the last month are not affected by this cleanup. If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate. Thanks again for taking the time to contribute. |
Sorry, something went wrong.
|
Still active — requesting reopen. Rebased onto dev@5e2a625 today, conflict-free. The stack gates clean at its tip: 3322 tests, 0 failures, typecheck clean. This sits mid-stack: #32192 → #32425 → this → #32693 → #35400. #32425 and #35400 are still open, so closing the middle links leaves open PRs stranded on closed bases. Kept current with dev on a roughly weekly cadence since it was opened. |
Sorry, something went wrong.
Issue for this PR
Related to #19215 (agent-team coordination) — this adds the sibling/coordinator layer that proposal needs.
Stacked on #32192 (agent-messaging) and #32425 (subagent-interrupt) — it builds directly on both. Until those merge, this PR's diff includes their commits (23 commits / +4492 vs dev); the net-new surface here is the last 9 commits (~+1189), from refactor(tui,session): extract one shared Marker.render through docs(messaging,message). Please review after the two base PRs land. Draft until then.
Type of change
What does this PR do?
Lets the sibling subagents one parent spawns message each other directly, instead of routing every message back through the parent. Same experimental flag as #32192 (OPENCODE_EXPERIMENTAL_AGENT_MESSAGING); off by default.
The surface is one composable primitive — a per-child allow-list — so the parent builds whatever communication graph it wants (hub/coordinator, mesh, chain) with no special-casing:
Why it can't deadlock: every peer send is fire-and-forget (returns at once) and every drain is non-blocking at a turn boundary, so no agent ever waits on a specific inbound message — no wait-cycle can form, even in a mesh with simultaneous A↔B sends. With the flag off the message tool is unregistered and the drain block is dead code.
How did you verify your code works?
New tests (no mocks): the slug registry + allow-list, the FIFO inbox with budget/cap/dedup, bounded awaitInbox, peer-send authorization (allow-list + parentID sibling check + expect_reply rejection), the runLoop drain (batched 2N-part injection, skip-on-cancel, flag-off no-op), and an end-to-end collaborative-sibling flow + gating.
Live-tested end-to-end on a real build across every topology the allow-list expresses, plus the refusal paths and cross-feature interaction:
Screenshots / recordings
UI surface is small and reuses #32192's marker render path: inbox deliveries show a muted ✉ Inbox from <sender-slug> row in the recipient's transcript (same mechanism/styling as #32192's ✉ Message from subagent). No new components. Screenshot to be added before marking ready.
Checklist