One long coding-agent run can contain several workers. If a monitor treats every finished worker as the user's foreground turn, it will produce a stream of believable but wrong alerts.
This failure is easy to create. A parent session asks a background agent to review code. The worker finishes while the parent continues. Both records can contain completion-shaped events. A parser that only looks for the latest end_turn reports that the user is needed even though the main session is still running.
Agent Island handles Claude Code and Codex records locally. Filtering background work became part of state detection, not a cosmetic notification setting, because the monitor cannot assign meaning to completion until it knows who completed.
Claude can interleave sidechain records
Some Claude Code transcript layouts keep background traffic in separate subagents files. Older layouts can also interleave sidechain records into the main transcript.
The main-turn parser skips records marked isSidechain. Consider this order:
{"type":"user","uuid":"u1"}
{"type":"assistant","uuid":"a1","message":{"stop_reason":"tool_use"}}
{"type":"assistant","uuid":"side1","isSidechain":true,
"message":{"stop_reason":"end_turn"}}The background worker ended, but the main assistant's last relevant record still says tool_use. The foreground turn remains active.
The inverse case matters too. A main assistant may finish and then receive a trailing sidechain record. Skipping sidechain traffic must preserve the main completion rather than letting the later file line hide it. Tests pin both orders.
Separate agent transcripts are classified by path shape as well as record content. Current layouts use a subagents directory; older flat layouts can use names such as agent-*.jsonl. The scanner omits these records from normal monitoring unless the user explicitly enables subagent alerts.
Opt-in monitoring needs a different return path. A subagent does not own a resumable top-level session. Its alert points back to the parent session ID, which is read from the agent record or inferred from the directory layout. That lets a user return to the conversation that launched the work.
Codex identifies the origin in session metadata
Codex rollout metadata carries a source field. Direct interactive sessions may use values such as cli. Automation can use exec or mcp. Spawned workers can carry a structured subagent source.
The scanner classifies each rollout before state parsing:
interactive -> eligible for normal status and your-turn alerts
subagent -> ignored unless subagent alerts are enabled
automation -> never treated as the user's turnThe originator is a second guard. A Codex-family originator can represent the user's own session. A foreign orchestrator or codex_exec is automation even when another field resembles a subagent. That precedence prevents a host application from creating user-facing alerts for its internal probes.
Backward compatibility needs an explicit policy. Older Codex records may omit source; the scanner treats those as interactive when the originator does not contradict that assumption. Dropping all old records would avoid false positives by making the monitor blind, which is not a useful trade.
Classification belongs before aggregation
The activity monitor eventually reduces many sessions to one visible state per provider. Background filtering has to happen before that reduction. Once a worker's completion has been merged into a provider-level needsYou state, the identity needed to undo the mistake is gone.
The monitoring scan therefore keeps recent sessions separate, classifies their origin, computes each turn state, and only then chooses the provider state and active thread. File events can trigger a fast rescan, while a periodic scan covers missed watcher events.
This design also keeps the notification rule understandable. Normal alerts answer one question: does the user's own interactive session need attention? Subagent alerts are a separate opt-in behavior with their own label and parent-session destination.
The test cases are the contract
The Windows test suite includes cases for interleaved Claude sidechain completion, trailing sidechain traffic after a main completion, agent transcript endings, plain tool results that must remain running, Codex CLI sessions, missing legacy sources, structured subagents, internal work, exec runs, and foreign originators.
Those examples are more useful than testing a single happy-path file. They describe the boundary between a user turn and machine fan-out. When upstream record formats move, the tests show which behavior must survive the parser change.
The public v1.6.1 release contains macOS and Windows builds. That confirms the released product baseline used for this discussion. Platform artifacts do not prove every runtime path behaves identically, so the article does not claim full behavioral parity from release metadata alone.
A completion marker has no user-facing meaning until it is attached to the right actor. Foreground session, background worker, and automation run are different sources even when their last lines look alike. Classify the source first, then decide whether anyone should be interrupted.