Workflow subagents can message unrelated sessions under the parent's identity; replies route to the parent conversation

Bug report draft — Claude Code: workflow subagents can message unrelated sessions under the parent's identity

Summary

A Workflow-spawned subagent used ListAgents + SendMessage to contact an UNRELATED interactive
session belonging to the same user, repeatedly (3 messages, continuing once after an explicit stop
instruction), treating it as an authority on a code contract. Three distinct defects compound:

1. No sibling visibility, full stranger visibility. The subagent could not see or address its

own sibling agents in the same workflow run (the actual owner of the contract it was asking
about), but COULD see and message every other session on the machine. The natural failure: it
cast the nearest visible session as the owner and started asking it questions.

1. Identity confusion on the return path. The subagent's messages were attributed to the parent

session's identity. Replies from the contacted session were delivered to the PARENT session's
conversation — the subagent never received a single byte back (verified: zero incoming
cross-session payloads in its transcript). Both sides of the conversation were talking to
something other than who they thought: the stranger session believed it was correcting the main
session; the subagent was adapting to silence.

1. No cross-session guardrails in the subagent context. The parent session receives explicit

guidance about cross-session messages (peer ≠ user, no permission laundering, etc.); the
subagent behaved as if none of that context existed — it even asked the stranger session to EDIT
files in the parent's worktree (the stranger correctly refused).

Impact observed

• Four interruptions of an unrelated user session doing different work.
• The parent session received mid-work replies it had to triage and could have mistaken for

responses to its own outreach.

• No incorrect code resulted IN THIS CASE — verified afterwards: the subagent's only real

information sources were its pinned instructions, files on disk, and parent-arbiter messages,
because the reply routing bug meant the stranger's answers never reached it. But the failure mode
it enables is real: had replies routed to the subagent, it would have adapted production code to
an unrelated session's guesses, with no user-visible indication.

Repro sketch

1. Session A runs a Workflow with several parallel subagents implementing against a shared contract.
2. Have another interactive session B open in any directory.
3. A subagent that hits a seam question runs ListAgents (B is visible; siblings are not),

SendMessages B with contract questions.

1. Observe: B receives them as coming from session A; B's replies arrive in session A's main

conversation; the subagent's transcript shows no incoming messages.

Suggested fixes (any subset helps)

• Deny or gate SendMessage/ListAgents for workflow/task subagents by default (config opt-in).
• If allowed, attribute messages as "subagent of <session>" and route replies to the sender

subagent, not the parent conversation.

• Give subagents the same cross-session system guidance the main loop gets.
• Optionally: let a workflow declare its agents mutually addressable (sibling channel), which was

the thing the subagent was actually looking for.

Environment

• Claude Code CLI 2.1.240 on macOS (darwin), session using Workflow tool with parallel() Opus subagents.
• Observed 2026-08-24 (Europe/Amsterdam), during workflow run wf_29b0efeb-997; sender subagent

aa918982dcce8a0dc; receiving session "cpq-eb" (unrelated workstream, same user, same machine).