Why Coding Agent Suppose Run Inside Disposable VM

Why disposable VM better pass your laptop

Give coding agent one disposable VM, and the worst thing wey e fit do na destroy machine wey you fit rebuild within ten minutes. Agent still get root, still install packages, and still run test suite without asking permission for every step. Difference na where the damage go land. For laptop, agent dey share home directory with your SSH keys, browser profile, your .env files, and every other repository wey you don ever clone. For throwaway server, e get shell, one checkout, and nothing else wey worth stealing.

Na the whole argument be this, and na argument about asymmetry, no be probability. Careful agent for careful laptop dey okay almost every time. The one time e no okay, cost no be bad commit. Na restore from backup, if you get backup.

Name the blast radius before you argue about it

Blast radius na set of things wey one process fit reach. For agent wey dey run as your normal user for your normal machine, that set dey bigger pass wetin most people dey imagine.

E include ~/.ssh/id_ed25519, wey normally no get encryption because you don tire to dey type the passphrase. E include ~/.aws/credentials and ~/.config/gh/hosts.yml, wey plain text by design. E include every sibling repository under ~/code, including the ones wey get production connection strings for local env file. E also include your shell history, wey hold tokens wey you paste once. E include the network wey your laptop dey use too. Most times, na home or office network wey get unauthenticated services.

None of this need malicious agent. One confidently wrong command dey enough. rm -rf "$BUILD_DIR"/* with BUILD_DIR unset, wey expand to /* and pass GNU rm default refusal to delete / itself, a git clean -xfd for wrong directory, a docker system prune -af --volumes wey carry your local database along, or a helpful chmod -R 777 for home directory. Agents dey train with the same internet wey teach everybody else those commands.

The thing wey save you no be the agent's judgement. Na say the machine wey hold the damage na one wey you ready to lose.

Cost calculation boring dey, and na the point

Small VPS dey cost few dollars every month. To recover developer laptop fit take one day, and na the good case be that, where you notice the problem immediately and you get backup.

Calculate am with your own numbers. Take your hourly rate, multiply am by the hours wey e go take to reinstall operating system, restore home directory, rotate SSH key, rotate personal access token, and re-clone twenty repositories. Compare that amount with twelve months of the smallest server wey your provider dey sell. Break-even go happen after less than one incident every several years, and the incident no need be catastrophic before e pass that cost. One afternoon wey you lose because local environment corrupt don already pay for the whole year.

The second part of the calculation na snapshots. Snapshot before risky run fit change bad outcome from "restore my life" to "roll back and try a different prompt". You no get that option for the laptop wey you dey type this on, because you no fit take snapshot of machine while you dey use am as your desk.

The situation for October 2026

There are three correct answers to “where the agent suppose run”, and each one dey balance the same two things: how strong the boundary be, and how much setup you fit tolerate.

A local micro VM. Tools for this category dey boot real virtual machine for your own hardware, mount your repository inside am, and give the agent root access inside. clawk na the current example, and the main idea be exactly wetin this post dey explain: give coding agents disposable Linux VM, no be your laptop. As of October 2026, e targets macOS 14 and later for Apple silicon, with experimental Linux support through Firecracker, and you fit install am with brew install clawkwork/tap/clawk. You run clawk inside repository to boot the sandbox and attach agent, clawk down to stop am, and clawk destroy to remove am. The boundary na hypervisor, so e strong. The limit be say the VM dey run for the machine wey you dey carry around, so e dey compete for your memory and e go stop when you close the laptop lid.

A container. Docker na the answer wey most people don already install, and e genuinely useful.

docker run --rm -it -v "$PWD:/work" -w /work --network none ubuntu:24.04 bash

--rm go throw the container away when e exit, while --network none go give am no network access at all. This na good default for build or test run. Make you understand wetin this no do: container dey share host kernel, so kernel bug fit provide way out, and the boundary disappear immediately you add --privileged or mount /var/run/docker.sock so the agent fit “use Docker”. If you mount Docker socket inside container, e be the same as giving that container root access on the host.

A plain VPS wey you fit rebuild. No new tool, real kernel boundary, provider snapshots, and e go continue running even when you shut your laptop. Na this pattern the rest of this guide dey describe, and na the one wey fit survive long agent runs, because job wey dey take four hours no care say you don go house.

The VPS pattern: give the agent its own user

Start with a box wey you don harden. The first ten minutes for new VPS cover the parts wey no depend on agent: updates, non-root login, key-only SSH, and firewall.

Then create account wey na only the agent go use, so mistake inside am no fit touch anything else for the server.

sudo adduser --disabled-password --gecos "" agent
sudo install -d -m 700 -o agent -g agent /home/agent/work
sudo -u agent -H bash -lc 'id; ls -la ~'

--disabled-password mean say no password dey to guess, and you fit enter the account with sudo -u agent or SSH key. Note say agent no dey inside sudo group deliberately. Agent wey get sudo get root access, and root fit read every other user files, so the separation wey you just build na only decoration. If the agent truly need install packages, that one na reason to use whole server wey e own, no be to give am sudo for shared server. The general rules dey for least privilege for Linux users on VPS.

Check the boundary before you trust am. As the agent user, try list your own account home directory:

sudo -u agent ls /home/you

You suppose see ls: cannot open directory '/home/you': Permission denied. If you see file listing instead, other users fit read your home directory, and the agent fit read anything inside wey no get separate protection, like a world-readable .env file. Fix am with sudo chmod 700 /home/you. This test no dey protect your private SSH key: ssh ignores private key file wey other users fit access, so any key wey actually work for you don already become unreadable to agent, no matter the mode wey your home directory get.

Keep the credentials off the machine entirely

Disposable machine get one main purpose: e no suppose hold your production secrets. If you copy production secrets enter am, you don spoil that purpose. Rule simple: nothing for that machine suppose be credential wey you no go mind rotate this afternoon.

For git, forward your SSH agent instead of copying key. Private key go remain for your laptop, and na signature requests only go pass through the connection.

ssh -A agent@203.0.113.10
ssh -T git@github.com

The second command suppose answer Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.. That one prove say git push go work even when server no get key file. Run ls -la ~/.ssh for the machine afterwards, then confirm say no private key dey inside am.

Agent forwarding get one real warning, so make we talk am clearly: while you dey connected, anybody wey get root for that server fit use the forwarded socket authenticate as you. If na server wey only you dey use, that tradeoff dey acceptable. For shared machine, e no acceptable. Deploy key wey scope to one repository na better answer. You fit see the options for SSH key management basics.

For API keys, give the agent e own key with e own spending limit. Store the key for file wey agent user own, with mode 600. When you destroy the machine, revoke that key instead of wondering whether e leak. If you track model spending per key, the numbers for AI agent cost control on a VPS go remain predictable.

Limit wetin agent fit reach for network

Filesystem isolation na only half of the boundary. The other half na egress: wetin process fit talk to. Linux fit filter outbound traffic based on the user wey create am, and this fit the pattern exactly.

sudo iptables -A OUTPUT -m owner --uid-owner agent -o lo -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p tcp --dport 443 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -j REJECT

System dey read the rules in order, so the last REJECT go catch everything wey earlier lines no allow. Test am as the agent:

sudo -u agent curl -sS -m 5 http://example.com

This one suppose fail immediately with a curl: (7) Failed to connect to example.com error. After that, wording fit change based on your curl version, because the reject rule answer immediately instead of making the connection hang. HTTPS request to the same host suppose still work.

Two limits wey you need state clearly. First, these rules go disappear after the next reboot unless you save dem, with sudo apt install -y iptables-persistent and then sudo netfilter-persistent save. Second, this filtering dey work with ports and addresses, not names. Rule wey allow port 443 go allow every HTTPS host for internet. That one enough to reach the model API, and e also enough to reach a pastebin. Real domain allow-list need the traffic to pass through a proxy wey dey read the requested hostname. That one na more machinery than most single-developer setups want. Claim only wetin you actually get: port-level egress control, for machine wey you don prepare to lose.

Reboot clean state between tasks

Clean state for each task na be benefit wey people dey underrate. Agent wey spend three hours on the last ticket fit leave installed packages, migrations wey apply halfway, stale node_modules, and git working tree with changes wey nobody review. Next task inherit everything, and you go spend your review time to find out which mess belong to which run. Narrower agent no go leave plenty things behind from the start. So, if you pair disposable machine with skill wey push agent toward the smallest change wey go work, both the diff and leftover state go remain small enough to review.

The cheap option na fresh checkout for each task.

sudo -u agent -H bash -lc 'rm -rf ~/work/repo && git clone git@github.com:you/repo.git ~/work/repo'

The stronger option na provider snapshot wey you take once, immediately after you set up the machine and before any agent touch am. When you restore that snapshot, the whole system, including packages, go return to known state. Most providers expose this feature for control panel or through API, instead of as command wey you run for the box. So, the exact steps depend on your provider. The important thing na to take the snapshot while the machine still dey unused.

Keep anything wey matter to you off the disposable machine. Most times, this mean say you push branches instead of keeping dem only for local machine. If the box eventually hold something wey you go miss, back am up properly with restic backups for VPS. Machine wey you fit destroy only useful if destroying am no cause real wahala.

If you want several isolated environments without paying for several servers, one larger VPS fit host guest VMs directly. Nested virtualisation for VPS explain how this one work, including how to check whether your provider allow am. Isolation get two sides here. If you prefer make two agents coordinate for the same box instead of keeping dem completely separate, one Claude Code session fit send text directly to another instead of routing every handoff through you.

When laptop wey get proper care dey genuinely okay

Make we talk true about this, because if we overstate isolation, people go stop to listen.

If you dey review every command before e run, laptop dey okay. The permission prompt na real control, and running Claude Code safely on a server explain wetin each level actually dey block. If your work na one repository, and no production credentials dey anywhere for the machine, the blast radius don already small. If your agent sessions short and you dey supervise dem, the exposure window short too.

The answer change immediately you skip the prompts. This one worth thinking about now because auto mode is the Claude Code default, and fresh install no longer ask you before e edit files or run commands. Unattended runs, overnight jobs, and any workflow wey you approve plan then waka comot all remove the human check wey dey contain the risk. Na that time the machine need handle am instead. The same thing apply to anything wey widen the agent reach, including running a coding agent on a VPS across several repositories at once.

The decision no really depend on how much you trust the model. E depend on wetin dey next to am when the model make mistake.

FAQ

Container enough isolation for coding agent?

For most work, yes, if two conditions dey hold. Container no suppose run with --privileged, and e no suppose get /var/run/docker.sock mounted inside am, because any of dem fit give process road reach root for host. Container dey share host kernel, so boundary no strong reach wetin virtual machine get. If agent dey run untrusted code wey e pull from internet, use real VM or separate server instead.

Agent need sudo for server?

No. If you give am sudo, e go cancel the isolation wey you build, because root fit read every other account for the machine. Create agent user without sudo, and give am write access only to im own work directory. If task really need package installation, give agent complete machine wey belong to am instead of root access for machine wey e dey share.

How I fit let agent push to git without putting my SSH key for the machine?

Forward your SSH agent with ssh -A when you connect. Signature requests dey pass through the connection while private key remain for your laptop, so ssh -T git@github.com fit authenticate and git push fit work without private key for server. But root for that server fit use the forwarded socket while you dey connected, so use repository-scoped deploy key for any machine wey you dey share with other people.

Wetin be the VPS size wey agent need?

Agent work mostly na editing files, running builds, and running tests, so size the machine based on the build, no be the model. Hosted model dey run for provider hardware, wey add network traffic but almost no local load. Agent itself still get minimum requirement: as of October 20, 2026, Claude Code system requirements list 4 GB of RAM as minimum. Start with 4 GB even for scripting work, and move to 8 GB if repository dey build containers or compile anything substantial.

How often I suppose destroy and rebuild the machine?

Rebuild when the machine state no longer dey explainable, and at minimum whenever credential for the machine fit don expose. Fresh checkout between tasks dey handle everyday drift, while snapshot wey you take before first agent run gives you clean system image wey you fit return to. If rebuilding dey feel expensive, e mean say something important dey live for machine wey you call disposable.