Monitor/background task notifications fabricate completion events with future timestamps while process still running

Summary

During one session, the Monitor / background-Bash task-notification layer delivered multiple fabricated completion notifications: summaries quoting log lines that did not exist, stamped with timestamps in the future relative to the machine's clock. The real completion arrived later and was accurate.

Environment

• Claude Code (desktop app session), macOS (Darwin 25.5.0)
• Model: claude-fable-5
• Date: 2026-07-19, ~19:40–19:50 local (EDT)
• Task IDs within the session: b01qtdc8w, bdkc1n3vy, b8f8nyaja (session id 089bce6d-882a-4fdb-916c-ebb1ef8a0968)

What happened

The model was watching a long-running remote job (a launchd-fired script on another Mac over SSH, expected runtime ~8–40 min, started 19:42:05) using:

1. A Monitor polling over SSH every 60–90 s for the job's terminal log line.
2. Later, a background Bash (run_in_background: true) until-loop on the same condition.

Observed failures, in order:

1. Monitor b01qtdc8w reported completed with summary quoting: === 2026-07-19T20:35:31-04:00 alfred-run done [council-beat] rc=0 === — at a real wall-clock time of 19:43. The quoted line did not exist in the watched log (verified over SSH seconds later; the remote machine's date also read 19:43). The timestamp is ~52 minutes in the future.
2. Monitor bdkc1n3vy (re-armed with a stricter count-based condition that provably could not yet be true) reported completed with summary: === 2026-07-19T20:14:38-04:00 ... rc=0 === — again at real time ~19:43, again a future timestamp, again absent from the actual log (line count condition >= 2 was still 1).
3. Background Bash b8f8nyaja (an until loop that only exits after echoing a REAL-DONE: line) reported completed (exit code 0) ~20 s after launch with a completely empty output file — the echo never ran, and the loop condition was still false at that moment.
4. At 19:50:00 the job genuinely finished; a foreground until-loop and the (apparently still-alive?) monitors then produced correct, clock-consistent events matching the log, so the eventual real signal was fine.

Note the oddity in (4): monitors b01qtdc8w/bdkc1n3vy emitted correct events at ~19:50 after having already been reported completed at ~19:43 — so the earlier "completed" notifications appear to have been synthesized while the underlying processes were still running.

Why this looks like the notification layer, not the scripts

• The fabricated lines were plausible extrapolations of the expected success line (correct format, correct rc, future timestamp) — exactly what a summarizer predicting a result would produce, and the monitor scripts themselves could not have printed them (their only output paths were verbatim grep output of existing log lines, or a fixed literal string).
• The empty-output background task could not have exited 0 without printing its REAL-DONE: line.

Impact

If the model trusts these notifications, it marks unfinished work as verified-done (in this session it would have closed an ops flag on a fabricated success). The system prompt itself warns the model that "the notification is never something you write yourself" — but here the channel itself delivered fabricated content, which the model can only catch by independently re-verifying ground truth.

Expected

Task notifications should only ever relay actual observed process output/exit, and a task should not be reported completed while its process is still running.

🤖 Generated with Claude Code