Home / All Skills / Workflow & Core Tools / macos-watchdog
Workflow & Core Tools · daymade/claude-code-skills

macos-watchdog

Design, deploy, and discipline macOS launchd watchdogs — LaunchAgents/LaunchDaemons that detect a recurring problem and auto-remediate it. Use whenever creating or editing a persistent background monitor / daemon / agent on macOS, writing a launchd plist, scheduling a self-healing script, or when a watchdog has become a disturbance itself: re-launching apps the user quit, firing repeated notifications, re-running its full repair ladder every few minutes on an unfixable network, or hammering the system (crash loops, fork storms, runaway restarts). Also use for stop/disable semantics (bootout vs bootstrap vs disable vs unload), adding cooldown / backoff / notification throttling to a self-healer, binding a monitor's lifecycle to its premise state, or auditing existing LaunchAgents. 中文触发:launchd 守护进程、常驻任务、开机自启、后台监控、定时自愈脚本。 Covers KeepAlive/ThrottleInterval/domains/logging, premise self-checks, auto-cooldown, alert layering, batch throttling.

L4 High-Privilege · Graded auth & full auditV1 Commit-PinnedExecute CommandWrite FileDual-pass Audit
Author daymadeGitHub daymade/claude-code-skills ↗Stars 1385License MIT(仓库根 LICENSE,Copyright (c) 2025 daymade;GitHub API spdx MIT)Commit d5c4678cb5
Control levels describe skill capabilities and suggested control measures; they do not represent quality or safety certifications, nor do they dictate usability. Usage decisions rest entirely with users and administrators. Different agent hosts apply varying constraints; do not assume hosts provide automatic protection. Third-party skill copyrights belong to their original authors. Use at your own risk.

1How It Works & Mechanism

Design philosophy: Bind the watchdog's lifecycle to its premise state—when its reason for existing vanishes (Wi-Fi disconnected, user quit the target app, prerequisite state missing), it must stand down on its own rather than waiting for manual disabling; the core doctrine of this skill is 'never let a watchdog become a new disturbance'.

daymade-macos/macos-watchdog/SKILL.md
**a watchdog's lifecycle is bound to its premise state**. When the condition it exists to fix cannot be fixed by it (broken WiFi, user quit the target app, prerequisite state gone), the watchdog must stand down *by itself*
This is the primary thread of the skill: deployment guidelines are merely the outer shell, whereas the four clauses of the 'quiet-watchdog contract' (premise self-check / fix before alerting with multi-cycle escalation / stepped automatic cooldown / never resurrect an app intentionally quit by the user) form the core protection against disturbances.

Deployment mechanisms leverage native launchd tooling: using assets/launchagent.template.plist as a foundation, new-launchagent.sh performs idempotent installation (validates label/interval/program → bootout-if-loaded → writes plist → plutil -lint → launchctl bootstrap → verifies via launchctl print).

daymade-macos/macos-watchdog/scripts/new-launchagent.sh
plutil -lint "$tmp_plist" >/dev/null || { echo "Generated plist failed plutil -lint" >&2; rm -f "$tmp_plist"; exit 1; }
interval <30s is rejected outright (crash-loop zone); program must be an absolute and executable path; label must follow reverse-DNS notation; --system uses sudo to write to /Library/LaunchDaemons + the system domain (root daemon logs must not reside in user home directories).

Cooldown logic is enforced at the application layer rather than via ThrottleInterval: when sourced, watchdog-cooldown.sh provides paused_any/record_exhausted/clear_exhausted/cmd_pause/cmd_resume, tracking consecutive exhausted cycles in a state file and backing off quietly across stepped intervals (default 1800/7200/21600 seconds = 30m→2h→6h).

daymade-macos/macos-watchdog/scripts/watchdog-cooldown.sh
space-separated escalating tiers, seconds. Default "1800 7200 21600"
The documentation clarifies why ThrottleInterval is insufficient: it merely throttles process respawns, enforces a fixed delay without backoff, and fails against jobs that 'exit 0 yet still spam logs'—since the spam happens at the application layer, the silence must be enforced there too.

Stop semantics explicitly surface deprecation traps: on macOS Ventura+, unload can resurrect jobs if the plist remains present and RunAtLoad is set; modern pairs like bootstrap/bootout and disable/enable (persisting stop across logins) must be used instead.

daymade-macos/macos-watchdog/SKILL.md
**Never `launchctl unload`**: deprecated, and on Ventura+ the job re-loads via `RunAtLoad` when the plist stays in place — the "disabled" watchdog fires again
The command reference table in this section provides exact syntax for three distinct intentions: bootout (stop now), disable (stop across logins), and bootout→edit→bootstrap (reload after editing a plist).

Resurrection prevention gate: If remediation involves URL schemes, open -a, or restarting GUI apps, it must be guarded by a process vitality check and include the -g flag (do not steal foreground focus)—otherwise, the watchdog behaves like 'you quit it, but I force it back open'.

daymade-macos/macos-watchdog/SKILL.md
Gate every such action: check the target process is alive before invoking its scheme, and pass `-g` so a legitimate action never pops a window. If the user quit the app mid-remediation, abort the ladder
Cleanup traps must adhere to this exact same gate; otherwise, a fallback intended to 'ensure connection on exit' will inadvertently turn into a resurrection culprit.

2Core Capabilities

01End-to-end new watchdog deployment (location selection for LaunchAgents vs LaunchDaemons, plist templates, loading/reloading/logging/idempotency)
02Quiet-watchdog four-clause contract review (diagnosing nuisance behaviors in existing watchdogs: spam/resurrection/idling/log spamming)
03Idempotent installer new-launchagent.sh (bootout-if-loaded → write plist → bootstrap → launchctl print verification)
04Application-layer stepped cooldown / manual pausing (watchdog-cooldown.sh state machine)
05Precise command matrix for stop/disable semantics (bootout / disable / enable / unload pitfalls)
06Troubleshooting cheat sheet (resurrection/spamming/false health/ineffective bootout/silent failures/TCC interpreter mismatches)
07Default rate-limiting discipline for batch tasks (preventing unthrottled loops = runaway processes)

3External Dependencies

KindDependency / Endpoint
clilaunchctl(bootstrap/bootout/kickstart/print/list/disable/enable)
cliplutil(plist lint 校验)
clisudo(--system 路径:/Library/LaunchDaemons + system 域 bootstrap)
cliopen / log show / id -u(GUI 域引导、launchd 日志排查)

4Recommended Governance & Evidence

Suggested Controls for Safe Operation
For Agent Runtime
Graded/per-use authorization, sandbox recommended
For Administrators
Approval workflow, rollback support, full audit
Evidence & Triggers (File Paths & Excerpts)
  • scripts/: Local script or command execution: scripts/new-launchagent.sh (installation phase: bootout/write plist/bootstrap)
  • 本地工作目录: File I/O and artifact output: ~/Library/LaunchAgents/<label>.plist (or sudo /Library/LaunchDaemons/<label>.
Audit Notes: Local launchd automation skill: no outbound network calls, no credential reading (templates explicitly mandate world-readable plists without secrets). Yellow rating is driven by its design purpose—installing executable scripts as **persistent background jobs** (LaunchAgents/LaunchDaemons). Paths with --system write to /Library/LaunchDaemons via sudo and bootstrap into the system domain, executing trusted scripts periodically with user/root privileges, representing a persistent system-level attack/change surface; furthermore, watchdog scripts generated by models using this skill are not strictly constrained by the skill itself (only indirectly guided by the four-clause discipline and input validation). Without outbound traffic or credential access, it does not warrant orange; however, because it represents a persistent root-level execution surface rather than standard local file I/O, it is rated higher than blue: yellow.

5Second-Pass Verification

  • [ok] 四条款契约与真实事故绑定 — SKILL.md 每条 clause 后都带真实案例('Real case: a recovery watcher kept firing for 2h after its premise resolved'、'unthrottled test replay forked 1,041 processes/sec for 7 minutes' 等);war stories 在 references/quiet-watchdog-patterns.md。
  • [ok] new-launchagent.sh 校验与安装流程 — label reverse-DNS 校验、interval 整数且 ≥30、program -f/-x 绝对路径、tmp plist + plutil -lint、bootout-if-loaded、launchctl bootstrap + print 验证,全部逐字在源码。
  • [ok] cool-down 状态机(1800/7200/21600 阶梯) — watchdog-cooldown.sh 常量与文档默认一致;state 文件 pause/autopause/exhausted.state;提供 cmd_pause/cmd_resume/record_exhausted/clear_exhausted/paused_any。
  • [ok] unload 陷阱与 bootstrap/bootout 语义 — SKILL.md 'Never `launchctl unload`' + Ventura+ RunAtLoad 复活机制说明 + bootout/disable 命令表,与脚本实现一致。
  • [ok] 运行路径无网络(安全结论基础) — 全目录运行代码无 curl/wget/http 调用;唯一 curl 出现在 evals/iteration-1 fixture broken-heal.sh(评测反例夹具),已在 internal_assets/风险注记中说明非运行路径。
  • [ok] 无凭证读取 + plist 密钥警告 — plist 模板 'Never put secrets here; the plist is world-readable.';脚本无 token/API key 处理。
  • [ok] 元数据(commit/license/stars) — 本地 HEAD == pin d5c4678cb5d4fd6acc9c922690df035dbd33d247;GitHub API:MIT、stars 1385(2026-09-09 实采)、pushed_at 2026-09-09T12:33:29Z。

6Verdict & Scenarios

  • Genuinely understands that 'a watchdog can become a new failure mode': treats self-healer dysfunction (resurrection, spam, spinning, fork storms) as first-class problems.
  • Application-layer cooldowns and premise self-checks form practical engineering patterns: ThrottleInterval cannot address application-layer spam, whereas state files + stepped backoff do.
  • Incident-driven and battle-tested: every discipline is backed by real-world cases and observational metrics (e.g., N=2 cycles derived from 94-minute monitoring), not theoretical posturing.
  • Built-in idempotency and verification: new-launchagent.sh ensures convergence on re-runs, performs plutil -lint, and validates via launchctl print after bootstrap, preventing deployment drift.
  • Side-effect disciplines like anti-resurrection and batch throttling are codified as explicit gates and default parameters, eliminating the two most common watchdog anti-patterns.
  • Best for: Ideal for macOS background monitoring scenarios requiring 'periodic detection + automatic remediation': creating and governing watchdogs for network, proxy, configuration rollback, or service keep-alive, as well as diagnosing and fixing existing watchdogs that have become nuisances (resurrecting apps, spamming notifications, or hammering system resources); suited for engineering-minded users who write/review watchdog scripts and understand launchd domain models.
    Not for: Not suited for one-off remediation tasks that do not require persistence; not suited for users lacking the ability to write or review scripts who intend to deploy root daemons; not suited for non-macOS platforms; not suited for those looking for a 'fire-and-forget' setup—the core purpose of this skill is precisely to watch the watchdog.
    Install Agent-Ready
    ① Verified Mirror 2026-09-09
    Option A · Direct DownloadDownload macos-watchdog.tar.gz
    sha256: 84c303ee98ee57c6…
    Option B · Copy Guide for Agent
    install.json
    Agents automatically download and verify mirrors from this JSON guide.
    ② Upstream GitHub
    GitHub Repo ↗
    Pinned to commit d5c4678cb5.