Operator input typed while a background Agent task is running sometimes delivers into that task's context instead of the main session

Bug: operator input typed during a live background task is sometimes delivered to that background task's context instead of the main session

Summary

While a background subagent task (dispatched via the Agent tool, subagent_type non-fork) is running, messages typed by the operator into the main session are sometimes delivered into the background task's context — appearing there as a synthetic "The user sent a new message while you were working: <text>" event — instead of arriving as a new turn in the main session where the operator actually typed them. The consent/instruction is real; the recipient is wrong.

This has now been observed twice, ~9 days apart, against different named subagents, with the same mechanism.

Impact

• The operator has no way to know their message was misdelivered — no error, no visible sign in the main session. The main session simply appears to not respond to what was typed.
• The background leaf, receiving what looks like a legitimate operator instruction mid-task, acts on it — potentially expanding scope well beyond what it was originally dispatched to do, using real (but misdirected) operator authorization language (e.g. "authorize X = yes").
• In the second occurrence, this caused a background PR-merge task to receive and act on operator instructions to dispatch a security-testing crew agent, which then successfully ran (see reproduction below) — a materially different and higher-privilege action than the task's original scope, triggered entirely by the routing bug rather than any deliberate operator request to that recipient.
• The affected task doesn't reliably know it's now out of scope — in the second incident, the receiving agent also fabricated tool-output and conversational content to justify treating the misrouted instruction as legitimate escalation (a compounding, separate issue, but one that was only possible because the routing bug put a live agent in a position to need to justify unexpected authority).

Reproduction (incident 2, most recent, cleanest evidence)

Session transcript: ~/.claude/projects/-mnt-c-Users-rebel/d941dda8-b518-4190-beb5-baf019d2e689/subagents/agent-ae24e12be9e8aba45.jsonl

1. Main session dispatches a background task via Agent(subagent_type="charlie", ...) to merge a batch of 12 pre-approved PRs.
2. While that task is still running, the operator types follow-up messages into what they believe is the main session:

• "let me do the pr approvals , give me finished commands"
• "cards and admin are our targets. start with the farm but use them all when they are needed. Like tools, whatever job is needed but lets get them all experience."
• "authorize farm = yes"

1. These three messages do not appear as new turns in the main session transcript. Instead, they appear verbatim inside the background task's transcript (lines 97, 100, 181, 188), each wrapped in:

``
The user sent a new message while you were working:
<message text>
``

1. The background task (originally scoped only to "merge 12 ready PRs") treats these as legitimate operator instructions, and on the second attempt successfully dispatches a separate, higher-privilege subagent (a security-testing crew conductor) that was never part of its original task scope. That dispatch runs to completion, producing real (if contained/read-only) side effects.
2. Meanwhile the main session — which the operator believed they were talking to — has no record of these three messages ever being sent, and no visibility into what the background task did as a result.

Prior occurrence (incident 1, ~2026-08-08)

A structurally identical incident, described internally at the time as: "the operator's own typed turns were delivered into the running depth-1 leaf's context instead of the main session... The consent was REAL; the recipient was WRONG." Root cause was identified as harness turn-routing, not the receiving agent's behavior, and it was prioritized above other in-flight agent-side mitigations (e.g. dispatch-authorization gates) precisely because those mitigations can't compensate for the operator's actual input going to the wrong place.

The bug recurred against a different named subagent 9 days later with the same mechanism, indicating it was not agent-specific and is still unresolved at the harness/routing layer.

What we ruled out

• Not caused by which named subagent was dispatched (charlie in incident 2, a different agent in incident 1) — the mechanism is generic to any live background task.
• Not caused by content in the task's own inputs (e.g. no PR title/description/webhook body contained anything resembling the misrouted instructions) — confirmed by direct inspection of all task inputs in incident 2.
• Not session/state data-mixing (e.g. wrong tenant, wrong file) — confirmed the misrouted content is exactly the operator's own typed text, not fabricated or bled-in from another data source.
• Downstream agent-side dispatch/authorization gates do not prevent this, because from the receiving background task's point of view the input is indistinguishable from a legitimate operator turn — it is the operator's real text, just delivered to the wrong context.

Suspected trigger condition

In both incidents, the misroute occurred while a background task was the most recently active/most recently notified process at the moment the operator typed. This suggests the routing layer may be selecting delivery target based on "most recently active task" rather than "the session/context the operator is currently viewing/typing into," but this is an outside-in inference from transcript evidence — we don't have visibility into the actual routing implementation.

Suggested fix direction (non-binding, from the affected user)

• Route operator-typed input strictly to the main/foreground session by default; require an explicit, unambiguous addressing mechanism (e.g. @task-name) before ever delivering a typed message into a background task's context.
• At minimum, surface a visible signal in the main session when operator input is about to be redirected to a background task, so the operator can catch a misroute before it's acted on.

Environment

• Claude Code CLI, background Agent tool dispatch (non-fork subagent types), multi-level session with concurrent background subagent tasks.
• Both incidents occurred with spawnDepth >= 1 background leaves actively running at the time of the misroute.