macOS Load Doctor

5. Act within the boundary

On a shared machine, diagnosis is read-only; remediation has an owner.

• Never terminate another session's, agent's or user's processes. A "service restart" whose side effect is killing the daemon's children is the same action in a nicer wrapper — it counts as terminating them.
• What you may do yourself: throttle your own loops, renice your own processes, stop your own background jobs.
• Terminating or restarting another session's, agent's, service's or user's process requires the current user's explicit authorization. Coordinate ownership with peers, but their agreement does not grant that authorization. Pause only the intervention that needs approval; continue the authorized read-only investigation that does not depend on it.
• For a named alert, reconstruct its recorded window, measurement units and trigger calculation before attributing the cause. Another process being hotter does not explain why this alert fired. Keep alert validity and the machine's actual workload as separate conclusions.
• For a diagnosis or remediation request, progress reports do not end the task. Do not send a closing answer with the cause unknown while an authorized probe can still distinguish the competing explanations. Diagnosis completes when a specific mechanism explains the requested symptom or alert and has evidence that discriminates those explanations; an approved repair continues through independent readback. A standalone snapshot-only request can end after that snapshot; a status question during active diagnosis gets a progress update while investigation continues. An explicit pause is honored. If an external condition blocks all remaining probes, name it and the missing evidence as unfinished, rather than claiming completion.
• Once the current user authorizes an intervention, execute and verify it; handing an already authorized action back as another report is not completion.
• After any remediation (yours or the owner's), read back: re-run sysctl -n vm.loadavg and the census. A command receipt is not recovery; the load and the child count are.

Common leak patterns

Short table in this file for the shapes seen repeatedly; worked cases with real probe outputs and the reasoning chain live in references/incident-playbook.md — read it when the census shows something you have not seen before, or when you need a precedent for the report you are about to write.

• Per-thread MCP spawners: an agent runtime starts the full configured MCP set per conversation thread and never reaps them; hundreds of proxy/helper processes accumulate under one daemon over days. GUI-flavored MCP servers additionally hammer WindowServer.
• Unthrottled batch loops: a replay/fuzz/migration loop with no rate limit is indistinguishable from a fork bomb to the rest of the machine — same rate, same heat, same cascading security-scan load.
• GUI busy loops: a menu-bar or settings app polling without sleep — one core at 100% for days, invisible until cumulative-time census.
• Respawn loops: a launchd job crashing and restarting every few seconds — launchctl list shows a non-zero last-exit code and a PID that keeps changing.

Troubleshooting

• Load is high but every reading looks normal: the suspects are short-lived — measure the fork rate directly: two ps -Ao pid= snapshots a few seconds apart, count the PIDs that appear only in the second (comm -13 <(sort old.txt) <(sort new.txt) | wc -l, divided by the interval). Dozens per second is a storm; a few is normal churn.
• The obvious big-CPU process is innocent: WindowServer, a terminal, or a screen-sharing client at high CPU is often downstream of the real cause (hundreds of GUI app copies each needing window service). Keep tracing.
• Everything points at a system service: that is the cascade shape — the fix is reducing the rate of new work reaching it, not the service itself.