Keep a Mac awake for one VPN task, not for the VPN

You need one transfer to finish while you step away, and the Mac sleeping is the obvious suspect. caffeinate can hold a power assertion for exactly that window, and it is a narrower tool than it first appears. It prevents idle sleep while a command runs; it does not keep a VPN session alive, and it will not save a transfer from a credential that expires at midnight. Knowing where its reach ends is what stops the next failure from being blamed on the wrong layer.

What the assertion actually holds

The utility asks the power-management system to keep a claim open while the wrapped process lives. When the process exits, the claim goes with it. That lifetime is the useful part: you are not toggling a machine-wide setting and hoping to remember to undo it later.

The flags select different claims. -i prevents idle system sleep. -d targets display sleep, and -s targets system sleep in the situations where the system allows it. None of them is a blanket "stay awake" promise, and none of them unlocks the screen or defeats a lid close. Pick the one that matches the interruption you actually saw.

That distinction matters when someone reports that the Mac "still slept". The question is which claim was requested, for how long, and what event caused the sleep. Power management evaluates several inputs, and an assertion covers one of them.

Wrap the task instead of decorating the session

caffeinate -i /usr/bin/ssh [email protected]

This keeps the idle-sleep claim for as long as the SSH client runs, which is the whole point of wrapping rather than backgrounding. The VPN profile is untouched, no keepalive is sent, and nothing about the tunnel's configuration changes.

For a bounded window, the duration flag is the honest form:

caffeinate -i -t 1800

Stop that invocation with its normal interrupt when the task finishes early. Do not leave a stack of wrappers in the background and later clean up by killing every process with the same name; you will take out something you wanted to keep.

Sleep is one cause, not the cause

Preventing idle sleep removes one interruption from the list. It does not override a deliberate sleep command, a closed lid, a power loss, or a policy that an administrator set. Those are separate decisions, and expecting a user-level assertion to win them is how people conclude the tool does not work.

Display sleep and screen lock are also separate. A Mac can stay awake with the display off, and it can lock while the task continues. If the requirement is an illuminated screen, that is a different flag; if the requirement is an unlocked screen, no flag provides it. Say which of those three outcomes you actually need before picking a switch, because they are not one behaviour under different names.

The VPN session keeps its own clock

An IPsec or TLS tunnel rekeys on a schedule the endpoints agreed to, and a server can enforce a maximum session lifetime regardless of client activity. Credentials expire. An access link can drop for reasons that have nothing to do with the laptop being awake. None of these care about a power assertion.

So when useful traffic fails while the Mac is clearly awake, increasing the duration is not an explanation and not a repair. Read the failure: a rekey error, an authentication expiry, and a dropped carrier look different in the tunnel log, and each has its own fix.

Put durability on the remote host

If losing the local connection would waste hours of work, the answer is on the far side. A terminal multiplexer keeps the session alive on the server when SSH dies, and a job system keeps the work alive when the session ends. Neither depends on the laptop's power state.

That is a different failure boundary, and it is the one that matters for long jobs. Combine the two only when both are true: the machine must stay awake for the local part of the work, and the remote part must survive a disconnect. Then verify by reconnecting from a second terminal and checking the job is still running.

Write down the assertion you used and when it ends. A short-lived operational choice is fine; an unexplained permanent one becomes a support ticket six months later when nobody remembers why the Mac never sleeps.