Stop Making Your Agents Commute With You
Long-running coding agents need a computer that stays put so their work can continue when your laptop closes, disconnects, or dies.
A recent Business Insider story followed people carrying half-open laptops through airports and offices because their coding agents were still running. At an ice rink, one developer put his laptop on a shelf and kept checking it while helping his daughters with their skates. Closing the lid would stop the computer doing the work.
If an agent can keep working after you leave, run it on a computer that stays behind.
The laptop is the wrong host
Local development works because the developer and the computer usually share a schedule. You sit down, edit a file, run a command, and inspect the result. When you leave, the work stops too.
Coding agents do not have to share that schedule. They can keep working after I stop watching them. That makes the laptop's lid, battery, and Wi-Fi part of the job.
Closing the lid can put that computer to sleep. A dead battery stops it. Bad Wi-Fi can cut its connection to the model or whatever else it needs. Keeping the laptop half open is an uptime strategy, just not a good one.
My Chromebook is the window
My setup is boring. I open a Chromebook and SSH into a persistent Linux VM on exe.dev. The repo, tools, files, and agent session live on the VM. When I am done steering, I disconnect and leave the agent running.
Closing the Chromebook ends my access, not the computer doing the work. A dead laptop does not take the VM's disk with it. Bad local Wi-Fi can keep me from watching or steering, but the VM still has its own network connection.
When my connection returns, I SSH into the same Linux machine. The repo and its tools are where I left them. So is any work the agent completed while I was away.
The Chromebook does not need to be my work computer. It only needs to give me a keyboard, a screen, and SSH.
Persistence is the feature
What won me over to exe.dev is refreshingly small: a Linux VM with a persistent disk.
exe.dev VMs do not stop when SSH connections or network traffic disappear, and rebooting does not wipe their disks. The default image includes common coding agents, but underneath it is still normal Linux.
The disk and the process are separate. The agent must run in a session that stays alive after SSH disconnects. Otherwise, closing the shell can stop the process even though its files remain. With that session running, the laptop can disappear without taking the workspace with it.
I can create or manage a VM with ssh exe.dev, then connect to it with ordinary SSH. That is simple enough to become my default, which is why moving the work back onto my laptop now feels wrong.
This is an old idea with a new payoff
In 2022, Google said most employees relied on virtual Linux or Windows desktops running on Compute Engine and reached them through SSH or Chrome Remote Desktop.
My setup is smaller and shell-only, but the useful idea is the same. The device in front of me is a replaceable way into a computer that holds the work. Coding agents make that separation more valuable because the remote computer can stay busy after I close the lid.
The VM does not solve trust or bad Wi-Fi
Remote development still needs a connection. If my Wi-Fi drops, I cannot steer the agent, inspect a diff, or stop a bad run until I reconnect. Network round trips can make tight interactive loops feel worse. Local work still wins when I need to stay offline or use local hardware.
Running an agent in a VM does not make its commands safe. I still have to limit the files, credentials, and services the agent can reach. If I copy every secret from my laptop and expose every service, I have moved the risk rather than reduced it.
Persistence keeps mistakes too, and a remote machine means trusting the provider’s access controls. I still need scoped credentials, updates, backups, and review. The server is a place to contain work, not a reason to trust whatever the agent does.
exe.dev is the version of this setup that I enjoy, not the only way to build it. An always-on Linux box anywhere can provide the same useful split.
I start a task in that session, close the Chromebook completely, and put it in my bag. Later, I open it, SSH back in, and return to the same machine. The Chromebook came with me. The computer doing the work stayed put.