How to Keep Muse Code Running After You Close Your Laptop
Published September 4, 2026 · by the AQ team
Closing your laptop stops Muse Code, along with every subagent it fanned out into worktrees, because the muse process runs on the laptop itself. Meta's event log makes the session unusually recoverable, but recovery is not persistence: nothing executes while the lid is shut. To keep a Muse Code task working you have to run it on a machine that never sleeps, and as of September 2026 Meta ships no hosted execution for Muse Code, no equivalent of Claude Code on the web or Codex cloud. That leaves three practical shapes: an interactive session kept alive on a remote box with tmux, unattended non-interactive runs on a server or in CI with a Model API key, or a persistent team workspace like AQ built on the same tmux pattern.
Why closing the lid kills the session (and its subagents)
When you run muse in a local terminal and the laptop sleeps, the process is suspended or loses its controlling terminal, and the default signal handling terminates whatever was attached to that shell. The same happens if you SSH into a server and run muse directly in that connection: a Wi-Fi handoff or a suspend takes the SSH session down with everything inside it. None of this is specific to Muse Code; the Claude Code and Codex versions of this guide walk the same failure for those harnesses.
Muse Code adds one wrinkle of scale: when it parallelizes, it fans work out to subagents in isolated git worktrees under .muse/worktrees/, each a child process on the same machine. Close the laptop and the whole tree stops together, main agent, workers, and reviewers alike; the worktrees stay on disk, but no commits land while you are away. If Meta's harness is new to you, our Muse Code explainer covers the architecture in full.
What the event log restores (and what it does not)
Muse Code has the strongest crash recovery in the mainstream harness field. Every model call, tool run, approval, and file edit is appended to a local event log, and Meta's documentation is explicit about what that buys as of September 2026: any session can be replayed exactly as it ran, and a run killed mid-task can be resumed with no duplicate side effects. Start muse again in the same project, resume the session, and it carries on from the last recorded step.
What the event log cannot do is execute while the process is dead. If the laptop closed at 11pm mid-refactor, resuming at 8am picks the task up cleanly, but the nine hours in between were spent, not worked. Resume is for crashes; keeping work moving overnight needs the process on hardware that stays awake. The two combine well: on an always-on machine, the event log turns even a host reboot into a resumable blip.
Option 1: A remote box with tmux
The baseline pattern needs no product at all: a Linux server you can SSH into, plus tmux. tmux keeps the session running whether or not any client is attached, so closing your laptop only kills the SSH client; muse and its subagent worktrees keep executing on the server.
# On the remote server, once:
ssh dev-box
curl -fsSL https://dev.meta.ai/install.sh | bash
# Start a named session and run Muse Code inside it
tmux new -s auth-fix
muse
# Detach: Ctrl-b then d. Close your laptop, go anywhere.
# Later, from any machine:
ssh dev-box
tmux attach -t auth-fixTwo Muse-specific setup notes. Sign-in: the first run normally authenticates through a browser with your Meta developer account, which a headless server does not have. Meta's documented route for non-interactive environments, as of September 2026, is a Model API key exported as the MODEL_API_KEY environment variable; use that, or complete the browser flow once from a machine that has one. Platform: Muse Code ships for macOS and Linux only, so a Linux VM is fully supported territory, and it sidesteps the missing Windows build entirely.
Reattaching drops you into the exact same scrollback, mid-conversation. The limits arrive with teammates and scale: sharing the session means sharing SSH access, two top-level sessions in one clone trample each other unless you split them into git worktrees (Muse Code isolates its own subagents, not sibling sessions), and nobody sees what the agent is doing without SSHing in themselves. If you are building the box from scratch, the self-hosted AI coding agent setup guide covers sizing, hardening, and CLI auth in order.
Option 2: Add mosh for connections that actually drop
tmux solves persistence on the server; it does nothing for the connection between you and the server. If you work from trains or a laptop that changes networks all day, add mosh: it replaces the SSH connection layer with a UDP protocol that survives IP changes and long suspends, reconnecting the moment your machine wakes. Run mosh to connect, tmux inside it, and both halves are covered. The constraint is that mosh needs UDP through the firewall; fall back to plain SSH where it is blocked.
Option 3: No first-party cloud, so unattended means CI or a server you own
Anthropic and OpenAI both ship a managed answer to this problem: Claude Code on the web runs sessions in Anthropic-managed VMs, and Codex cloud runs delegated tasks in OpenAI-managed containers. Meta has no equivalent for Muse Code as of September 2026: no hosted execution tier, no "muse cloud", and inter-session messaging (added at the September 1 general availability) is deliberately same-machine, so it does not make a session reachable from elsewhere either.
What Meta does position, in its own documentation, is Muse Code as an agent for the terminal and CI: with a Model API key, non-interactive runs work in pipelines, and the event log's deterministic replay can even serve as a merge-blocking CI check. Muse Code also supports scheduling agent work in natural language, but a schedule does not move execution anywhere: the run still fires on whatever machine muse lives on, so a sleeping laptop still means nothing happens. Genuinely unattended work means a server or CI runner you own, a Model API key, and tasks defined tightly enough to run without approvals. Work you want to watch and steer is Option 1.
The options at a glance
| Approach | Survives closing your laptop | Live terminal to step back into | Who runs the infrastructure |
|---|---|---|---|
| Event-log resume alone | No, recovers the session later | Resumed session, exact state, no lost work but no progress made | Your laptop |
| tmux on a remote box | Yes | Yes, exact scrollback | You |
| mosh + tmux | Yes, plus survives network changes | Yes | You |
| Non-interactive runs in CI | Yes, if the runner stays up | No, scripted run | You |
| A Meta-hosted cloud session | Does not exist as of September 2026 | n/a | n/a |
| AQ | Yes, persistent tmux on your team's VM | Yes, live and shared with teammates | You (Free) or AQ (Team) |
Which one to actually use
One person who wants the session back exactly as it was left: tmux on a small Linux VM, with mosh if your network is unreliable, and the event log as a free safety net underneath. Recurring, well-defined tasks: non-interactive runs on a server or in CI with a Model API key. What no assembly of these gives you is the missing managed tier: a persistent Muse Code session that survives everything, reachable from a browser, that a teammate can also open. That is the gap the whole keep-it-running category keeps hitting, and always-on coding agents covers the vendor-neutral patterns across every harness.
Where AQ fits
AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. In this guide's terms, AQ is Option 1 turned into a team product, and the closest thing Muse Code has to the cloud tier Meta does not ship. An AQ workspace is a real Linux terminal in a persistent tmux session on your team's VM, and a plain shell there runs any Linux CLI, Muse Code included: install it on the VM, sign in with your own Meta account, and run muse exactly as on your own machine. The session survives a closed laptop, resumes from any device, and streams live to the browser, where a teammate can open the same workspace and watch the same session; if the owner approves a control request in one click, the teammate can type into it too.
The worktree layers stack rather than fight: AQ gives every workspace its own isolated git worktree on a branch like ai/1234-fix-auth, so two Muse Code sessions in two workspaces never collide, while inside a workspace Muse Code fans its subagents into its own .muse/worktrees/ untouched. Commits and pull requests go out under per-user GitHub auth and are tracked against the workspace, and workspace visibility is owner-managed: team-visible, or private and shared with specific people. The Free plan is a personal sandbox for one person, created by AQ on a private machine in an isolated network with nothing to install and no time limit. The Team plan ($50 per user per month early access, standard $200, billed monthly) covers VMs you connect from your own cloud or a dedicated always-on AQ-managed VM in its own isolated network, with the rate locked for your first 12 months.
Plainly: if you are one engineer evaluating Meta's harness, tmux on a box you already have is enough, and you should use it. AQ earns its place when you want Muse Code running overnight on a machine your whole team can open from a browser, without anyone owning SSH keys or waiting on Meta to ship a cloud.
Frequently asked questions
Does Muse Code's event log continue the work that was running when my laptop closed?
No. The event log makes the session recoverable, not persistent: Meta documents that a killed run can be resumed with no duplicate side effects, replaying exactly to the last recorded step, as of September 2026. But the process itself stopped when the laptop slept, so nothing executed in the meantime. Resume recovers state; keeping work moving requires running muse on a machine that stays awake, such as a VM with tmux.
Does Muse Code have a cloud option like Codex cloud or Claude Code on the web?
Not as of September 2026. Meta ships no hosted execution for Muse Code: the muse binary runs on your machine (model inference is hosted, but the agent process is local), and there is no managed tier that keeps a session running after you disconnect. The unattended routes Meta documents are non-interactive runs with a Model API key, suited to CI and servers you own. For a persistent interactive session, run muse inside tmux on a VM, or in a persistent workspace platform like AQ.
How do I sign in to Muse Code on a headless server?
Muse Code's default first-run authentication goes through a browser with your Meta developer account, which a headless box does not have. As of September 2026, Meta's documented route for non-interactive environments is a Model API key exported as the MODEL_API_KEY environment variable. Alternatively, complete the browser sign-in once from a machine with a display and use the cached credentials on the server, checking Meta's current docs for the supported flow.
What happens to Muse Code's subagents and their worktrees when the laptop sleeps?
They stop with everything else: subagents are child processes on the same machine, so a sleeping host suspends the entire tree, main agent and workers alike. Their git worktrees under .muse/worktrees/ and any commits already made stay safely on disk, and the event log lets the session resume cleanly when you return. But no new work happens while the machine sleeps, which is exactly why long fan-out runs belong on an always-on VM.
What is the simplest way to keep Muse Code sessions running for a whole team?
The manual version is a shared Linux VM with tmux, but then everyone needs SSH access to one box and has to know which session to attach to. AQ wraps the same pattern into a product: each workspace runs its CLI (Muse Code included, as a plain Linux binary) in a persistent tmux session on your team's VM, streamed to the browser, so teammates open the workspace to see the live session instead of sharing SSH credentials, and sessions survive closed laptops by construction.