Building StillOn around the part of Mac sleep that caffeinate misses

The first test was supposed to be boring

I had an agent running a long task on my MacBook and needed to leave. The obvious command was caffeinate: keep the machine awake, close the lid, and check the session later. Instead, the lid changed the power state in a way the ordinary idle-sleep assertion did not cancel. The command was still correct; it was solving a different sleep path.

That distinction became the entire product boundary for StillOn. I did not want another task runner or a second dashboard. I wanted one small utility that said: when I explicitly arm this Mac, let the display turn off and let the work already running continue.

There is more than one kind of “awake”

The screen, the user-idle timer, the whole system, and the lid sensor are related, but they are not one switch. A normal keep-awake assertion is useful for preventing idle sleep. It does not automatically mean a notebook will ignore the clamshell transition without an external display.

StillOn combines a system sleep assertion with the lid-specific power-management control used by macOS. It then asks the display to sleep and locks the session. The intended state is not “pretend the laptop is open.” It is “screen dark, session locked, computer available to the process that is already working.”

• Idle-sleep prevention keeps inactivity from suspending work.
• The lid-close path needs its own explicit handling.
• Display sleep and system sleep should remain separate decisions.
• Locking is part of the transition, not an optional afterthought.

Restoring state mattered more than arming it

It is easy to demo the moment a lid closes. The less visible work is making sure the Mac returns to ordinary behaviour after the lid opens, the app quits, the computer restarts, or a safety condition intervenes. A utility that can set a power-management bit must be equally deliberate about clearing it.

The implementation therefore tracks the assertion it owns and tears it down at the lifecycle boundaries it can observe. StillOn also uses an early display blank and a heartbeat because docks and power transitions do not always arrive in the clean sequence a single desk test suggests.

The lid setting is shared with macOS power management, not a private sandbox belonging only to my app. That makes conservative restoration and repeated physical tests more important than a clever animation in the menu bar.

I kept the gesture small

There are two ways to use the beta. A persistent arm lives in the menu-bar control. For a one-off session, hold Fn while closing the lid. If the lid is tilted and reopened without completing the gesture, StillOn should do nothing.

The one-shot gesture is useful because it carries intent at the exact boundary being changed. I do not need every close to mean the same thing forever. I need this close, for this job, to keep the Mac available.

The limits belong in the product

StillOn uses an undocumented IOKit selector for the lid behaviour. It works on the Apple-silicon machines and macOS versions I am testing, but Apple can change an undocumented interface in an update. That is why this remains a beta and why update testing is part of the release work.

It also does not make heat disappear. The screen is off and the GPU is no longer driving that display, but a heavy local model or build can still make the computer warm. A working Mac needs ventilation. I would not put it in a bag, and I would not treat a remote connection as proof that thermals are fine.

The useful promise is narrow: StillOn can keep a supported Mac available with its lid shut when you deliberately arm it. It does not guarantee an agent will succeed, monitor the task, or make a physically unsafe setup safe.