# How to Run Cursor CLI on a Cloud VM

> Provision a small Linux VM, install Cursor CLI with one command, sign in headlessly with NO_OPEN_BROWSER or an API key, and keep agent sessions alive with tmux.

Published October 23, 2026 · by the AQ team · Canonical: https://aq.dev/guides/run-cursor-cli-on-a-cloud-vm/

Running Cursor CLI on a cloud VM takes about fifteen minutes: provision a small Linux server, install the CLI with Cursor's one-line installer, sign in once using the no-browser login flow or an API key, and run every session inside tmux so it survives disconnects. The payoff is a Cursor agent that keeps executing after your laptop lid closes and that you can reattach to from any device. Every Cursor detail here is checked against Cursor's own documentation as of October 2026. This is the Cursor twin of our [Claude Code cloud VM guide](https://aq.dev/guides/run-claude-code-on-a-cloud-vm/) and [Codex cloud VM guide](https://aq.dev/guides/run-codex-on-a-cloud-vm/); the three setups differ mainly in how sign-in works on a headless box.

## Why put Cursor CLI on a server at all

On a laptop, a Cursor CLI session dies with your terminal: close the lid mid-refactor and the process is gone. The CLI softens the loss because conversations are saved with IDs, and agent resume, agent ls, and agent --resume with a chat ID bring a conversation back. But resume is recovery, not persistence: it reloads the transcript so the model regains its context, and nothing executed while the laptop slept. On a VM the process runs on hardware that never sleeps, you check on it from any machine by reattaching, an agent running with --force or a relaxed sandbox is confined to a disposable box instead of the machine holding your password manager, and your credentials and repository clones get a stable home independent of any laptop. The fuller decision tree, Cloud Agents included, is in [keeping Cursor CLI running after closing your laptop](https://aq.dev/guides/keep-cursor-cli-running-after-closing-laptop/); this page is the build-the-box half.

## Step 1: Provision the VM

Cursor does not publish minimum hardware specs for the CLI, so size for what runs next to the agent rather than for the agent itself: 2 vCPUs and 4 GB of RAM handle the CLI plus a light toolchain comfortably, while heavy npm or cargo builds and a running dev server make 8 GB the safer floor. Any current Ubuntu LTS image works; the installer supports macOS, Linux, and Windows through WSL, and native Windows via PowerShell. On a 4 GB machine, add swap so a hungry build gets slow instead of killed:

```
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
```

Any provider works. As of October 2026, entry shared vCPU plans with those specs run under 5 euros per month at European budget providers like Hetzner (after its April 2026 repricing), while comparable basic droplets at the larger US clouds list from the mid 20s of dollars per month depending on CPU class. Prices move; check the provider's page before committing.

## Step 2: Ten minutes of hardening

An always-on box that will hold your Cursor and GitHub credentials deserves basic hygiene before any agent touches it:

```
# As root, once
adduser dev
usermod -aG sudo dev

# Firewall: SSH only
ufw allow OpenSSH
ufw enable

# Keys only: in /etc/ssh/sshd_config set
#   PasswordAuthentication no
#   PermitRootLogin no
# then restart sshd

# Security patches apply themselves
apt install -y unattended-upgrades
```

Two optional upgrades: a mesh VPN such as Tailscale takes SSH off the public internet entirely, and mosh keeps your interactive connection responsive on flaky networks, though with tmux in the loop a dropped connection costs you nothing anyway. The [self-hosted AI coding agent setup guide](https://aq.dev/guides/self-hosted-ai-coding-agent-setup/) covers the hardening end in more depth.

## Step 3: Install Cursor CLI

Install the basics, then the CLI itself. As of October 2026 the documented installer is one line and needs no Node.js:

```
sudo apt update && sudo apt install -y git tmux
curl https://cursor.com/install -fsS | bash
```

The binary lands in ~/.local/bin, so add that to your PATH if the installer has not already (echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc, then source ~/.bashrc). Confirm with agent --version. One naming note: Cursor's docs now spell the command agent everywhere, and cursor-agent remains as a backward-compatible alias after the January 2026 rename, which matters on a shared box where another tool may own the agent name. The CLI tries to keep itself current automatically; agent update forces a manual update.

## Step 4: Sign in on a headless box

The default sign-in, agent login, wants to open a browser on the machine running the command, which a headless VM cannot do. As of October 2026, Cursor's authentication docs give two ways through:

**The no-browser login.** Prefix the login with NO_OPEN_BROWSER=1 and the CLI prints the login URL instead of opening anything:

```
NO_OPEN_BROWSER=1 agent login
```

Open the printed URL in the browser on your laptop or phone and complete the sign-in with your Cursor account. Check the result on the VM with agent status, which shows whether you are authenticated and as whom. Credentials are stored locally on the VM, so the login persists across reboots, and agent logout clears it.

**An API key.** For scripts, CI, or any box where the browser handoff is awkward, generate a user API key in the Cursor dashboard under API Keys and export it as an environment variable:

```
export CURSOR_API_KEY=your_api_key_here
agent -p "summarize this repository"
```

The docs also support an --api-key flag, but the environment variable is the better habit: a flag value lands in shell history and process lists. Treat the key as a password-equivalent secret, and keep it out of the repository and out of prompts.

## Step 5: Run every session inside tmux

This is the step that makes the setup worth it. A Cursor agent launched in a bare SSH session dies when the connection drops; inside tmux, the session belongs to the server, not to your connection:

```
# Start a named session per task
tmux new -s payments-refactor
agent

# Detach: press Ctrl-b, then d. Close the laptop. Later, from anywhere:
ssh dev@your-vm
tmux attach -t payments-refactor

# See what is running
tmux ls
```

Reattaching drops you into the exact scrollback, mid-conversation, with the agent still working or waiting for input. Name sessions after tasks, not the tool: when you run two or three agents at once, tmux ls should read like a to-do list. Two warnings. tmux state lives in memory, so a VM reboot clears every session (agent resume recovers the conversations, but not work in flight); anything worth keeping gets committed and pushed. And if you run several agents in one repository, give each its own [git worktree](https://aq.dev/guides/git-worktrees-for-ai-coding-agents/) so they do not fight over the checkout.

Worth knowing inside the session: Shift+Tab or /plan switches to Plan mode (design before coding), /ask gives a read-only mode, /model picks the model, and /sandbox (or --sandbox enabled) controls whether commands run with restricted network access. When a command needs sudo, the CLI shows a masked password prompt and passes the password straight to sudo without the model ever seeing it.

## When a Cloud Agent or print mode is the better answer

Your own VM is not the only way to outlive a laptop. Prepending & to any message hands the conversation to a Cloud Agent, Cursor's managed environment: the task keeps running on a Cursor-managed VM and you follow it at cursor.com/agents, typically getting a draft pull request back. It is the least setup for fire-and-forget work, but there is no live terminal to step into mid-run, and it executes on Cursor's infrastructure rather than inside your network where your staging database and private registries are reachable; the full comparison is in [AQ vs Cursor Cloud Agents](https://aq.dev/compare/aq-vs-cursor-cloud-agents/). And for scripted, recurring jobs on the VM you just built, print mode runs a task non-interactively: agent -p with --force to actually apply file changes (without it, print mode only proposes them) and --output-format json or stream-json for output that scripts and jq can parse. That fits nightly triage and CI; it is the wrong shape for exploratory work you want to steer.

## What this actually costs

The VM is the only new line item. Your Cursor usage is billed exactly as before, through the Cursor plan or API key you signed in with; running on a server changes nothing about model pricing.

## Where a hand-rolled box runs out of road

For one engineer, this setup is genuinely good, and you should run it. The friction appears at the edges. Sharing a live session with a teammate means sharing SSH access to the box, which most teams rightly refuse to do. Parallel tasks need per-task worktrees you script yourself. Nobody sees what the agents are doing without logging in and attaching. And each teammate who wants this repeats the whole ritual, login flow included, on a box of their own.

## 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. It is this guide's setup, operated as a product. Cursor Agent runs as the real CLI (alongside Claude Code, Codex, Kimi, Grok, or plain shells) in persistent tmux sessions on your team's VM, streamed live to the browser: sessions survive a closed laptop and resume from any device, and a teammate can open the same workspace and watch the same live session instead of asking for SSH keys; if the owner approves a control request, the teammate can type into it too. You sign into Cursor with your own account, and AQ never marks up usage on your own subscriptions.

The glue you would otherwise script is built in: every workspace gets an isolated git worktree on a branch named ai/{id}-{slug} with dependencies installed automatically and a one-click rebase onto main, commits and PRs go out under per-user GitHub auth and are tracked per workspace, and each workspace can run a live dev-server preview with shareable links, where comments pinned on the preview can be sent to the agent as prompts. Teams that plan in Linear can label an issue ai-task and a workspace appears with status syncing both ways. 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.

Pricing is two plans. The Free plan is a personal sandbox for one person: AQ creates a private machine in an isolated network with nothing to install and no time limit, so you skip this guide's setup entirely. Connecting a VM you own, exactly like the one this guide builds, is part of the AQ Pro plan at $50 per user per month (early access; standard $200, billed monthly), which also covers a dedicated always-on AQ-managed VM in its own isolated network, with your rate locked for your first 12 months. Solo and comfortable in tmux? Keep the hand-rolled box. AQ earns its place when the second engineer wants in.

## Frequently asked questions

### How do I log in to Cursor CLI on a server with no browser?

Two documented ways as of October 2026. Run NO_OPEN_BROWSER=1 agent login on the server: the CLI prints the login URL instead of opening a browser, and you complete the sign-in from the browser on your laptop or phone, then confirm with agent status. Or generate a user API key in the Cursor dashboard under API Keys and export it as CURSOR_API_KEY on the server, which is also the right route for scripts and CI.

### Does Cursor CLI keep working after I close my laptop?

Only if the process runs somewhere that never sleeps. On a VM, launch agent inside a named tmux session and detach; the agent keeps executing no matter what your laptop does, and you reattach later from any machine. agent resume alone does not do this: it reopens a saved conversation with its context, but the process died when your laptop slept, so nothing ran in the meantime. tmux is the persistence; resume is the fallback.

### How big a VM does Cursor CLI need?

Cursor does not publish minimum hardware specs for the CLI, so size for the work around the agent: 2 vCPUs and 4 GB of RAM run the CLI plus a light toolchain, and heavy builds or a running dev server make 8 GB the comfortable choice. On smaller boxes, add a swap file so builds degrade gracefully instead of getting killed. Any current Ubuntu LTS works; the installer covers macOS, Linux, and Windows via WSL, plus native Windows through PowerShell.

### Should I use a Cloud Agent instead of my own VM?

For fire-and-forget tasks, yes: prepend & to a message and the conversation moves to a Cloud Agent on a Cursor-managed VM, which keeps running whatever your laptop does and typically returns a draft pull request you review at cursor.com/agents. A VM of your own earns its keep when you want a live, steerable terminal to step back into, execution inside your own network where staging databases and private registries are reachable, and a box whose lifecycle and credentials you control. Many developers use both.

### Can I run Cursor CLI non-interactively on the server, for cron jobs or CI?

Yes. Print mode (agent -p) runs a single prompt without the interactive UI and exits. By default it only proposes file changes; add --force to apply them, and --output-format json or stream-json to get output a script can parse (Cursor's docs show piping the json result through jq). Authenticate with the CURSOR_API_KEY environment variable rather than a browser login, and the server can run reviews, triage, or batch edits on a schedule with no laptop involved.

---

About AQ: 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. Start at [aq.dev](https://aq.dev/).