Muse Code was still working.
Your Mac didn't care.

Why your Mac sleeps while Muse Code is still going

A coding agent spends most of a 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. Once your system-sleep timer runs out, macOS suspends the Mac and every Muse process freezes along with it until you wake it back up.

Muse Code makes this more annoying than a single-shot tool does, because Meta pitches it at multi-step work — its own description is an agent for "your most complex coding workstreams," built on several coordinated agents. Those are exactly the runs you start and walk away from. 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. You can do that for free in two minutes, or have something watch for real activity so you don't think about it.

If you only run Muse Code now and then, you don't need to buy anything. Because it's a terminal agent, the cleanest free fix is one command:

• The built-in caffeinate command. Start the agent as caffeinate -i muse instead of muse. The Mac can't idle-sleep while it runs, and the moment Muse exits, normal sleep is allowed again — nothing to remember to undo. Already on your Mac, free.
• Attach to a session you already started. You don't have to restart it. Look at what's actually running first, then attach to it: pgrep -lf muse-bin lists the matching processes with their command lines, and caffeinate -i -w <pid> holds sleep off until that exact process exits. Read the list before you pick a PID — see the next section for why muse-bin and not muse is the string to search for.
• Amphetamine (free, Mac App Store). A menu-bar toggle to keep the Mac awake on a timer or while a chosen app is running — handy if you'd rather flip a switch than type a command.

All of these are a fine choice if Muse runs for a few minutes here and there. The catch: none of them knows when the agent actually finished a task versus when it's sitting at an idle prompt. You either stop it yourself, or it keeps your Mac awake — and your battery draining — long after the work is done.

This is the part worth knowing, and it applies to any keep-awake tool that watches for a process by name — ours included.

Meta installs Muse Code with a one-line script (curl -fsSL https://dev.meta.ai/install.sh | bash). What that script puts on your PATH at ~/.local/bin/muse is not the agent — it's a small shell launcher. Every time you run muse, the launcher hands off to the real binary sitting next to it — and, at most once an hour, kicks off an update check in the background that lands for your next run. The real binary is named with the version baked in: ~/.local/bin/muse-bin-<version>. The handoff replaces the process image, so the thing actually running on your Mac for the next two hours reports itself as something like muse-bin-1.4.0-R2, not muse.

Two practical consequences. First, when you go looking for the running agent — pgrep, Activity Monitor, an allowlist in a menu-bar app — search for muse-bin, not muse. Second, because the version is part of the name and Muse updates itself in the background, any list pinned to one exact process name goes stale the next time Meta ships a build. That's an argument for matching on the stable muse-bin prefix rather than the full name.

Both facts come from reading Meta's own installer and launcher scripts, fetched on 12 August 2026. We have not yet run Muse Code on a Mac of ours to confirm what ps prints during a live task, and we'd rather tell you that than imply we have.