Set up the lidrun CLI for your dev workflow
If you spend your day in a terminal, reaching for a menu-bar icon to keep the Mac awake breaks your flow. The lidrun command-line tool puts the same control where your hands already are. This is a setup guide for the CLI itself: the commands it gives you, how it talks to the app, and where it earns its place in scripts.
What the lidrun CLI is
lidrun is a thin command-line front end to the LidRun app. It does not hold power on its own and run as a separate daemon; instead it talks to the running app over a local IPC socket and asks it to do things.
That design matters for one practical reason: the same safety governor that gates the GUI also gates the CLI. A keep-awake you start from the terminal still respects your battery floor and thermal limits, because the app, not the CLI, is making the decision.
So the CLI is best thought of as a remote control for the app you already trust, not a second, parallel tool with its own rules.
The commands you'll actually use
lidrun status is the one you will run most. It shows the current keep-awake and clamshell state, so you can check whether the Mac is being held awake without leaving the terminal.
lidrun start and lidrun stop turn keep-awake on and off explicitly. If you prefer a single key, lidrun on, lidrun off, and lidrun toggle do the obvious things, with toggle flipping whatever the current state is.
lidrun -- <command> is the one worth knowing well: it wraps a single command, holding a short-lived keep-awake assertion just for that command and releasing it when the command exits. And the housekeeping commands round it out, lidrun --version to check what you are on, and lidrun help when you forget the exact flag.
Guía relacionadaRun a long command, then let your Mac sleep when it's doneHow it fits a script
Because lidrun returns and the app holds the state, the CLI composes cleanly into shell scripts. A deploy script can call lidrun start at the top and lidrun stop at the end, so the Mac stays up for the whole run and goes back to normal afterward.
For a single long step inside a script, the wrapper form is tidier: lidrun -- ./long-step.sh keeps the Mac awake for exactly that step and no longer, which is easier to reason about than a start/stop pair you have to remember to balance.
The honest caveat is that the CLI needs the app running to talk to, since it is a client over the socket. Check lidrun status if a command does not behave as expected, and make sure the app is up before a script relies on it.
Laptop CI and unattended runs
A common reason to want this is CI on a laptop: a self-hosted runner, a nightly job, a scheduled task that must not be cut off when the Mac would otherwise idle to sleep. Wrapping the job, or bracketing it with start and stop, keeps the machine up for the run.
Pair the CLI with the rest of LidRun rather than treating it as the whole story. Auto Mode can keep the Mac awake while watched tools are genuinely busy, and the GUI runner gives you the exit code and duration of a wrapped command. The CLI is the scriptable seam between them.
And the same caveats apply here as anywhere: an unattended laptop job still runs through the safety governor, so charge or thermal pressure can end a session, and a hard, ventilated surface with mains power is the right setup for anything long. The CLI helps reduce the friction of keeping a Mac awake from the terminal; it does not change the safety story underneath.
LidRun mantiene tu trabajo en marcha con la tapa cerrada, con protección de batería y temperatura integrada.
Preguntas frecuentes
lidrun status shows keep-awake and clamshell state; lidrun start and lidrun stop control keep-awake; lidrun on, off, and toggle are shortcuts; lidrun -- <command> wraps a single command; and lidrun --version and lidrun help round it out.
Yes. lidrun talks to the running app over a local IPC socket rather than holding power itself, so the app needs to be up. The upside is that the same battery and thermal safety governor applies to CLI-started sessions.
Use lidrun -- your-command. It holds a short-lived keep-awake assertion just for that command and releases it when the command exits, with the app's battery and thermal limits still applying.
Yes. Bracket a job with lidrun start and lidrun stop, or wrap a single step with lidrun -- <command>, so a self-hosted runner or nightly task is not cut off by idle sleep. The safety governor still gates the session.