Why You Need Disposable VM for Coding Agent

Why disposable VM better pass your laptop

Give coding agent one disposable VM, and the worst thing wey e fit do na to destroy one machine wey you fit rebuild within ten minutes. The agent still get root, still dey install packages, and still dey run the test suite without asking permission for every step. The difference na where the damage go land. For laptop, the agent dey share home directory with your SSH keys, your 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 taking.

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, the 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 a process fit reach. For agent wey dey run as your normal user for your normal machine, that set 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 hold tokens you paste one time. E also include the network wey your laptop dey use, wey often be home or office network with services wey no need authentication.

None of this need malicious agent. One command wey get am wrong with confidence fit cause am. rm -rf with variable wey no set expanding to /, a git clean -xfd for wrong directory, a docker system prune -af --volumes wey carry your local database join, or helpful chmod -R 777 for a home directory. Agents train on the same internet wey teach everybody else those commands.

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

The cost math dey boring, na the point

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

Work am out 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 with twelve months of the smallest server wey your provider dey sell. The break-even point dey below one incident every several years, and the incident no need to be catastrophic before e pass that cost. One afternoon wey corruption for local environment waste already fit pay for the whole year.

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

Di landscape as of July 2026

Three honest answers dey for “where agent suppose 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 agent get root inside. clawk na the current example, and the main idea of this post be exactly that: give coding agents disposable Linux VM, no be your laptop. As of July 2026, e target macOS 14 and later for Apple silicon, with experimental Linux support through Firecracker, and e dey install 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, so e strong. The limit be say 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 truly useful.

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

--rm dey throw the container away when e exit, and --network none no give am network 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 agent fit “use Docker”. When you mount Docker socket inside container, e be the same as giving that container root access for host.

A plain VPS wey you fit rebuild. No new tool, real kernel boundary, provider snapshots, and e go continue running 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 take four hours no send say you don go house.

The VPS pattern: make the agent get im own user

Start with a hardened box. The first ten minutes on a new VPS cover the parts wey no dey specific to agent: updates, a non-root login, key-only SSH, and a firewall.

Then create an 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 wey person fit guess, and you fit reach the account with sudo -u agent or an SSH key. Note say agent no dey inside sudo group on purpose. Agent wey get sudo get root, 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 mean say e need one whole server wey e own, no be say you give am sudo for shared server. The general rules dey for least privilege for Linux users on a VPS.

Check the boundary before you trust am. As the 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 mode na 755 and the isolation never real yet. Fix am with sudo chmod 700 /home/you.

Keep credentials off the machine entirely

Disposable machine use lose meaning if you copy your production secrets put am. The rule simple: nothing for that machine suppose be credential wey you go mind to rotate this afternoon.

For git, forward your SSH agent instead of copying key. The private key stay for your laptop, and na only signature requests dey cross 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.. This prove say git push go work without any key file for the server. Run ls -la ~/.ssh for the machine afterwards, then confirm say no private key dey inside am.

Agent forwarding get one important caveat, so make we state am clearly: while you dey connected, anybody wey get root for that server fit use the forwarded socket authenticate as you. For server wey na only you be the other user, this trade-off acceptable. For shared machine, e no acceptable, and deploy key wey scope to one repository na better answer. The choices dey covered for SSH key management basics.

For API keys, give the agent im own key with im own spending limit. Store am for file wey the agent user own, with mode 600. When you destroy the machine, revoke that key instead of dey wonder whether e leak. Keeping model spend visible per key na also how the numbers for AI agent cost control on a VPS stay predictable.

Limit wetin the agent fit reach for network

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

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

The rules dey read in order, so the final REJECT go catch everything wey the 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. An HTTPS request to the same host still suppose succeed.

Two limits dey wey we need talk true. 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. A rule wey allows port 443 allows every HTTPS host for the internet, so e fit reach the model API and e fit also reach a pastebin. A real domain allow-list needs the traffic to pass through a proxy wey reads the requested hostname. That setup get more machinery than most single-developer environments want. Claim only wetin you get: port-level egress control, for a machine wey you ready to lose.

Reset to clean state between tasks

Clean state for each task na benefit wey people dey underrate. Agent wey spend three hours on the last ticket fit leave installed packages, migrations wey only apply halfway, one stale node_modules, and git working tree wey get changes nobody review. The next task go inherit everything, and you go spend your review budget trying to know which mess belong to which run.

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 for control panel or through an API, instead of as command wey you run on the box, so the exact steps depend on your provider. The important discipline na to take the snapshot while the machine still dey plain.

Keep anything wey matter to you away from the disposable machine. This mostly mean say you push branches instead of keeping dem only for the local machine. If the box finally 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 truly no cause problem.

If you want several isolated environments without paying for several servers, one bigger VPS fit host guest VMs directly. Nested virtualisation for VPS explain how e work, including how to check whether your provider allow am.

When laptop wey get care dey genuinely okay

Make we talk true about this, because if person 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 how to run Claude Code safely on a server dey 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 dey short and you dey supervise dem, the exposure window short too.

The answer go change immediately you skip the prompts. 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 suppose do the containment instead. The same thing apply to anything wey widen the agent reach, including how to run a coding agent on a VPS across several repositories at once.

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

FAQ

Container fit be enough isolation for coding agent?

For most work, yes, but two conditions dey. Container must no run with --privileged, and e must no get /var/run/docker.sock mounted inside am, because any one of dem fit give the process path reach root for host. Container dey share host kernel, so the boundary no strong pass virtual machine own. 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 the 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 allow 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 dey 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.

Wetin be the VPS size wey agent need?

Agent work mostly na editing files, running builds, and running tests, so size the machine for the build, not for the model. Hosted model dey run for provider hardware, and this adds network traffic but 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 anytime credential for the machine fit don expose. Fresh checkout between tasks handles day-to-day drift, and 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 mean say something important dey live for machine wey you call disposable.