Coding agents on their own machines

It is 4pm, the agent is twenty minutes into a refactor, and you need to catch a train. On a laptop that is the end of the run. The lid closes, the process dies, and tomorrow you start the conversation again from the top.

That is one of three problems with running a coding agent on the machine you also work on. It competes with you for CPU. It can read every file you own, including the ones you never meant to point it at. And it stops existing the moment you walk away.

Give the agent a computer of its own and all three go at once. That is most of what this page is about.

Every boxd machine ships with three coding agents already installed: Claude Code (claude), Codex (codex), and OpenCode (opencode). Type the command from any directory and start working. They are part of the machine image, so forks and brand new machines carry them too.

The machine explains itself

An agent dropped into an unfamiliar box spends its first few minutes guessing. Where is the package manager, which port is open, how does anything get out to the network. You end up explaining the platform at the start of every session, in slightly different words each time.

Each boxd machine carries an instructions file instead, and every agent picks it up through its own convention.

The file describes the environment: the in-VM boxd CLI, the default proxy on port 8000, and how to create sibling machines, manage proxies, and clean up afterwards. A repo-level CLAUDE.md or AGENTS.md merges on top of it, so your project conventions arrive with the repo and the platform context stays underneath them.

The in-VM boxd CLI is pre-authenticated. Any of the three agents can create machines, exec into them, and expose ports with no token setup and no key for you to paste in. (Yes, this means an agent can give itself more machines. That is the intended behaviour, and it is why --isolated exists.)

Signing in once

Sign in to Claude Code on any machine, and every machine you create afterwards already has you signed in. That covers forks, machines built from a snapshot, and a machine you made a minute ago. boxd stores the credential encrypted on your account and injects it at boot, and you can revoke it from the console at any time.

boxd machine new myapp
boxd machine exec myapp -- claude -p "what branch am I on?"

No login step between those two lines, on a machine that did not exist when you started reading this paragraph.

That matters most when you create machines constantly. A workflow that forks a machine per task, or spins one up per pull request, would otherwise stop and ask for a login every time.

Codex and OpenCode work the same way once you are signed in on a machine, and that login carries into the machine's forks. On a brand new machine they ask again. We are working on carrying those credentials across the same way Claude Code does.

If you would rather use an API key than a subscription, set ANTHROPIC_API_KEY, or the equivalent for the other agents, as an env var or secret. The same binaries pick it up.

One deliberate rough edge: on shared org machines, boxd wipes personal agent logins. It means a teammate can never read your tokens, and it also means a shared machine is not where you get the already-signed-in experience. We think that is the correct trade. See VM sharing.

Two ways to drive them

Interactively:

boxd connect myapp
cd my-project
claude        # or codex, or opencode

Or delegated from your laptop, with no session to sit in:

boxd machine exec myapp 'claude -p "Add a /health endpoint" --dangerously-skip-permissions'
boxd machine exec myapp 'codex exec "Add a /health endpoint"'
boxd machine exec myapp 'opencode run "Add a /health endpoint"'

The useful part is that the two modes mix. Sessions live on the machine's persistent disk, so a job you fired off from a script is still there when you want to take the wheel.

boxd connect myapp
claude --resume <session-id>

Session state survives a reboot too, because the disk survives a reboot. The same holds for the other agents' session storage.

An agent that outlives your laptop

Back to the train. The machine keeps running when you disconnect, so an agent session that lives on the machine outlives the terminal you started it from.

Three pieces make that permanent. tmux keeps the terminal session alive on the machine. Claude Code runs inside tmux. Remote control connects that session to your Claude account.

boxd connect myapp
tmux
claude

Inside Claude Code, run /remote-control to turn remote control on.

Now close the terminal whenever you like. The session keeps running, and you can check progress or reply from the Claude mobile app, the desktop app, or claude.ai. To reattach from a shell, run boxd connect myapp, then tmux attach -t agent.

One caution, and it has bitten people. A long session that thinks quietly for a while can look idle to the machine's network idle timers. For an agent that must keep going unattended, turn hibernation off.

boxd machine config set myapp auto-hibernate.timeout 0

What the agent can actually reach

A boxd machine is a full VM with its own kernel. Anything you would do on a Linux server, the agent can do here, Docker included.

That matters more than it sounds, because it decides which jobs you can hand over. Building an image, starting a daemon, installing a system package, running the thing and watching it fail: all in scope, because there is a real machine under the agent rather than a slice of one. An agent that can only edit text is an agent you have to babysit.

One agent on one machine is the starting point. To fan a problem across many agents in parallel, each on its own machine with a lead agent merging the results, see Agent swarm intelligence.

Start with one machine

Take whatever you were about to ask an agent to do on your laptop this afternoon and do it on a machine instead. Create one, connect, run claude (already signed in), and give it the task.

The interesting moment comes later, when you close the terminal and the work carries on without you. Your laptop goes back to being a terminal. You open it to check on something that never stopped.

Michiel Voortman

PostShare⎘Copy link