I Built a Free Windows App So My Coding Agents Keep Running With My Laptop Lid Closed.

I lost a six-hour agent run to a closed laptop lid, and that is the whole reason this app exists.

I had a coding agent working through a large refactor. I checked on it, saw it was moving, closed the lid, and went out. When I came back, the run wasn't finished, and it hadn't failed either. It had just stopped somewhere in the middle of a tool call. No error, no stack trace, nothing to debug. Windows had suspended the machine, and my agent went down with it.

So I made a small Windows app to fix that for devs like me who leave long jobs running and walk away. It is called Always Up, it is free, it is open source under MIT, and it is one 62 KB file with no installer and no dependencies.

Here is the problem, why the obvious fixes didn't work for me, and how I ended up solving it.

Why closing the lid kills a long-running job

When you close the lid, Windows does not send your program a polite shutdown signal. It suspends the machine. Your process is no longer scheduled.

That is why the failure looks so strange when you open the lid again:

• The SSH session is gone.
• The API request timed out on the other end.
• The agent's tool call never returned.
• Nothing wrote an error, because nothing errored.

For a normal app, this is fine. You reopen the lid and carry on. For anything long-running, it is the worst kind of failure, because you get no signal at all about what happened, and you have to start over.

The three fixes I tried first, and why each one failed

I did not start by writing an app. I started by trying to configure my way out of it, the way most of us would.

1. I set the lid action to "Do nothing".

This stops suspend the moment the lid shuts. Then twenty minutes later, the machine hit its idle timeout and slept anyway. An agent that is waiting on an API response looks exactly like an idle machine to Windows. No CPU spike proves otherwise.

2. I used a keep-awake app.

Caffeine-style tools work by making a "keep the system awake" request to Windows. That request is real, and it works, but the lid action ignores it completely. These are two separate policies, and neither one overrides the other. Close the lid, sleep.

3. I turned off sleep in Power Options.

That panel does not reach every setting that matters. Two of the important ones, the unattended sleep timeout and the display off after lock timeout, are not exposed there. On newer laptops that use Modern Standby, which is a low-power idle state instead of true sleep, the machine also drifts down on its own.

The pattern I eventually understood is this: no single setting does what I want. The lid behaviour, the awake request, the idle timeouts, and the unattended timeout are four separate things. You need all of them pointing the same way at the same time.

That's genuinely annoying to set up by hand, and even more annoying to remember to undo. So I built the switch.

What Always Up actually does

One toggle: Keep this PC awake with the lid closed.

Turning it on sets all the involved policies at once. Turning it off, or quitting the app, restores your original settings.

Here is the full list of what it touches, so nothing is hidden:

The display one mattered more than I expected. On a docked laptop with the lid shut, the external monitor is your only screen. If Windows blanks it, some capture, streaming, and rendering work stalls along with it.

Who I built this for

I built it for my own setup first: a laptop on a shelf, lid closed, running agent work overnight. It turned out to cover a set of jobs that all have the same shape:

• AI coding agents. Claude Code, Codex, Cursor, Aider, or any agent loop that runs for hours and holds network connections the whole time.
• Local models. An Ollama or llama.A server you want to reach from your phone or another machine while the laptop sits closed.
• CI runners and build agents on a spare laptop.
• Long jobs. Training runs, dataset processing, video encodes, big syncs, a home media server.
• Docked work. Lid closed, external monitor as the only display.

If you use a desktop, you do not need this. If your laptop only needs to stay awake with the lid open, PowerToys Awake already covers you, and it is a great tool. I built Always Up for the closed-lid case specifically, because that is the one thing nothing else solved in a single switch.

How I built it, and why it is one small file

I wanted an app I would actually trust running elevated on my own machine, permanently, at startup. That pushed almost every decision toward less.

C# on .NET Framework 4.x. It ships in the box on every Windows 10 and 11 machine, so no one has to download a runtime first.

WinForms with every control painted by hand. No WinUI, no WPF, no control library. That is more work up front, and it is why the whole app is one file with zero dependencies instead of a folder of DLLs.

The power API directly, not powercfg output. This one is worth explaining, because it is the kind of thing you only learn by hitting it. My first instinct was to shell out to powercfg /query, read the values, and write them back. That does not work for two reasons. Several of the settings I needed are hidden, so they are readable and writable through the API but are never printed in the query output at all. On top of that, the friendly names powercfg prints are translated per language, while the underlying identifiers are not. A parser built on that output would break on any non-English Windows install. So the app reads and writes through powrprof.dll and never parses text.

Built with the compiler already on your machine. The build script calls csc.exe from the in-box .NET Framework. No Visual Studio, no SDK, no package restore. If you would rather not trust a downloaded binary, you can clone the repo, run build.cmd, and compile it yourself with nothing else installed.

The whole thing is two source files: AlwaysUp.cs for the logic and Ui.cs for the interface.

The bug that taught me the most

This one cost me an evening, and I think it is useful to anyone writing an elevated Windows app.

Always Up runs as administrator, so launching it shows a UAC prompt. If you dismiss that prompt with the keyboard, the key up event lands on the app window the instant it takes focus. There was never a matching key down, because the key was pressed while a different window was in front.

As a result, my app read a stray key up as "the user activated this control" and switched the machine's power settings on by itself at launch. It looked completely random until I traced it.

The fix is small, and I now apply it everywhere: controls that change power settings only fire on a completed gesture. Press and release inside the same control, or key down and key up in the same control. Never on a bare click event, and never on a key up on its own. The window also opens with nothing focused.

If you write elevated WinForms apps, you will run into this eventually. Save yourself the evening.

Giving the settings back

This was the part I cared about most as a user, because these are machine-wide settings and the app is only borrowing them.

The awake request dies with the process. It is tied to the app's own thread, so if Always Up crashes, that request disappears instantly. A crash can never leave your machine stuck awake.

The power settings persist, so the app snapshots your original plugged-in and battery values the first time it changes anything. Restore original power settings when I exit is on by default, and a Restore originals button lets you restore them right now without quitting.

About the admin prompt

Power settings are machine-wide, so changing them requires elevation. That means a UAC prompt on launch, and I think being suspicious is the right instinct.

So here is the complete list of what the app does with that privilege: it reads and writes the power settings in the table above, it registers or deletes one scheduled task named AlwaysUp, and it writes a small config file in your local app data folder.

It makes no network connections of any kind. It has no HTTP client, no socket, no update check, and no analytics. The only programs it ever launches are schtasks.exe for the Start with Windows option and powercfg for a read-only diagnostics dump.

All of that is verifiable. It is two files, the repo is public, and nothing clever is hidden in them.

Check it before you trust a real job to it

I would not want anyone to find out this works at hour five of an overnight run, so the app has a Diagnostics button that shows you three things:

• powercfg /a, which tells you which sleep states your machine actually supports.
• powercfg /requests, which tells you what is holding the machine awake right now, including other apps.
• The raw current value of every setting Always Up touches.

If that first one reports Standby (S0 Low Power Idle), your machine uses Modern Standby, and the lid setting alone genuinely is not enough on that hardware. Leave the "never" options ticked.

My honest advice is to do a ten-minute test before you rely on it. Start a job, close the lid, wait, open it, and confirm the job kept moving. Ten minutes of testing beats losing a six-hour run, which I can tell you about from direct experience.

What it does not do

Finding these out during a long run is worse than reading them now, so:

• Heat. A closed lid blocks airflow over the keyboard deck. A CPU-heavy agent runs hotter with the lid shut than with it open. Watch your temperatures on the first long run, and do not leave the machine on a bed or a couch.
• Battery. Keeping a laptop awake on battery drains it, and the app does not babysit your charge level.
• Modern Standby varies by machine. Some manufacturer firmware is aggressive about low-power idle in ways no user-space app can fully override. Diagnostics tells you what you are dealing with.
• Lock on lid close is separate. If something else in your setup locks the session when the lid shuts, that is outside what this app controls.
• Windows 10 and 11 only. It is built on Windows power APIs, so there is no meaningful port to macOS or Linux.
• The exe is unsigned. SmartScreen will warn you on first run. Code signing certificates cost real money for a free tray app. Build from source if that matters to you; it takes one command.

Try it

1. Download AlwaysUp.exe from the releases page.
2. Run it and approve the UAC prompt.
3. Turn on Keep this PC awake with the lid closed.

That is the whole setup. It lives in the tray; closing the window hides it, and you quit from the tray icon. Tick Start with Windows if you want it back at logon, which registers a scheduled task so it starts elevated without prompting you for UAC on every boot.

Repo, source, and issues: github.com/sudoatif/always-up

FAQ

Can I keep my laptop running with the lid closed?
Yes. You need to change the lid action, the idle sleep timeouts, the unattended sleep timeout, and add a keep-awake request. All four have to agree. Always Up sets them together behind one toggle.

Will my coding agent keep running when I close my laptop?
Not by default. Windows suspends the machine, and your agent stops mid-task without an error. With the lid behaviour and the awake request both set, it keeps running.

Is this different from PowerToys Awake or a caffeine app?
Yes. Those make a keep-awake request, which the lid action ignores. They are good for keeping a machine awake with the lid open. This one is built for the closed lid case.

Does it change my settings permanently?
No. It snapshots your originals the first time it changes anything and restores them when it exits. Restore on exit is on by default, and there is a manual restore button.

Why does it need administrator rights?
Power settings are machine-wide, so writing them requires elevation. The app makes no network connections, and the source is public if you want to check.

Does it work on Modern Standby laptops?
Usually, and the idle timeout settings do real work there. Some manufacturer firmware is aggressive about low-power idle. Run Diagnostics, then test with a real job before relying on it.

Closing

I built this because I lost work, and I kept building on it because closing a laptop lid should not quietly kill whatever you left running.

If you run agents, local models, or long jobs on a Windows laptop, test it for ten minutes and see if it holds on your machine. If it does not, open an issue with the Diagnostics dump attached, and I will look at it. That dump answers most of the questions before anyone has to guess.