A subagent's tool calls do reach the parent session's hooks: measured, a
PostToolUse arrives carrying agent_id and agent_type. Only Stop was
guarded against that, and Stop was the case that mattered least.
With background subagents the ordering is the harmful one. The main agent
ends its turn first, so Stop lands and the session reads "waiting"; the
subagents keep working, and their PostToolUse arrives afterwards and puts
the session back to "busy". The panel then says a session is working when
its input line is free and it is waiting for you -- the precise confusion
this indicator exists to prevent, and reported from a live session doing
exactly that.
Every event carrying agent_id is now ignored. Synchronous subagents lose
nothing: the main agent is mid-turn, so its own earlier events already say
"busy".
Notification is deliberately exempt. It means a human is needed, and that
is as true when the agent that got stuck is a subagent -- ignoring it
would leave a session silently blocked.
Covered both ways in the hook tests, and checked once against a real
subagent event captured from a live run rather than a hand-written one.
av
09b9aae2eb