A coordinator agent spawned a subagent with a prompt stating "you are running in a cloud environment" to run a long data job (3 GB HTTP read of parquet row groups, 30-90 min) as a parallel hedge next to its own local run. The subagent actually ran in a local git worktree on the same 16 GB laptop with swap 92% full. Following the steps literally would have doubled memory and bandwidth on a swap-starved machine, produced two identical outputs, and raced two commits onto the same branch. A second trap: macOS `ps -o etime` prints [[dd-]hh:]mm:ss, so "02:35" is 2.5 minutes, not 2.5 hours, which nearly led to the wrong conclusion about which run was ahead. Third: the worktree-isolation guard refused every "clever" one-liner (heredoc, inline python spawning bash, arithmetic on a captured variable).

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 machine swaps to death daily and the browser is suspected, but Activity Monitor / ps only show dozens of anonymous "Helper (Renderer)" processes — there is no CLI mapping from process to tab, so people restart the whole browser blind and the leak comes back within minutes.

Disk-usage audit scripts written with GNU/Linux habits silently return nothing on macOS. Two independent causes: (1) BSD du treats -s (summarize) and -d N (max-depth) as mutually exclusive, so the common Linux idiom `du -sh -d 1 ~/` prints a usage error instead of results. When written as `du -sh -d 1 ~/ 2>/dev/null | sort -rh`, that usage error goes to stderr and is discarded, leaving empty output that looks like "the directory is empty" rather than "the command was invalid". (2) `timeout` is a GNU coreutils binary and is NOT present on a stock macOS install, so `timeout 900 du ...` dies with "command not found" — again producing empty output easily mistaken for a real measurement of zero.

A macOS machine intermittently freezes, becomes unresponsive, or has to be force-powered-off, and the user reports it as a crash. Standard checks mislead: `~/Library/Logs/DiagnosticReports/` may contain zero crash reports (bug_type 109), `pmset -g therm` shows no thermal throttling, and Activity Monitor shows nothing obviously wrong after the fact because the evidence is gone once the machine reboots. Per-process RSS also understates the problem badly for multi-process apps — a browser reported as "400 MB" in a sorted process list may actually be 40+ processes totalling 6 GB.

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.

On macOS, a GUI app that was running in fullscreen appears to still be open after being quit or force-quit: Mission Control keeps showing a tile for it in the Spaces bar at the top, often rendered as a solid black thumbnail with the app's name under it. The app is actually fully dead — `ps aux | grep -i <app>` returns nothing, `pgrep` exits 1, and the app is absent from `lsappinfo list` — but the ghost Space persists across Mission Control invocations, making users think the process is stuck.

Editing a config file fails with "EPERM: operation not permitted" on the rename step of an atomic write (tmp file → target), even though `ls -l` shows the user owns the file with write permission. Standard permission debugging (chmod, chown, parent dir perms) finds nothing wrong.

A Mac feels suddenly slow but a single `top` sample shows mostly idle CPU, making the cause look invisible. The slowdown is transient and the obvious tools give misleading readings (top's first sample always reports 0% CPU per process; memory looks "full" but is actually fine).

A long-running `next dev` session (Next 16.x) forks a child process from `.next/dev/build/postcss.js` roughly once per second and never reaps it. Within ten minutes a machine can accumulate 400-500 orphaned node workers consuming 10+ GB RSS. Symptoms are a load average in the hundreds, fully exhausted swap, and a desktop that becomes unusable — while no single process looks abnormal in Activity Monitor, because the cost is spread across hundreds of small workers. The dev server itself shows only moderate CPU, so it is easy to blame the browser or the OS instead.