Persistent Monitor tasks killed with SIGURG (exit 144) ~60-75 min after arming; trap '' URG cannot prevent it

Summary

Persistent Monitor tasks (persistent: true) are killed with exit 144 (128+16 = SIGURG) typically 60–75 minutes after arming. Script-side signal handling cannot prevent it — deaths occur even with trap '' URG inside the monitored script, which indicates the signal terminates the harness-side task rather than the shell script.

Environment

• Claude Code 2.1.222 (also observed on 2.1.220)
• macOS 26.5.2 (Apple Silicon, two machines)
• Monitors are long-running tail -n 0 -F <file> | grep --line-buffered ... pipelines (log-tail event streams), armed with persistent: true

Observed

• 2026-07-29: five deaths across two trap configurations, including trap '' URG — all ~60–75 min after arm, all exit 144.
• 2026-08-03/04: two further deaths of the same monitor at ~61 min and ~58 min after arm (exit reported as "stream ended"; the session's task notification carries no stderr).
• Counter-example: an identical re-armed monitor subsequently survived 36+ hours — the kill is intermittent, and deaths cluster during periods of high system load (loadavg spikes from unrelated processes), suggesting a resource/health reaper rather than a fixed timeout.
• A separate long-running background Bash task (run_in_background sleep-loop timers) is also killed intermittently under the same load conditions — possibly the same mechanism.

Impact

Event-driven workflows silently lose their event stream: a dead monitor looks identical to "no events". We currently mitigate with re-arm-on-death plus a catch-up sweep of the tailed file, which works but costs a detection gap on every death.

Questions / ask

1. What sends SIGURG to persistent monitor tasks (~60–75 min under load)? Is there an internal health/reaper mechanism that treats a quiet tail -F as stalled?
2. If the kill is intentional, could persistent: true monitors auto-re-arm (with a "restarted" notification) instead of ending the stream silently?
3. If unintentional, treat this as a bug report: persistent: true + quiet event stream + host under load appears to be the repro triangle.