Kiro was still working.
Your Mac didn't care.

Why your Mac sleeps while Kiro is still going

Kiro spends most of an agent task waiting on a model response — which barely uses any CPU. But macOS doesn't decide from CPU at all — it goes by your idle time, how long since real keyboard or mouse input, plus the power assertions running processes hold. So working hard doesn't protect the machine: a Mac mid-refactor sleeps on exactly the same schedule as one doing nothing. After your system-sleep timer runs out, macOS suspends the Mac, and Kiro's agent is frozen along with everything else until you wake it back up.

This bites hardest on exactly the work Kiro is built for: turning a spec into a long execution run, or letting parallel agents grind across a large codebase while you go and do something else. The fix is to stop macOS from sleeping for as long as the agent is actually running — then let it sleep normally again once the run is done.

If you only run long Kiro tasks occasionally, you don't need to buy anything. The Kiro IDE is a graphical app rather than a command you launch, so the caffeinate -i <command> wrap that works so neatly for terminal agents doesn't apply to it directly. (If you're on the separate Kiro CLI, it is a command — caffeinate -i kiro-cli wraps it and releases the moment it exits. See the next section for why we can't yet promise which process does the work.) For the IDE, what does work:

• A timed caffeinate. Run caffeinate -d -i -t 7200 in any terminal window before you walk away. That holds off both display and idle sleep for two hours and then releases on its own — no cleanup, nothing left holding your Mac awake if you forget. Change the number of seconds to suit the run. Note it occupies that terminal window for the whole two hours; leave it be rather than Ctrl-C'ing it back to a prompt, or you drop the assertion with it.
• Amphetamine (free, Mac App Store). A menu-bar toggle with triggers — it can hold a session while a chosen app is running, optionally only above a CPU threshold. For an agentic editor neither setting is really a work signal: plain app-running keeps your Mac awake for as long as Kiro is open, and a CPU threshold catches the editor's own indexing and redrawing while missing the long stretches where the agent sits near zero waiting on a model. Still free, still a reasonable choice if you just want a switch.
• Just change the setting. System Settings → Lock Screen and Battery. Blunt, free, and easy to forget you did it — which is how a laptop ends up never sleeping again.

All of these are a fine choice if you kick off a long Kiro run now and then. The catch is the same one every time: none of them knows when the agent actually finished. You either stop it yourself, or your Mac stays awake — and your battery drains — long after the work is done.

There is the Kiro IDE — the desktop editor you install into your Applications folder — and there is Kiro CLI, a separate download from cli.kiro.dev. They are not the same program, and anything you configure for one will not automatically cover the other.

The CLI has a surprise in it that matters here. On Linux the installer's own paths point where you'd expect: executables named kiro-cli and kiro-cli-chat under ~/.local/bin. On a Mac the installer itself puts nothing there. The macOS installer downloads a disk image called "Kiro CLI.dmg" and copies an application bundle into /Applications — and then you still drive it with a kiro-cli command, which the installer tells you to reach by putting ~/.local/bin on your PATH. So on macOS both shapes are in play at once: an app bundle in /Applications and a kiro-cli command in front of it. A keep-awake rule that watches only one of them can miss the other, and we have not run it on a Mac of ours, so we can't yet tell you which one is the process actually doing the work during a run.

One more piece of lineage, in case you have it already: the installer looks for an existing Amazon Q CLI on your PATH and treats Kiro CLI as its replacement: it runs q update for you, or stops and asks you to uninstall it if it's somewhere it can't update. If you used Q CLI, Kiro CLI is where that tool went.

We read all of this out of Kiro's own published installer rather than guessing, but we have not run Kiro CLI on a Mac of ours — so treat it as read-from-the-source, not measured-on-hardware.