Updated May 2026 — v1.4.2: Codex integration is now hook-based (was process-based). See the Codex section below.
You know that feeling when you come back to your desk and your Claude Code session is just gone?
Not crashed. Not errored. Just a blank terminal because Windows put the machine to sleep while you were away.
It happened to me too many times. So I built something to fix it.
The Problem
Windows has a sleep timer. By default it kicks in after 10 or 15 minutes of no user input. The problem is that AI coding agents don't count as user input. You're not moving the mouse or typing. Claude Code is reading files, writing code, running tools in the background, and Windows has no idea anything is happening.
You lose your session, your context, sometimes your terminal state. If you kicked off a long agentic run and stepped away, that's genuinely painful.
The obvious fix is to disable sleep in Power Settings. But then you have to remember to turn it back on, and I never do. Laptop running hot at 3am for no reason.
What I wanted was something that keeps the machine awake while work is happening and backs off when it isn't.
What I Built
Insomnia is a small Windows tray app. It watches for AI coding activity and prevents Windows from sleeping. When activity stops, it releases. That's it.
No scheduled tasks. No registry edits. No "set sleep to Never."
How It Works
Three modes, all running at the same time if you want:
Claude Code Hook Integration
Claude Code has a hooks system that fires shell commands on lifecycle events. Insomnia registers as a hook handler for:
- PreToolUse and PostToolUse — Claude is using a tool
- UserPromptSubmit — you sent a message
- PermissionRequest — Claude is waiting for your approval
- Notification — Claude is surfacing something
When any of these fire, Insomnia activates. When they stop, it releases. No polling, no guessing, responds to the actual lifecycle of the agent.
OpenAI Codex Integration
Codex also gets hook-based detection, not process-based.
For CLI sessions, Insomnia registers a notify hook in ~/.codex/config.toml that fires when each turn completes. For the VS Code extension and standalone Codex app, Insomnia watches Codex's session transcript files — they only get written during active turns, so it's a clean signal with no false positives from the background app-server just being open.
Either way, the PC stays awake while Codex is working and idles out within 3 minutes of it going quiet.
Process Watching
For tools without a hooks API, Insomnia watches the process list. Cursor, Aider, Ollama — if any of them are running, your PC stays awake. When they close, it backs off.
Manual Toggle
One switch for when you just need the PC awake right now. Toggle it off when you're done.
The Tray Icon
Purple owl means awake. Grey owl means idle. Hover and it tells you why: "Staying awake for Claude Code." You always know what state you're in.
Stack
Electron, zero npm dependencies. Free, MIT licensed, Windows only.
Install
Direct download: https://github.com/stanley-projects/Insomnia/releases
Scoop:
scoop bucket add stanley-projects https://github.com/stanley-projects/scoop-stanley
scoop install stanley-projects/insomnia
winget:
winget install StanleyProjects.Insomnia
Enable the Claude Code or Codex integration inside the app and it wires up the hooks automatically. No manual config needed.
Links
GitHub: github.com/stanley-projects/Insomnia
Landing page: stanley-projects.github.io/Insomnia
Stars and feedback welcome.
Top comments (4)
Fellow Electron builder here -- I built a desktop Gmail client with Electron and I run Claude Code as an autonomous agent to handle all the marketing and operations for it. So Claude Code is both the tool I build with AND the thing that runs my business.
The keep-alive problem is real. My agent runs on a 4-hour cron job and I have hit similar issues with sessions dying mid-task. What does your app do differently from just setting the power settings to never sleep? Is it intercepting specific Windows power management events?
Also curious about your Electron setup. Are you using electron-builder or electron-forge for packaging? That decision alone probably cost me a full day of debugging.
Interesting setup. nooicee👌
To your question, the difference from "never sleep" in power settings is that Insomnia is conditional. Power Settings is a blunt instrument, your machine never sleeps, full stop, even at 3am when nothing is running. Insomnia uses Electron's powerSaveBlocker API which wraps Windows' SetThreadExecutionState under the hood. It can turn the sleep block on and off, so it only holds the lock while Claude or Codex is actually doing something, then releases it when Claude goes quiet. Your machine sleeps normally when it should.
It's not intercepting power events it's more the opposite. It's really just telling Windows "not yet" based on Claude Code's or Codex's own lifecycle hooks. When a hook is fired, Insomnia activates the blocker. When hooks stop coming for 3 minutes, it releases. For your cron job scenario that means the machine stays up for the full run and is free to sleep between jobs.
On packaging, electron-builder. What were you hitting with forge?
P.S sorry for the late response, just saw your comment lol.
Fellow Electron builder here! We're building a desktop Gmail client with Electron and hit similar process management headaches — our update checker used to spawn child processes that survived the parent app quitting.
What process does Claude Code run that Windows keeps killing? Is it a terminal subprocess it spawns, or something else? Curious if this is a Windows-specific quirk or if you've seen it on macOS too.
Not a process kill, more like a session disruption. Claude Code runs as claude.exe in the background, and when Windows sleeps mid task, the API calls drop and the session state breaks. The process itself might still be technically alive when you wake up, but the work is gone.
Insomnia sidesteps the child process angle completely it just uses Electron's powerSaveBlocker API, which calls the native Windows power management layer directly. Nothing spawned, nothing to clean up. Windows-specific problem.