How to Keep Claude Code Running After You Close Your Laptop

Updated August 26, 2026 · first published July 18, 2026 · by the AQ team

Closing your laptop kills a Claude Code session unless that session runs somewhere other than your laptop. The fix is not a setting inside Claude Code itself: move the process onto a machine that never sleeps (a remote server, kept alive in a persistent terminal with tmux or screen), or use a cloud-native option built for the same purpose, like Claude Code on the web, Claude Code Routines, Cursor cloud agents, or a persistent team workspace like AQ. Which one is right depends on whether you want an interactive terminal to reattach to, or a fire-and-forget task that reports back when done. Every vendor claim below was re-verified on the vendor's own documentation in August 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, and if Codex is your daily driver, the Codex version of this guide covers its specifics.

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 now has a first-party answer to this exact problem. Claude Code on the web (in research preview for Pro, Max, and Team plans as of August 2026, with Enterprise access via premium seats) runs each session in an isolated VM on Anthropic-managed infrastructure: you start a task at claude.ai/code or from your own terminal with the claude --cloud flag, and the session keeps working after you close the browser or the laptop. You can watch and steer it from the Claude mobile app (more patterns for that in running Claude Code from your phone), run several sessions in parallel, 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, and repository cloning and PR creation require GitHub. Team and Enterprise organizations can route these sessions to a self-hosted environment on their own servers (public beta as of August 2026).

Two honest caveats for the keep-it-running use case: an idle cloud session eventually expires and its VM is reclaimed (reopening the session restores the conversation history on a fresh VM), 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, also in research preview as of August 2026: 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, Claude Code on the web 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 Team 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.