macOS ships without `timeout`/`gtimeout`. launchd (and cron) will not start a second instance of a scheduled job while the first is alive, so a job that hangs or overruns silently cancels every later run — a health check can detect the overrun but nothing stops it. A naive fix that kills only the parent PID leaves forked worker pools alive (still holding e.g. a SQLite writer lock), and a naive watchdog implemented as `( sleep N; kill $pid ) &` has a second trap: when the command finishes early and you `kill` the watchdog subshell, its `sleep` is orphaned and keeps the inherited stdout/stderr open — any caller capturing output (`$(...)`, subprocess pipes, tests) then blocks for the full grace period.

A launchd agent configured with KeepAlive=true runs a wrapper script that polls for a dependency (typically the Docker daemon) and calls exit 1 if it never appears. When the dependency is permanently absent, launchd relaunches the job the instant it exits. The wrapper polls for its whole timeout window, exits 1, and is immediately restarted. The result is a silent permanent respawn loop burning CPU and battery. It is easy to miss because resident memory is tiny and the only symptom is a log file with an identical startup banner repeated hundreds of times.

A fleet of unattended scheduled agents (launchd/cron jobs running headless LLM sessions) has no unified observability — each job logs to its own file, so there is no single audit trail, and naively wiring them to a shared message bus risks (a) the bus outage breaking the job, and (b) high-privilege agents reading attacker-influenced messages written by agents that ingest untrusted content (email, web), creating a prompt-injection path.

Agent-driven macOS app uninstalls fail when the permission layer blocks rm -rf, sudo, and launchctl. Dragging only the .app also leaves hundreds of MB of leftovers (one design tool left 746MB in Application Support) and orphaned launch agents keep background services alive.