All posts
7 min read

How to Run Claude Code on a Remote Server (and Keep It Running)

Running Claude Code on a server instead of your laptop means sessions survive a closed lid, a dropped connection, and a flat battery. A practical setup guide — the server, the session, the security — and what you take on by doing it yourself.

Claude CodeAI agentsinfrastructuregetting started

Claude Code runs where you start it. On a laptop, that means the agent's working life is tied to the laptop's: close the lid and the session stops, lose Wi-Fi mid-task and the terminal goes with it, and anything it was building waits for you to come back.

Moving it to a server breaks that link. The agent keeps working while you're away, and you reconnect to the same session from wherever you are. This guide covers the do-it-yourself version properly — and is honest about what you're signing up to maintain.

What "remote" actually needs to mean

There are three different things people mean by running Claude Code remotely, and they need different solutions:

  1. The session survives disconnection. You SSH in, start a task, lose your connection, and the task keeps going.
  2. The session survives you being away for hours. You start something substantial, close everything, and come back to finished work.
  3. The environment survives between sessions. Tomorrow's session starts with yesterday's dependencies installed, database migrated, and notes in place.

A server gives you the raw material for all three, but only the first comes for free. The second needs a terminal multiplexer. The third needs you to treat the server as a long-lived workspace rather than a disposable box.

Step 1: pick a server

You don't need much. Claude Code itself is light — the model runs on Anthropic's side — so the server only has to handle what your project needs: installing dependencies, running a dev server, running tests, maybe a local database.

A reasonable starting point:

Project Rough spec
Scripts, small APIs 1 vCPU, 2 GB RAM
A typical web app with a database 2 vCPU, 4 GB RAM
Large builds, monorepos, heavy test suites 4+ vCPU, 8+ GB RAM

Memory is the one to be generous with. Package installs and bundlers spike memory, and an out-of-memory kill in the middle of an unattended task is a miserable thing to discover the next morning.

Any VPS provider works. Pick a region close to you, because you'll feel the latency in every keystroke over SSH.

Step 2: harden it before you install anything

A server that runs an agent with shell access deserves more care than a hobby box, not less.

  • Create a non-root user and do all the work as that user. Never run the agent as root.
  • Use SSH keys only. Disable password authentication in sshd_config.
  • Turn on a firewall allowing SSH and nothing else until you need more.
  • Enable automatic security updates. You will forget otherwise.
adduser dev
usermod -aG sudo dev      # remove later if the agent shouldn't have it
ufw allow OpenSSH && ufw enable

That sudo line is a real decision, not boilerplate. If the account the agent runs as can sudo, the agent can do anything to the machine. Give it sudo while you set things up, then think hard about whether to take it away.

Step 3: install your toolchain and Claude Code

Install whatever your project needs — Node, Python, a database — then Claude Code itself, following Anthropic's current install instructions for Linux. Clone your repository into the user's home directory and run claude once from inside it to sign in.

Signing in on a headless server works: Claude Code gives you a URL to open in a browser on any device, and you complete the login there. You can use a Claude Pro or Max subscription, or an Anthropic API key — see which of those makes sense for Claude Code.

Step 4: run it inside tmux

This is the step that makes it actually remote. Without it, your Claude Code session is a child of your SSH connection, and when the connection drops, the session dies with it.

tmux runs the session independently of your connection:

tmux new -s agent       # start a named session
claude                  # run Claude Code inside it
# press Ctrl-b then d to detach — the session keeps running

tmux attach -t agent    # reattach later, from anywhere

Detach, close your laptop, reconnect from a different machine tomorrow, and tmux attach puts you back exactly where the agent is. For several projects, run one tmux session per project so they don't share a terminal.

If your connection is flaky — trains, phones, hotel Wi-Fi — mosh in place of plain SSH makes reconnection seamless. It pairs well with tmux.

Step 5: decide how much it can do without asking

Out of the box, Claude Code asks permission before running shell commands and editing files. That's the right default when you're watching. It's useless when you're not, because the agent stops at the first prompt and waits for hours.

The fix is not to switch everything off. It's to pre-approve the commands your project routinely needs — the test runner, the build, the package manager — and keep prompting for the dangerous ones. We cover the permission modes and allow/deny rules in detail in Running Claude Code Unattended. The short version: the more you let it run unattended, the more the server itself has to be the safety boundary.

Step 6: get to it from other devices

Once the session lives on a server, any device with SSH reaches it. From a phone, an SSH app plus tmux attach gets you into the live session. Anthropic has also shipped ways to steer sessions from the Claude apps; we compare the options in How to Use Claude Code From Your Phone.

What you've now taken on

Here is the honest part. You've built a working remote agent setup, and you now own:

  • Security patches for the OS and everything installed on it.
  • Backups. The server's disk is the only copy of anything not pushed to git — including the agent's scratch files and your local database.
  • The database. If your app needs Postgres, you installed it, and you're responsible for its upgrades, its backups, and restoring it when something goes wrong.
  • Exposure. Previewing the app from your phone means opening a port, putting a reverse proxy in front of it, and issuing a certificate — or tunnelling.
  • Disk and memory pressure. Agents install things. Disks fill. Nobody warns you.
  • Isolation between projects. Every project on the box shares one user, one filesystem, and one set of resources. A runaway build in one starves the rest.

None of that is exotic, and if you enjoy running servers, it's a fine setup — many people run exactly this. But notice that most of the list has nothing to do with Claude Code. It's the ordinary cost of operating a machine that happens to have an agent on it.

The checklist

  • Non-root user, SSH keys only, firewall on, automatic updates
  • Toolchain installed, repo cloned, claude signed in
  • Claude Code running inside a named tmux session
  • Routine commands pre-approved; destructive ones still prompt
  • Code pushed to GitHub regularly — the server is not your backup
  • A plan for the database, backups, and previewing the running app

Get the first four right and you have an agent that works while you don't. The last two decide whether it's still a good idea in six months.


EasySpawn is the managed version of this setup: Claude Code running in a persistent, isolated workspace, with managed Postgres, automatic SSL, a live URL per branch, and backups handled — reachable from the web, your phone, or SSH. See how it works or join the waitlist.

Related: Why AI Coding Agents Need Persistent Workspaces · Running Claude Code Agents in Parallel With Git Worktrees

Keep reading