Running Claude Code on an always-on VPS: the tmux pattern, done right

Why people want this

A coding agent on your laptop dies when the lid closes. Put it on an always-on machine instead and you get the things a laptop can’t give: multi-hour tasks that actually finish, kicking off work from your phone on the train, and one persistent environment that accumulates context instead of starting cold. The DIY walkthroughs for exactly this setup have been circulating among developers all year — it’s the same conclusion the agent world keeps reaching from every direction: agents want their own always-on computer.

The core pattern (twenty minutes)

• 1. A small VPS — 2 vCPU / 4 GB is plenty for an agent + toolchain. Secure it like you mean it: key-only SSH, no root login, updates on. (New box? You’ll meet the login-attempt noise within hours — know what it is.)
• 2. Install your toolchain + the agent CLI — git, your language runtimes, then Claude Code (or Codex). Sign in once on the box.
• 3. Run it inside tmux:

  tmux new -s agent
  claude
  # detach: Ctrl-b d   ·   reattach later: tmux attach -t agent

  tmux is the persistence layer: the session survives your SSH connection dropping, and any device that can SSH in can reattach to the same live conversation. A phone SSH client (Termius, Blink) turns this into “coding agent in your pocket.”
• 4. Give the box a handover file. A CLAUDE.md at the project root is what makes a fresh session useful in seconds: what this machine is, what projects live where, house rules, what the agent may do without asking. Write it like an operations handover, because that’s literally what it is.

For unattended scripted runs (cron jobs, CI-style tasks) the official non-interactive mode is claude -p with --allowedTools or a permission mode, and --continue/--resume to keep a thread going across invocations — that half is well documented; the persistent interactive box above is the half the docs don’t really cover.

The security posture is the whole game

On a remote box, the temptation is to run the agent with permissions wide open so it never stalls waiting for you. Understand what that trade means: an agent with unattended shell access is only as safe as everything it reads (a hostile string in a webpage or dependency README is an instruction-injection attempt against it), so the machine itself must be the boundary. Concretely: this box holds only what the agent needs — no password managers, no personal browser profiles, no do-everything cloud keys; repo access via a scoped deploy key, not your identity; a spending cap on the model account; and snapshots/backups so a bad afternoon is recoverable. A first-class citizen of this setup is the assumption that the agent will eventually do something you didn’t intend — arrange the blast radius accordingly.

Can the agent administer its own server?

Mostly, yes — and it’s genuinely useful. Package updates, service restarts, disk cleanups, “why is the dev server down” triage: agents handle this well when the handover file tells them the house rules. Two boundaries have earned their keep in our own operations: the agent administers inside the machine, but identity and access — SSH keys, firewall rules, the provider account — stay yours; and anything irreversible (destroying data, rotating keys, touching DNS) is an ask-first item written explicitly into the handover file. An agent that can rebuild its own dev environment is a feature; an agent that can lock you out of the box is a story you tell at parties.

DIY vs the hosted alternatives

First-party clouds now cover slices of this — Codex’s cloud tasks, Claude Code on the web — and they’re the zero-setup answer for bursty, repo-scoped work. What they don’t give you is the thing the VPS pattern exists for: a persistent machine you own, with state, tools, and context that accumulate. That’s the same ownership trade-off that runs through the whole open-agent world, and it’s why we expect the persistent-agent-computer shape to keep winning for daily-driver use. (Full disclosure of where we sit: Everpod hosts OpenClaw pods today — personal agents, not coding harnesses — so this guide is a straight do-it-yourself recipe. The security posture above is the same one we apply to the agent machines we do operate.)