The most common thing people believe about running Configure My AI on their own machine is that they have to be sitting at it. They don't. A locked screen stops nothing, a dark display stops nothing, and the one state that does stop work — real system sleep — is something you can switch off in a single command. Plugged in and on Wi-Fi is the whole requirement.

Three states that all get called "asleep"

This is where the confusion starts, so it is worth separating out. When you walk away from a laptop, three different things happen at three different times, and only the last one matters:

What happened	Does work still run?	Why
The display went dark	Yes	A panel turned off. Nothing about the CPU or the network changed.
The screen locked	Yes	The lock screen is a window drawn over a machine that never stopped. The companion is an ordinary background process and it keeps polling behind it.
The system slept	No	Every process on the machine is frozen, this one included. It stops heartbeating and shows as Offline within about ninety seconds.

So the goal is not "keep the machine unlocked" — nobody wants that, and it would be a bad idea in an office anyway. The goal is narrower and much easier: keep it from sleeping. Lock the screen all you like.

One command on a Mac

macOS ships with caffeinate, which holds sleep off for exactly as long as the command it wraps keeps running. Start the companion through it:

caffeinate -is cma-agent start

Two flags, because they cover different halves of the problem.

-s blocks system sleep outright. macOS only honours it while the machine is on the power adapter — which is the charged-and-plugged-in case, and the one worth designing around.
-i blocks idle sleep, the kind that arrives after a stretch of no keyboard and no mouse. That one holds on battery too.

Together they cover a machine you walked away from, whether or not it happens to be on the charger at that moment. And because the assertion belongs to the process, it disappears the moment you stop the companion. There is no setting left switched on afterwards, no pmset change to remember to undo, and nothing that outlives a reboot. That property is the reason to prefer it over changing the machine's power behaviour globally.

If you would rather set it once and stop thinking about it, the equivalent lives in System Settings → Battery → Options on a laptop — "Prevent automatic sleeping on power adapter when the display is off" — or System Settings → Energy Saver on a desktop. Then plain cma-agent start is enough. Lock with Control+⌘+Q, go and do something else, and send yourself work from your phone.

On Linux it is the same idea with a different name, and most Linux servers were never going to sleep in the first place:

systemd-inhibit --what=idle:sleep --why="cma-agent" cma-agent start

The lid is the one thing this cannot hold

Close a Mac laptop and it sleeps, whatever caffeinate has asserted — the only exception is clamshell mode, which needs an external display, power, and an external keyboard or mouse all attached. So the shape of "away from the computer" that works is screen locked, lid open. If that is not a thing you want on your desk, this is the argument for pairing a Mac mini or a Linux box instead: no lid, no version of the problem.

What happens when the Wi-Fi drops

Less than you would expect. The companion polls us — we never connect to it — so there is no inbound connection to lose, no port to forward, and nothing that breaks when the machine moves to a different network. A drop means a request that doesn't land, and the companion retries on its own with a widening backoff until one does.

In the web app the machine flips to Offline while it is out of touch and back to Online on the next heartbeat, thirty seconds apart. Nothing needs re-pairing. Nothing needs restarting. The pairing, the logins and the folders you shared all live in ~/.configure-my-ai and are entirely unbothered by the network coming and going.

Sleeping mid-run costs the run, not the machine

If a machine does sleep while a turn is in flight, that turn goes down with it and ends as a timeout rather than an answer. It is the single most common cause of a run that "just stopped". Nothing else is damaged — waking the machine is the whole fix, and the next message runs normally.

The one thing a lock screen does not survive

A restart. After a reboot the machine sits at the login window with FileVault holding the disk closed, and nothing of yours is running yet — the companion included. Locked after you logged in is fine; rebooted and never logged into is not, and no amount of caffeinate changes that.

If the machine is going to be away from you for days rather than hours, that is the case for starting the companion as a launchd or systemd service, so a restart brings it back without you. Worth checking the other clock too: a Claude login that expires while you are away fails the same way a sleeping machine does, and cma-agent status will say which one you are looking at.

What this is actually good for

The honest framing is that this makes your own machine a decent part-time worker, not an always-on one. A laptop that is charged, on Wi-Fi and locked will take chat turns and code sessions all afternoon while you are in meetings, and your Claude plan pays for them rather than your credits. That is a real amount of work to reclaim from a machine that was going to sit there regardless.

What it still won't do is the 3am case. Embedded widgets, API endpoints and scheduled bots are called by other software at times nobody chose, and those need a credential that does not depend on a particular computer being awake — an API key or managed credits. Keeping your plan for the work you initiate and a key for the work that initiates itself is not a compromise; it is the setup most people land on anyway.

The full version, including the flags, the Linux equivalent and what each device status means, is in the local machine docs. If you only ever use the machine while sitting at it, none of this needs doing — the companion already behaves the way you expect.