How to Keep Cursor CLI Running After You Close Your Laptop

Published September 19, 2026 · by the AQ team

Closing your laptop kills a Cursor CLI session that is running on the laptop itself, and agent resume does not undo that: it reopens the saved conversation, not the interrupted work. To keep a Cursor agent executing while the lid is shut you have to run it somewhere that never sleeps. There are two practical shapes: keep an interactive session alive on a remote machine with tmux, or hand the conversation to a Cloud Agent, Cursor's managed environment that keeps working on its own VM and comes back with a pull request. Which one fits depends on whether you want a live terminal to step back into, or a finished result to review.

Why closing the lid kills the session

When you run agent in a local terminal and the laptop sleeps, the process loses its controlling terminal and is stopped or killed with everything else attached to that shell. The same applies if you SSH into a server and run the CLI directly in that connection: a dropped Wi-Fi handoff, a VPN reset, or a suspend takes the SSH session down, and the default SIGHUP handling terminates whatever it was running. None of this is specific to Cursor: it is how terminals treat any long-running CLI, which is why persistent remote sessions are a recurring feature request on Cursor's own forum.

One naming note first: as of September 2026, agent is the primary entrypoint for Cursor CLI (installed with curl https://cursor.com/install -fsS | bash), and cursor-agent remains as a backward-compatible alias after the January 2026 rename. Everything here applies to both spellings.

What agent resume actually restores (and what it does not)

Cursor CLI saves every session with an ID, and as of September 2026 there are several ways to get a conversation back: agent resume or agent --continue reopens the most recent one, agent ls lists previous chats so you can pick one, agent --resume with a chat ID jumps to a specific thread, and the /resume slash command (Ctrl+Y) opens the same picker inside a running session. Resume works across workspaces from any directory.

What resume cannot do is finish work that was interrupted. If the agent was halfway through a refactor when the laptop slept, the process died at that point; resuming reloads the transcript so the model regains its context, and you can tell it to continue, but the hours in between were spent, not worked. Resume is recovery, not persistence. For persistence, the process has to outlive your laptop.

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 on the server whether or not any client is attached, so closing your laptop only kills the SSH client; the Cursor agent inside keeps executing.

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

# Start a named session and run Cursor CLI inside it
tmux new -s auth-fix
agent

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

Reattaching drops you into the exact same scrollback, mid-conversation, with the agent still working or waiting for input. This costs only the VM and works identically for Cursor CLI, Claude Code, Codex, or a plain shell. If you are building the box from scratch, the self-hosted AI coding agent setup guide covers VM sizing, hardening, and headless CLI auth in order.

Two caveats. Some users report the CLI's terminal UI redraws roughly over high-latency SSH links, so a distant VM can feel choppy even though the work itself is fine. And the limits arrive with teammates and scale: sharing a session means sharing SSH access, two tasks in one checkout trample each other unless you split them into git worktrees, and nobody sees what an agent is doing without SSHing in themselves.

Option 2: Add mosh for connections that actually drop

tmux solves persistence on the server; it does not make your connection to the server any better. 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 you have both halves. The one constraint is that mosh needs UDP through the firewall; fall back to plain SSH where it is blocked.

Option 3: Hand the conversation to a Cloud Agent

Cursor's first-party answer is built into the CLI itself. As of September 2026, prepending & to any message mid-conversation pushes that conversation to a Cloud Agent: the task keeps running on a Cursor-managed VM regardless of what your laptop does, and you pick it back up on the web or mobile at cursor.com/agents. Cloud Agents run in isolated VMs with full development environments, clone your repository, work on their own branch, and push a draft pull request for review, attaching artifacts like screenshots and logs. You can also move an agent back from cloud to local to iterate, then send it up again.

The tradeoff is the shape of the work. A Cloud Agent is delegation: it runs to a result on Cursor's infrastructure, not a standing terminal you step back into, and the VM is Cursor's environment rather than a machine inside your network with your staging database and private registries reachable. The full comparison is in AQ vs Cursor Cloud Agents.

Option 4: Headless runs with print mode

For automation on infrastructure you already own, Cursor CLI has a non-interactive mode: agent -p runs a prompt without the interactive UI, with --force to allow file changes and --output-format json for output that scripts can parse. Cursor documents this pattern for GitHub Actions and other CI systems. Run it on a server on a schedule and laptop lifetime stops mattering because your laptop was never involved. It fits recurring jobs like nightly triage; it is the wrong shape for exploratory work you want to steer.

The options at a glance

Which one to actually use

One person, well-defined tasks, happy to review pull requests: the & handoff to a Cloud Agent is the least setup. One person who wants the actual session back the way it was left: tmux on a small VM, with mosh if your network is unreliable. Recurring unattended jobs: agent -p under CI. The gap opens when a team wants the tmux pattern, real reattachable terminals that survive everything, without sharing SSH keys to one box. The same fork exists for the other CLIs, covered in keeping Claude Code running and keeping Codex running after closing your laptop.

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. Cursor Agent runs as the real CLI (alongside Claude Code, Codex, Kimi, Grok, or plain shells) in a persistent tmux session on your team's VM, so the session survives a closed laptop and resumes from any device, streamed live to the browser where a teammate can open the same workspace and watch the same session; if the owner approves a control request, the teammate can type into it too.

Each workspace gets its own isolated git worktree so parallel sessions never collide, you log into Cursor with your own account (AQ never marks up usage on your own subscriptions), and commits and pull requests go out under per-user GitHub auth, tracked against the workspace. There is no shared multi-tenant execution tier: your agents run on your team's machine, 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 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, the Cloud Agent handoff or tmux on a box you already have is enough, and you should use it. AQ earns its place when a team wants those persistent sessions shared and visible from a browser without anyone owning the SSH keys.