How to Keep Claude Code Running After You Close Your Laptop

Updated September 24, 2026 · first published July 18, 2026 · by the AQ team

To keep Claude Code running after you close your laptop, run it somewhere other than the laptop: inside tmux on a remote server you SSH into (start a named session, run claude, detach, reattach later from any machine), or as a Claude Code cloud session started with claude --cloud or from claude.ai/code, which runs on Anthropic-managed infrastructure and keeps working when the lid closes. Closing the laptop only kills processes that live on the laptop itself; a session running on a server or a cloud VM continues, and you reattach or reopen it from any device. This guide walks through every current option (tmux and mosh on your own VM, VS Code Remote Tunnels, Claude Code cloud sessions and Routines, managed cloud agent products, and a persistent team workspace like AQ), with each vendor claim re-verified on the vendor's own documentation as of September 2026.

Why closing the lid kills the session

When you run claude in a local terminal and close your laptop (or it sleeps), the process loses its controlling terminal. On most systems that sends SIGHUP to the foreground process, whose default handler is to terminate. An SSH connection that drops for any reason (Wi-Fi handoff, VPN reset, a laptop suspending mid-session) takes every process attached to that shell down with it too. None of this is specific to Claude Code: it is true of any long-running CLI run directly in a terminal. If another agent is your daily driver, this guide has twins for Codex, Cursor CLI, and Muse Code.

Two different fixes apply here. One keeps a terminal session alive independent of your connection to it, so you can reattach later and see everything that happened. The other skips the terminal entirely and runs the task as a managed cloud job that reports results when finished. Pick based on whether you need to watch and steer the agent interactively, or just need the outcome.

Option 1: A remote box with tmux or screen

The baseline pattern needs no special product: a Linux server you can SSH into, plus a terminal multiplexer. tmux is the standard choice in 2026, actively developed with a large plugin ecosystem (tmux-resurrect even restores sessions across a host reboot). GNU Screen still works and ships preinstalled on more locked-down systems, but its development has been largely dormant, so reach for it only if you cannot install anything else.

# On the remote server, once:
ssh dev-box

# Start a named session and run Claude Code inside it
tmux new -s auth-fix
claude

# Detach: Ctrl-b then d. Close your laptop, go anywhere.
# Later, from any machine:
ssh dev-box
tmux attach -t auth-fix

Building this box from scratch? Running Claude Code on a cloud VM walks the Claude-specific path (provider choice, install, headless login), and the self-hosted AI coding agent setup guide covers VM sizing, hardening, and CLI auth in order.

tmux itself keeps running on the remote host regardless of whether any client is attached. Closing your laptop only kills the SSH client; the shell and everything inside it, including Claude Code, keeps executing on the server. Reattaching drops you back into the exact same scrollback, mid-conversation, mid-command.

If you want this pattern purpose-built for agents instead of assembled by hand, Herdr (herdr.dev) has become the community default in 2026: an open source Rust terminal multiplexer that runs Claude Code and a dozen other agent CLIs in tmux-style panes, shows at a glance which agent is working, blocked, or done, keeps sessions alive when your laptop closes, and attaches over SSH from any device, including a phone. It is open source, ships as a single small binary, and as of August 2026 remains one of the fastest-growing tools in the space. It gives you everything in this option with less ceremony, and it shares the option's limit: the moment a second person needs to see or steer the session, a terminal on one box has no answer.

This works with any CLI agent (Claude Code, Codex, or a plain shell) and costs nothing beyond the VM. The limits show up with scale: sharing the session means sharing SSH access, two unrelated tasks in one checkout trample each other's edits unless split into separate git worktrees, and nobody can see what the agent is doing without SSHing in and attaching themselves.

Option 2: Add mosh for connections that actually drop

tmux solves persistence; it does not solve a bad network. If the SSH connection itself times out or resets (switching Wi-Fi networks, a flaky hotel connection, a laptop resuming on a different IP), the client-server handshake restarts from scratch, and tmux only helps once you are back inside the session. Mosh (mobile shell) replaces the connection layer with a UDP-based protocol built to survive IP changes and high latency, resuming the moment your device reconnects instead of requiring a fresh login. Run mosh to connect, then tmux inside it, for both: a connection that survives network changes, and a session that survives disconnecting entirely. The one real constraint is that mosh needs UDP to get through, so it fails behind firewalls or VPNs that block it; fall back to plain SSH there.

Option 3: VS Code Remote Tunnels, if you live in the editor

If your workflow is editor-centric rather than terminal-centric, VS Code's Remote Tunnels feature gets you a persistent connection to a remote machine without an SSH server at all: you authenticate the same GitHub or Microsoft account on both ends, and VS Code brokers the connection. That helps when SSH access is restricted. The tradeoff is the inverse of tmux: the tunnel keeps your editor connected, but if the remote machine sleeps, reboots, or the tunnel service stops, the session is gone until you bring it back manually. Long-running agent processes still need a persistent shell (tmux again) on that machine; the tunnel only solves how your editor reaches it.

Option 4: Skip your own server, run it in Anthropic's cloud

Anthropic's first-party answer to this exact problem is a cloud session, previously called Claude Code on the web. Cloud sessions are out of research preview and available on Pro, Max, and Team plans (Enterprise via premium seats or Chat plus Claude Code seats), as of September 2026. Each session runs in an isolated VM on Anthropic-managed infrastructure, started from the browser at claude.ai/code, the Code tab of the Claude mobile app, the desktop app, or your terminal with the claude --cloud flag, and it keeps working after you close the browser or the laptop. You can watch and steer it from any device (more patterns in running Claude Code from your phone), run several sessions in parallel (a Claude Code project coordinates parallel cloud sessions from one conversation, as of September 2026), and later pull any session down into a local terminal with claude --teleport. Cloud sessions share rate limits with your other Claude usage rather than billing separate compute, repository cloning and PR creation require GitHub, and Team and Enterprise organizations can route sessions to a self-hosted environment on their own servers.

Two honest caveats for the keep-it-running use case: an idle cloud session eventually stops and its VM is reclaimed (Anthropic's docs call this environment expiry; reopening the session restores the conversation history on a fresh VM, though background work such as shell commands that were still running is not restored), and the session runs Claude Code only, not a general terminal where Codex or a build server can live alongside it.

Claude Code Routines are the unattended flavor, still in research preview as of September 2026 and available on Pro, Max, Team, and Enterprise plans: a saved prompt, repositories, and connectors, packaged to run automatically. A routine fires on a schedule, a GitHub event, or an HTTP call to a per-routine API endpoint, and each fire starts a fresh cloud session that clones the repo, does the work, and pushes to a claude/-prefixed branch. There is no permission-mode picker and no approval prompts mid-run, so the prompt must be fully self-contained about what "done" looks like. Routines fit genuinely unattended work (nightly backlog triage, a PR-triggered review, a smoke test after a deploy) and not a standing session you steer: each trigger is a one-shot run, and routines carry a daily cap on runs per account.

Option 5: A managed cloud agent product

Several vendors package "keeps running when you close your laptop" as a product feature. Cursor's cloud agents (the feature formerly called Background Agents) each run in an isolated cloud VM with a full development environment, cloning your repo, working on their own branch, and opening a PR whether or not you stay online, startable and checkable from the editor, the web, an iOS app, or Slack, as of August 2026. GitHub Codespaces keeps a background process running too, but only until its idle timeout (5 to 240 minutes, default 30) elapses with no user activity, as of August 2026; closing the tab or sleeping your laptop does not reset that timer, so it is unreliable for hours-long unattended runs. Warp's Remote Control instead publishes an already-running local agent session (Claude Code, Codex, or another CLI) to the cloud so you can monitor and steer it from a phone or browser, rather than moving execution to a new VM, as of July 2026.

Which one to actually use

If you are one person and want the exact session back the way you left it, tmux (with mosh on unreliable networks) on a small VM is the whole answer, costing only the VM. If you want Claude Code specifically with no server to own, a Claude Code cloud session is the shortest path, with the expiry and Claude-only caveats above. If the task is well-defined and truly unattended, a routine or a cloud-agent product removes the terminal entirely, reporting back with a PR. The gap all of these leave is a team wanting the first pattern, a real, reattachable terminal running any CLI, without anyone running their own VM or SSHing into a shared box to watch.

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 (tmux on a remote box) built into a team product. Agents run as real CLIs (Claude Code, Codex, Cursor Agent, Kimi, Grok, Antigravity CLI, or plain shells) in persistent tmux sessions on your team's own VM, so a session survives closing your laptop and resumes from any device, streamed live to the browser so a teammate can open the same workspace and steer the exact same session rather than SSHing in themselves. That shared live session, not just a persistent one, is the heart of multiplayer coding agents.

Each workspace gets its own isolated git worktree so parallel sessions never collide, each engineer authenticates the CLIs with their own account, and commits and PRs go out under per-user GitHub auth, tracked against the workspace. There is no shared multi-tenant execution tier: your agents run on a machine dedicated to your team, with runner health visible in the product and an aq-runner doctor command for diagnosing a broken host. The Free plan is a personal sandbox AQ creates for you; the AQ Pro plan ($50 per user per month promotional, standard $200, billed monthly) adds your whole team, VMs you bring from your own cloud, and a dedicated always-on AQ-managed machine, rate locked for your first 12 months.

Plainly: if tmux on a box you already have is enough, use it, that is what this guide is for. AQ is worth it once you want that same persistence shared across a team, visible from a browser, without anyone owning the SSH keys.