Monitor tool: background poll loop silently stops emitting output/heartbeats mid-run, with no error or completion notification

Summary

The Monitor tool (background command watcher, one stdout line = one notification) can silently stop delivering output partway through a run, with no error, no timeout notification, and no final completion signal — even though the underlying polled state has changed and a manual re-check outside the monitor confirms the correct result immediately.

Reproduction context

Used Monitor to run a bash polling loop against a local HTTP API (a self-hosted task daemon on 127.0.0.1), checking curl'd JSON status for a handful of task IDs every 25s, printing a heartbeat line every 4th poll (~100s) and a transition line the moment any task's status flipped to complete/failed.

• Curl calls used --max-time 8 --retry 2 --retry-delay 1 (no unbounded blocking calls).
• Loop iteration count was bounded well under the timeout_ms budget so it should self-terminate with a final "done" line before any forced kill.
• Reproduced the query used inside the loop outside the monitor at the point it appeared stuck — it returned the correct, current status immediately (complete).

Observed: heartbeats printed correctly for ~13 consecutive cycles (~22 minutes), then output stopped entirely — no further heartbeats, no transition lines when the tracked tasks completed shortly after, no final summary line — for the remainder of the run (several more minutes observed before the monitor was manually stopped).

Calling TaskStop on the stalled monitor returned a normal "successfully stopped" result (not "already exited" / not-found), indicating the harness still considered the background task alive and running at the time output had already gone silent for an extended period.

Impact

From the caller's side, a stalled monitor is indistinguishable from "quietly still waiting, nothing to report yet." This makes Monitor unsafe to treat as a reliable completion signal for anything decision-relevant — the only mitigation currently available is to never trust monitor output/silence and always independently re-verify state via a direct manual query before acting on "no news yet."

What I ruled out

• Not a bug in the polled script itself — the exact same query reproduced correctly and instantly when run standalone outside the monitor.
• Not an unbounded/blocking call in the loop (curl was time-bounded and retried).
• Not the loop's own iteration cap silently exiting early (heartbeat counter and iteration cap were consistent with the loop still expecting to run further).

What would help

• Some way to confirm from the caller's side whether a Monitor-backed process is still alive and actually producing/consuming stdout, versus stalled with output capture broken — today a stalled monitor and a genuinely-idle one look identical.
• Emitting a synthetic notification (or making TaskStop/task-status introspection reveal it) when a monitor's own stdout stream appears to have stopped advancing for an anomalously long stretch relative to its own historical cadence.

Happy to provide more detail/logs if useful — this was observed inside a Claude Code CLI session on Linux.