.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Close the laptop lid mid-refactor and the agent dies with it. That's the entire case for moving Claude Code onto a server: a long-running session on a VPS keeps working through your commute, your flaky hotel Wi-Fi and your machine going to sleep, and it sits on a datacenter connection that doesn't blink. The official docs quietly assume you're on a laptop, so this guide fills the gap with the setup I run on an Ubuntu 24.04 VPS: headless login, tmux for survivable sessions and scheduled headless jobs.
A server install also changes what the tool is for. On a laptop, Claude Code is an assistant you sit with. On an always-on box it becomes something closer to CI: kick off a chunky task over SSH, disconnect, come back to a finished branch. Both modes are worth having.
Provision the server
Any small VPS clears the bar. Claude Code needs 4 GB of RAM and no GPU, since inference happens on Anthropic's side; size the box for your project's builds and tests, not for the agent. I use Ubuntu 24.04, a non-root user with sudo and SSH keys before anything else touches the machine, and the walkthrough in the Ubuntu 26.04 LTS VPS setup guide applies unchanged to 24.04 if you want the full hardening pass. Do the non-root user part regardless; it matters later in this article for permission reasons on top of the usual security argument.
If you'd rather not assemble this yourself, LumaDock's Claude Code VPS hosting deploys Ubuntu with the CLI preinstalled on NVMe hardware via a one-click template, so a working agent box is live minutes after checkout.
Install Claude Code over SSH
SSH in as your regular user and run the native installer:
curl -fsSL https://claude.ai/install.sh | bash
export PATH="$HOME/.local/bin:$PATH"
claude --versionThe PATH export covers the current session; add it to ~/.bashrc to make it stick. The native installer is the right pick on a server specifically because it auto-updates in the background, and an unattended box is the last place you want a stale binary. Alternatives (npm, the apt repo) and the reasoning between them are covered in installing Claude Code on Ubuntu, so I won't repeat them here.
Log in without a browser
Run claude in a project directory and pick the subscription login. Since there's no browser on the server, the OAuth screen offers a copy option: press c, open the copied URL in the browser on your own machine, authorize and paste the returned code back into the SSH session. Done once per server; the credential persists on disk afterward.
Long-lived tokens with claude setup-token
For non-interactive use (cron jobs, CI runners, a box several people script against), the interactive OAuth flow doesn't fit. Run claude setup-token on any machine where you're logged in and it mints a long-lived token you can set as CLAUDE_CODE_OAUTH_TOKEN in the environment of your scripted jobs. The precedence order between this token, API keys and subscription login is documented on the authentication page, and it's worth a skim, because a stray ANTHROPIC_API_KEY in a server's environment silently rebilling your Console account is a classic.
Keep sessions alive with tmux
Here's the part that makes a server install worth it. An SSH connection that drops takes its foreground processes with it, so a bare claude session dies with your connection. tmux detaches the session from the connection entirely:
sudo apt install tmux
tmux new -s claudeInside that tmux window, start Claude Code and hand it something long ("migrate the test suite from mocha to vitest, run everything, fix what breaks"). Now detach with Ctrl+b followed by d, close your laptop and leave. The agent keeps working on the server. From anywhere, later:
tmux attach -t claudeYou're looking at the live session exactly where it is, mid-thought included. tmux ls lists sessions if you forget what you named things (I always do). Two habits from my own setup: one tmux session per project rather than one giant one, and a second tmux window with htop and logs, since a test suite the agent is running can eat a small VPS's CPU and it's better to see that than guess.
Resume after an SSH drop
Skipped tmux and lost the connection anyway? The conversation isn't gone. Session history lives on the server's disk per project, so reconnect and run:
cd ~/projects/my-app
claude --continueThat reopens the latest session in that directory with full history; claude --resume shows a picker when there are several. The in-flight action at the moment of disconnect is lost, the context isn't, and in practice you restate the last instruction and carry on. Forking, renaming and exporting transcripts are covered in the deeper guide to Claude Code sessions. Sessions survive server reboots too, for the same on-disk reason.
Run headless jobs with claude -p
Interactive sessions are half the story. The other half is print mode, where Claude Code runs one prompt to completion and exits, which turns the VPS into a scheduled agent:
claude -p "review yesterday's entries in logs/app.log and summarize new error patterns" \
--output-format jsonThe JSON output pipes cleanly into whatever consumes the result, exit codes are 0 on success and 1 on failure for scripting, and --output-format stream-json exists when you want events as they happen. Since nobody is present to answer permission prompts, headless runs need permissions decided in advance, either through allowed-tools rules in settings or a permission mode set on the command line. Flags like --bare, which skips hooks, skills and MCP discovery for fast isolated runs, are all in the CLI reference. Drop a line like this in cron and you've got a nightly reviewer that never asks for a standup. If your scripting around claude -p starts growing parsers and retry logic, that's the sign you've outgrown print mode; the library route is covered in the Claude Code SDK guide.
Skip permission prompts on a disposable box
Servers are where --dangerously-skip-permissions gets tempting, because approving prompts defeats the point of walking away. My rule: it's reasonable only on a disposable box, one with no production credentials, no customer data and nothing you'd mourn, and unreasonable everywhere else. The flag refuses to run as root or under sudo unless it detects a container or VM environment, which is one more reason the non-root user from the provisioning step wasn't optional. What the flag disables and the safer middle grounds (allowlists, acceptEdits, plan-first runs) are laid out in the guide to --dangerously-skip-permissions.
Your own VPS vs Claude Code on the web
Anthropic has its own answer to "run it somewhere that isn't my laptop": Claude Code on the web runs async sessions on Anthropic-managed VMs against a GitHub repo and returns branches and pull requests, with claude --cloud starting one from any terminal. For GitHub-hosted repos and self-contained tasks it's genuinely enough, and it costs zero setup.
The VPS wins at the edges of that. Repos that don't live on GitHub. Projects needing custom tooling the managed VM doesn't have, a specific database, an internal API only reachable from your network, a licensed compiler. Persistent state between sessions, since your box keeps its databases, caches and half-finished experiments warm while cloud sandboxes start clean. And attended-but-remote work, because tmux attach mid-run gives you a level of watch-and-steer that a web dashboard doesn't. I use both: web for disposable GitHub chores, the VPS for everything with state. If the agent side of this is still new to you, the first-session walkthrough in how to use Claude Code is the place to build the habits before you leave them running unattended.
