Monitor tool: completion notification silently dropped (nondeterministic) when a polling until-loop Monitor finishes (Windows)

Summary

A Monitor tool task running a polling until loop transitioned to completed (its watched condition became true and the final echo ran), but no <task-notification> was delivered to the conversation. The model kept "standing by" until the user manually pointed out, minutes later, that the awaited file already existed. In the same session, an identically-shaped Monitor did deliver its notification — so the drop is nondeterministic.

This is the Monitor tool surface, distinct from #66311 (which reports the same symptom for run_in_background: true Bash tasks). Likely a shared root cause, but a different tool, so filing separately.

Environment

• Claude Code, Windows (Git Bash), Opus 4.x.
• Monitor tool, persistent: false, timeout_ms: 1800000.

Repro / observed

Monitor command — poll for a file, emit one line, exit:

F="…/R1-03-codex-review.md"; until [ -f "$F" ]; do sleep 5; done; echo "ready: appeared"

1. Monitor armed (task id returned, 30-min timeout).
2. The watched file was created ~26 min later — within the 30-min window.
3. Expected: a <task-notification> carrying ready: appeared.
4. Actual: no notification at all; the model continued as if the Monitor were still pending. The user noticed minutes later and reported it manually.
5. A second Monitor armed in the same session with the same shape (different file) did fire its notification correctly.

So: same pattern, same session — one Monitor delivered, the other silently dropped → nondeterministic notification loss.

Possible correlation (unconfirmed)

In the dropped case, a new user turn arrived between arming the Monitor and the condition firing. But the delivered case also had an intervening user turn, so "intervening turn" is not a conclusive cause. This leans toward the stdout-drain / quick-exit-after-sleep timing hypothesis from #66311.

Impact

Async orchestration via Monitor loses its signal silently. The model cannot tell the notification was dropped, so it waits indefinitely; the user must remember to probe. Same user-facing cost as #66311, but on the Monitor surface and on Windows.

Related

• #66311 — same symptom for run_in_background Bash polling loops (Linux). This issue is the Monitor tool surface (Windows). Possibly one root cause; tracking per tool surface.