How to Keep Claude Code Running After You Close Your Laptop

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 feature built for the same purpose, like Claude Code Routines, Cursor Background 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.

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.

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

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.

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 the terminal, run it as a cloud task

As of July 2026, Anthropic offers Claude Code Routines (in research preview): a saved prompt, repositories, and connectors, packaged to run automatically on Anthropic-managed cloud infrastructure rather than your machine. A routine fires on a schedule, a GitHub event, or an HTTP call to a per-routine API endpoint, and each fire spins up a full Claude Code 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.

This is the right tool when the task is genuinely unattended (nightly backlog triage, a PR-triggered review, a smoke test after a deploy). It is the wrong tool if you want an interactive session to jump into and redirect: routines are one-shot runs, not a standing terminal you reattach to, and during the research preview they carry a daily run cap 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 Background Agents (and the more capable Cloud Agents) run your task in an isolated cloud VM with its own terminal, cloning your repo and opening a PR whether or not you stay connected, as of July 2026. GitHub Codespaces keeps a background process running too, but only until its idle timeout (5 to 240 minutes, default 30) elapses with no terminal activity; 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.

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 the task is well-defined and truly unattended, a routine or a cloud background-agent product removes the server entirely, at the cost of a terminal to step into mid-run. The gap between the two is a team wanting the first pattern, a real, reattachable terminal, 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, 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.

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 your VM, with runner health visible in the product and an aq-runner doctor command for diagnosing a broken host. The Free plan is the full product on a VM you bring, paying only your cloud provider; the Team plan ($100 per user per month promotional, standard $200, billed monthly) adds a dedicated, always-on VM that AQ manages in its own isolated network, 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.