Give Your Coding Agent One 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 mean the set of things wey one process fit reach. For an 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 usually 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 still include your shell history, wey fit hold tokens wey you paste one time. E also include the network wey your laptop dey use, and na often home or office network wey get unauthenticated services.

None of this need malicious agent. One confidently wrong command dey enough. rm -rf wey get unset variable wey expand to /, one git clean -xfd for wrong directory, one docker system prune -af --volumes wey carry your local database along, or one helpful chmod -R 777 for home directory. Agents dey train on the same internet wey teach everybody else those commands.

The thing wey protect you no be the agent judgement. Na the fact say the machine wey hold the damage na one wey you don 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 landscape as of July 2026

There are three honest answers to "where should the agent run", and dem 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 allow the agent get root inside. clawk na the current example, and the main idea na exactly this post's thesis: give coding agents disposable Linux VM, no be your laptop. As of July 2026 e targets macOS 14 and later for Apple silicon, with experimental Linux support through Firecracker, and e installs 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. Hypervisor na the boundary, and e strong. The limit be say the VM dey live for the machine wey you dey carry around, so e dey compete for your memory and e go stop when you close the 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, and --network none no go give am any network at all. This na good default for build or test run. Make you understand wetin this one no do: container dey share host kernel, so kernel bug fit provide way out, and the boundary go 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 for the host.

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

VPS pattern: give the agent im own user

Start with a hardened box. 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 by design. 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 really need install packages, that one mean say e need whole server wey e own, no be to give am sudo for shared server. General rules dey for least privilege for Linux users for VPS.

Check the boundary before you trust am. As agent user, try read file wey belong to your own account:

sudo -u agent cat /home/you/.ssh/id_ed25519

You suppose see cat: /home/you/.ssh/id_ed25519: Permission denied. If you see key material instead, your home directory dey mode 755 and the isolation never real yet. Fix am with sudo chmod 700 /home/you.

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 dey allowed to connect to. Linux fit filter outbound traffic based on the user wey create am, and this match 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 final REJECT go catch everything wey earlier lines no allow. Test am as the agent:

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

That one suppose fail with curl: (7) Failed to connect to example.com port 80: Connection refused, because the reject rule go answer immediately instead of making the connection hang. HTTPS request to the same host suppose still work.

Two honest limits dey. 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 filters 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 still enough to reach a pastebin. True domain allow-list need the traffic to pass through a proxy wey reads 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 a 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 you handle well fit really dey okay

Make we talk true about this, because if person overstate isolation, people go stop listening.

If you dey review every command before e run, laptop dey okay. The permission prompt na real control, and how to run Claude Code safely for server go 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 dey important now because auto mode go become Claude Code default on 14 August 2026, and fresh install no longer go ask before e edit files or run commands. Unattended runs, overnight jobs, and any workflow where you approve plan then comot all remove the human check wey dey contain the risk. Na that time the machine itself must do the containment. The same thing apply to anything wey increase the agent reach, including how to run coding agent for VPS across several repositories at once.

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

FAQ

Container fit provide enough isolation for coding agent?

For most work, yes, but two conditions dey apply. Container no suppose run with --privileged, and e no suppose mount /var/run/docker.sock inside am, because either one fit give the process path go root for host. Container dey share host kernel, so the boundary no strong reach virtual machine own. If agent dey run untrusted code wey e pull from internet, prefer real VM or separate server.

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 its own work directory. If the task really need package installation, give agent a complete machine wey na im own instead of root access for machine wey e dey share.

How I go make 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 authenticates and git push works 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 share with other people.

Which VPS size agent need?

Agent work mostly na editing files, running builds, and running tests, so size the machine based on the build, not the model. Hosted model dey run for provider hardware, so e add network traffic and almost no local load. Start with 2 GB RAM 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 am when the state no longer dey explainable, and at minimum whenever credential for the machine fit don expose. Fresh checkout between tasks dey handle day-to-day drift, while snapshot wey you take before the first agent run gives you clean system image wey you fit return to. If rebuilding dey feel expensive, e show say something important dey live for machine wey you call disposable.