## Problem

Closing the lid suspends the machine immediately, whatever is running. That regularly lands mid-task: #10203 tracks an update killed by a lid close, and the same fate hits coding agent runs — close the lid on the way to a meeting and hours of agent work stall on suspend.

There is currently no way to say "not this close," and the system has zero awareness of background work. Lid close is an unconditional suspend (modulo dock/docked config), full stop.

## Solution

Two safeguards, both fail-open:

1. **Skip once, anywhere.** `omarchy toggle lid-suspend skip-once` (`Super + Alt + L`) skips suspend for the next lid close only, on AC or battery — the user explicitly asked for it, so we assume they know what they're doing. The lid still locks, it just does not suspend. Consumed on reopen; disarms after 30 minutes.
2. **Automatic guard, AC only.** While herdr reports a working agent **and the machine is on AC power**, lid close never suspends. On battery the guard stays out of the way — a working agent must never silently drain a battery in a bag. Hyprland's lid-switch binds still fire, so `omarchy-system-lid-close` keeps locking and reconciling displays. No herdr installed, no guard — the lid behaves exactly as before.

`omarchy toggle lid-suspend status` shows whether a skip is armed and whether the guard currently holds the lid.

## Rabbit holes (out of scope)

- General activity detection (CPU, per-app heuristics) — herdr's working state is the only signal.
- Battery-level-aware guarding (e.g. "guard below 80%") — the rule is binary: AC guards, battery doesn't.
- Touching the lock path — `omarchy-system-lid-close` is untouched; the inhibitor only suppresses logind's suspend action.

## No-gos

- No new hard dependencies — herdr is optional, absence means fail-open.
- Never suspend a docked closed lid — clamshell stays awake.
- No persistent "never suspend on lid close" mode — the manual side is one-shot by design; the permanent toggles (`suspend-off`) already exist for that.