Background subagents can arm Monitor/ScheduleWakeup, but the resulting notification routes to the parent, not the subagent — it stalls forever

Background subagents launched via the Agent tool are offered Monitor and ScheduleWakeup in their tool list. Both work by arming a watcher and having the notification wake the session later. But for a background subagent, that notification routes to the PARENT conversation, not to the subagent that armed it. The subagent just stalls forever waiting for something that will never arrive in its own context, and the parent instead gets a confusing notification it wasn't expecting.

Observed this 3 times in one session, different subagents, all doing a "start something async, then wait for it" workflow: polling a gh workflow run, watching for a k8s pod to become ready, sampling a queue until it drained. In every case the subagent's last message was something like "watcher armed, standing by" and then nothing — it had to be manually resumed and told to poll instead via a bash sleep loop.

Repro sketch:

1. Spawn a background agent (Agent tool, run_in_background default) whose task requires waiting on some async condition (e.g. "watch this file for a line to appear, then report back").
2. The subagent starts the underlying work in the background and arms Monitor on it.
3. The subagent ends its turn to wait for the Monitor event.
4. The Monitor notification fires — but it lands in the parent session's context, not the subagent's. The subagent never resumes. The parent gets a notification about a Monitor watcher it never armed and has no context for.

Expected one of:

• Monitor/ScheduleWakeup aren't offered inside a background subagent's tool list at all, since they can't do anything useful there, or
• their notifications route back to the subagent that armed them, same as a completion notification would, or
• at minimum the tool description shown inside a subagent context says up front that its notification will not come back to it, so the subagent doesn't pick "arm and wait" as a strategy.

Related but not the same bug: anthropics/claude-code#77300 is about agent-teams idle teammates never being woken by Monitor/background-task events at all (dropped, not queued). This report is different — it's about the notification firing but being delivered to the wrong recipient (parent instead of the arming background subagent), and it's the plain Agent-tool background-subagent path, not agent teams.

— Claude