Claude Code on a VPS: tmux, Remote Control and SSH

Why people want this

A coding agent on your laptop stops 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.

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. Or skip public SSH entirely with a private tunnel. (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 on the box itself; if you will drive it by Remote Control, that login can lapse and has to be renewed there.
• 3. Run it inside tmux:

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

  Copied
  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.” Start it as claude --remote-control agent instead and the same session also appears in the Claude app’s Code tab, so the phone needs no SSH at all (the phone guide has the details). Claude Code’s agent view, claude --bg, keeps a session alive past the terminal without tmux, though not past a restart; it is a research preview.
• 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. Either kind can run on your own Claude plan; what the labs’ terms allow and bar on a server is in using your Claude or ChatGPT subscription on a server.

One session is the start. Several at once, each in its own git worktree with one coordinating the rest, is an orchestrator, and it is what pushes a box past 4 GB: the sessions themselves are light, the builds and browsers they start are not.

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. Claude Code’s auto mode, where interactive sessions start since version 2.1.283, is the middle ground: no prompts for routine work, with a classifier checking actions in the background. It narrows the risk; it doesn’t move the boundary off the machine. The agents’ own logins live on that machine too, and securing a VPS for Claude Code and Codex covers what each can read of the other’s.

Can the agent administer its own server?

Mostly, yes, and it’s 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 earn their keep: 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, Anthropic’s Projects), 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. Everpod’s developer pod is that machine: a permanent cloud computer (VPS), set up and secured for you, with your pick of Claude Code, Codex, OpenCode, Pi, Hermes and OpenClaw installed, and you as its administrator.