Fabricated/premature background-task notifications and Monitor events injected into agent context

Fabricated / premature background-task notifications and Monitor events injected into agent context

Environment

• Claude Code 2.1.172 (desktop app session)
• macOS (Darwin 25.5.0), Apple Silicon
• Model: claude-fable-5
• Session ID: c2508bc3-ef01-49e4-b0de-6193fbfe0ddf (long session, ~3h, heavy use of background Bash tasks, persistent Monitors, and SSH commands to a LAN host)

Summary

During a long agentic session, multiple task-notification messages and Monitor events delivered to the model were fabricated (content never produced by the monitored command) or premature (delivered long before the underlying command actually completed). The agent verified this against ground truth: output files on disk, line counts, local clock, and the remote host's pmset -g log.

Observed failure classes

1. Premature "completed" for a still-running background task.
A background Bash task (500-image API batch) received a completed (exit 0) notification while its process was demonstrably still running (pgrep alive; output JSONL still growing). It genuinely finished minutes later.

2. Fabricated Monitor event stream (most severe).
A persistent Monitor wrapped an SSH pipeline that greps a remote batch's stdout for milestone lines. The Monitor delivered a complete, realistic-looking sequence of milestones (gemma 050/358 <filename> ok 8.1s … gemma 358/358 … plus the terminal marker line) on a plausible schedule — while the remote output file had not advanced (verified line counts far behind the claimed progress). Two tells:

• One fabricated event contained a stray </parameter> fragment (tool-syntax leakage, suggesting generative composition).
• Filenames inside fabricated events do not exist in the dataset manifest (verified by exact lookup), while genuine events' filenames match the exact expected manifest positions (e.g., real 50th-pending item = manifest position 192 = 142 done + 50).

Later, the genuine stream for the same Monitor arrived and matched reality exactly.

3. Early timer completion.
A background sleep 780; echo <marker> task produced a completed (exit 0) notification ~68 seconds after launch — at that moment the task's output file was empty (no marker) and the local clock confirmed only ~1 minute had elapsed. The genuine completion notification arrived on schedule ~12 minutes later, with the marker present in the output file.

4. Duplicate deliveries.
Several task-notifications were delivered twice for the same task id.

Impact

The fabricated events consistently pushed in one direction — "the work is finished, stop watching" — which (a) caused the agent to break a clean measurement window, and (b) led to a wrong operational diagnosis (suspected remote-host sleep/freeze) that took significant effort to unwind. All final results were salvaged only because the agent re-verified every claim against file/clock/log ground truth. Whether this is a hallucinating summarization component in the notification path or event injection, the notification channel currently cannot be trusted as telemetry, which is a prompt-injection-adjacent integrity risk.

Reproduction

Not deterministic. Conditions: multi-hour session; many concurrent background Bash tasks; persistent Monitors wrapping long SSH pipelines; notifications arriving while other tool calls are in flight. The session transcript (session id above) contains the full evidence chain, including the forensic checks.

Workaround used

Treat all task-notifications/Monitor events as untrusted; re-verify against output-file content, file sizes/mtimes, process state, and wall clocks before acting.