Developer Runtime Safety for AI Agents

The real risks of long unattended AI agent runs

An overnight Ollama run, a Claude Code agent scaffolding a full feature, a build pipeline that re-runs on every file change — these workloads share one property: no human watching. When nothing watches for you, the standard macOS idle-sleep guard kicks in but draws no hard line around battery level or sustained CPU heat. The run continues until it finishes, or until the Mac shuts itself down.

Battery risk is cumulative. Charging a MacBook from near-empty repeatedly strains the charge cycle count faster than charging from 40–80%. A single overnight drain to 0% is rarely fatal; a habit of it over weeks accelerates capacity loss. The more immediate danger is a stalled agent — a prompt loop, an API timeout that never retried, a build waiting on a locked port — consuming steady CPU at 60–70% for hours while you sleep, neither finishing nor surfacing an error.

Thermal risk on a MacBook is partly self-managed by macOS and partly dependent on the physical environment. The chip will throttle itself, but throttling means a longer, hotter run — not a safe one. A MacBook on a soft surface with vents blocked, or running lid-closed with poor airflow, concentrates heat in a smaller area. No software tool changes that physical reality. Guardrails help you stay within the safer part of the operating range; they do not override physics.

Battery safety: why a low-charge floor matters

A low-battery floor is a hard stop: when charge drops to a threshold you set, the run ends, the machine returns to its default sleep behavior, and you wake up to a Mac with some charge remaining. The difference between a 10% and a 25% cutoff is meaningful. At 10%, a brief spike in CPU load or a delayed fan response can push into the zone where macOS triggers an emergency shutdown without warning. At 25–30%, you have runway — enough charge for a clean stop and margin against unexpected load spikes.

LidRun's battery auto-stop watches charge level via IOKit and stops the power assertion when the threshold is crossed. For laptop-only overnight runs — no charger, just the battery — 25% is a reasonable floor for most MacBooks. If your workload tends to spike (large model inferences, heavy compilation), 30% gives more margin. Running on AC power removes the immediate drain concern, but a floor still protects against adapter disconnection mid-run.

For any run longer than two hours, plug in first. Sustained high CPU load on battery compresses charge cycles faster than the same load on AC. This is not a LidRun-specific recommendation — it is basic hardware care. The macOS battery health notification reflects this; repeated deep-discharge cycles trigger the warning earlier on machines used heavily for compute. Prefer charging for overnight agent work whenever the option exists.

Thermal safety: what the Mac tells you and what it does not

macOS exposes thermal state through ProcessInfo.thermalState: nominal, fair, serious, critical. LidRun reads this signal and can stop the assertion when state reaches 'serious'. The catch is granularity: 'serious' covers a wide temperature band, and the system only steps to 'critical' when it is already throttling hard. By the time the API returns 'critical', clock speeds have already dropped. Stopping at 'serious' is the more useful trigger — it catches the climb before the worst of the throttle.

Fan speed and SMC sensor data are readable on Intel Macs and some Apple Silicon configurations. On Apple Silicon, fan control is largely managed by the platform controller and is not exposed the way it was on Intel. LidRun reads fan metrics as a monitoring signal on compatible hardware; it cannot force fans to spin faster on chips where that path is locked. Knowing a fan is already at 4,200 RPM tells you the system is working hard. Whether it is safe to continue depends on the thermal state trend and the physical setup together — not on any single metric.

Software thermal guardrails are a second line of defense. The first is physical: hard flat surface, vents clear, lid open where possible. Lid-closed running concentrates heat more than lid-open running, which is worth understanding before you set up an overnight clamshell workflow. A laptop stand with bottom clearance, or even a simple desk elevation, makes a measurable difference. Running a long compute job in a bag or enclosed space is the highest-risk configuration — no process monitor changes the heat trap that creates.

Building safe defaults for overnight agent work

For a typical overnight AI agent run on a developer Mac, a reasonable starting configuration: battery floor at 25–30%, thermal stop at 'serious' or above, session timer set to 8 hours or however long until you will be awake. The session timer is often overlooked. It catches the case where the agent stalled at hour two but the keep-awake assertion persisted until morning — burning battery and heat on a process that stopped doing useful work hours earlier.

LidRun's process detection can link the keep-awake assertion to a specific process — Claude Code, Ollama, a custom Python script. When that process exits, the assertion drops automatically. This is cleaner than a fixed timer because it matches the real workload duration rather than a worst-case estimate. Combine it with a session timer as an upper bound: the assertion ends when the process exits, or after N hours, whichever comes first.

Push notifications via ntfy.sh or Pushover close the loop. If you are running an agent overnight, a notification when it stops — whether from completion, low battery, or thermal state — means you know at 3 AM rather than discovering a cold Mac at 12% charge over breakfast. For jobs that should finish in two or three hours, this feedback matters: you can verify and kick off the next stage rather than losing half a day to a stalled run.

For short, attended runs, caffeinate and a watched terminal are often enough. Where LidRun adds value is the combination: battery floor plus thermal stop plus process-linked assertion plus notifications, managed from the menu bar without needing a terminal session to stay open. The safety comes from the stack of guardrails, not from any single feature. Set them once, leave the Mac running, and let the limits do their job.