Monitor (Claude Code) repeatedly disappears mid-session ("task list empty") — auto-delivery stops, manual inbox still works

[fujibee]

Report

Reported by a community user (@gorosann1234) on X: https://x.com/gorosann1234/status/2068256436325634166

A Claude Code agent frequently reports that the monitor "died" / "there was no notification from the monitor," especially during long or "bad" stretches. In healthy stretches, multiple Claude sessions message each other fine; in bad stretches the monitor drops often, incoming messages stop being auto-delivered, and the agent falls back to manual checks — which the user finds unreliable.

Concrete signature (from a shared screenshot, transcribed — image not attached)

The agent repeatedly finds its persistent agmsg inbox stream Monitor task gone from the TaskList (it observes "the task list is empty"), relaunches it, and notes that a manual /agmsg inbox pull still catches every message — so messages are not lost, but the push channel (the Monitor task) keeps terminating. The agent eventually gives up on Monitor and switches to pulling the inbox manually each turn ("Monitor is "nice to have", I'll restart it but rely on manual pulls").

So the failure mode is the Monitor task ending mid-session, not (necessarily) message loss.

Candidate causes

• The harness auto-stops high-volume monitors ("monitors that produce too many events are automatically stopped"). If watch.sh is chatty or re-emits, the task gets killed — prime suspect for "frequent in bad mode."
• watch.sh self-exit when the owning session looks not-alive (watch.sh: self-exit when owning CC session is no longer alive #67, open).
• A duplicate / orphan watcher for the same session_id racing or starving the live one (watch.sh: multi-Monitor-invocation leaks duplicate watchers under same session_id #66; watch.sh: orphaned watcher advances shared watermark after its Monitor consumer dies → messages silently dropped from stream #127 → fixed by fix: Stop orphaned watch.sh from advancing the shared watermark past undelivered messages #145).
• A SessionStart re-fire (/clear, resume) running the dedup TaskStop and not relaunching cleanly.
• Stale subscription after a team/agent rename (Running watch.sh stays on old subscription after team/agent rename — silent message drops #72).

Reproduced internally (2026-06-20)

A leader session's monitor went silent for several messages. Root cause was a duplicate orphan watcher for the same session_id advancing the shared watermark (#127 / #66) plus a stale post-rename subscription (#72). Killing the orphan + relaunching the Monitor recovered. So "monitor down" is often a starved / superseded watcher, not a crash — which matches the report (messages still pullable manually).

Next steps

• Verify fix: Stop orphaned watch.sh from advancing the shared watermark past undelivered messages #145 (orphan-watermark fix, merged) reduces frequency in the field.
• Harden the watcher lifecycle: lean watch.sh output, one watcher per session_id (kill duplicates at launch), and have superseded watchers exit cleanly rather than starving the live one (watch.sh: multi-Monitor-invocation leaks duplicate watchers under same session_id #66 / watch.sh: self-exit when owning CC session is no longer alive #67 / watch.sh: orphaned watcher advances shared watermark after its Monitor consumer dies → messages silently dropped from stream #127).
• Give the agent a reliable "watcher alive & armed?" self-check (the Claude-Code equivalent of delivery.sh status reports 'watch processes: 0 alive' for Codex even when the bridge is alive — causes false 'monitor dead' misdiagnosis #157), and make the turn / both fallback actually fire when the monitor degrades, so the user doesn't depend on the agent remembering to pull manually.

Need from the reporter

agmsg version, delivery mode (monitor / both), Claude Code CLI vs Desktop app, and whether it correlates with /clear, multiple concurrent sessions, or actas / rename.

[fujibee]

Update — environment + a Windows hypothesis

Environment (from the thread): the reporter is using the Claude Desktop app (they explicitly asked whether it's a Claude Desktop bug). OS is being confirmed — if it is native Windows, that is a strong lead (see below). Delivery mode and agmsg version still TBD.

Windows hypothesis (high priority if confirmed): watch.sh decides whether its owning session is still alive via a kill -0 <pid>-style liveness check (agmsg_instance_alive in scripts/lib/instance-id.sh). We confirmed in #134 that kill -0 does not report liveness for native Windows PIDs under Git Bash — actas_lock_sid_alive() always returns false there. The same broken primitive feeds the watcher's self-exit path (#67): if the watcher believes its owning session is dead (because the Windows liveness check always fails), it can self-terminate, which would present exactly as "the Monitor task disappeared / the monitor keeps dying." That matches the report (frequent drops, but messages still pullable manually).

If the reporter is on Windows, this likely ties #169 → #67 → #134 (Windows liveness) into one root cause for the Claude-Code/Desktop side, mirroring the Codex-side actas-lock breakage.

Revised asks for the reporter: OS (Windows / macOS / Linux), agmsg version, delivery mode (monitor / both). (Claude Desktop is already known.)

[fujibee]

Windows CONFIRMED — root cause is the kill -0 liveness primitive (ties to #134)

The reporter confirmed native Windows (Claude Desktop). Tracing the watcher lifecycle, the kill -0-based liveness primitive is used pervasively and is broken on native Windows (Git Bash) — the same breakage confirmed in #134 (actas_lock_sid_alive() always false). It feeds multiple Claude-Code Monitor lifecycle decisions:

• agmsg_instance_alive() (scripts/lib/instance-id.sh) — liveness is only kill -0 <pid> → on native Windows it always returns false.
• session-start.sh orphan/stale cleanup — every pass keys off kill -0:
  • the "live cc-instance" pass treats all sessions as dead,
  • the stale-watcher-pidfile pass reaps a live watcher's pidfile (kill -0 "$pid" || rm -f "$f") because the live pid reads as dead.
• watch.sh dedup (kill -0 "$prev_pid") misfires for the same reason.

So on native Windows the watcher lifecycle management can't tell a live watcher from a dead one: pidfiles get reaped, dedup misjudges, and a re-fire (/clear, resume, another SessionStart) compounds it — which presents exactly as the reported symptom (the Monitor task "keeps dying," yet messages are still pullable manually because the data path is fine).

This unifies #169 ← #67 / #134 / #125: the Windows-compatible liveness fix (the kill -0 → tasklist/ps -W branch discussed in #134) is the single lever that fixes the user-facing Monitor instability on Windows. #125 (Windows CI, in progress) is the verification path. Recommend treating the Windows liveness fix as higher priority than originally scoped — it's not just an edge actas-lock race, it's a real user-facing "monitor keeps dying" bug on Claude Desktop + Windows.