Coding agents changed what a working session looks like. You describe the work, and it happens without you. You can walk away for twenty minutes and come back to a finished change.
The tools around them haven't caught up. Almost all of them still assume you're sitting at the machine the agent runs on, watching it.
I often wasn't. Some days I was nowhere near my PC, and on others I was near it but couldn't do any real work on it. Long-running agents looked like the obvious answer: start the work, walk away, let it run. What I wanted was a way to hand work to an agent while my PC was off.
That raised two questions right away. If I'm away for hours, how do I keep the agent's output good enough to be worth keeping? And when I get back, how do I review what it did without digging through a terminal?
A phone is a good place to ask for work and a bad place to review it. A small screen is fine for a sentence of instructions and a glance at a live page. It's a poor place to read a 300-line diff.
On the phone, an installable web app lets you pick a project, send a prompt and watch the agent's turn stream in: every file it reads, every command it runs, every step of its reasoning. When it wants to run a command, it asks, and you approve or deny it from the phone. A preview tab shows the project's dev server live, so a UI change is something you can see, not just read about. Then you lock the screen, and it tells you when it's done.
At your desk, a desktop app shows you what changed as a real diff, file by file. Nothing reaches your files until you pull. If you changed the same file while you were away, you choose a side per file, and the last pull can be undone.
Your .env files never leave the PC. If the preview needs some of their values, you pick them in the desktop app. It keeps them in the OS keychain and sends them to the runner for the dev server alone. The agent runs in a sandbox and only ever sees their names.
The PC doesn't need to be on while the agent works. It only has to be reachable when you sync.
I set one rule before writing anything. It had to run on infrastructure that costs nothing. No credit card, no domain, no Docker, no paid server.
That ruled out the easy version: rent a small server, point a domain at it, done. What was left was a free Lightning AI Studio, a CPU machine in the cloud with an SSH endpoint and ports you can expose over HTTPS.
The machine restarts every four hours. Not gracefully, and not on your schedule. Processes die, installed dependencies disappear, and a file written just before the restart can come back older or cut short.
You don't control the front door. Traffic reaches the machine through the provider's proxy, and that proxy has its own ideas about cookies and headers.
And the PC is a laptop on a home network. It can't accept connections from the internet, and I didn't want it to.
Each of those could have been a reason to pay for something. Treated as requirements instead, they pushed the system to be more careful than it would have been on a server I trusted.
Before any code, I wrote down every feature end to end: what the phone shows, what the runner does, what the PC does, and what happens at each step when something fails halfway. The design I settled on then is the one that shipped.
Three machines, one job each. The runner, in the cloud, runs the agent, the project's dev server, the API and the phone app, all behind a single gateway. The phone steers. The PC keeps the real project and decides what gets into it.
The easy mistake is to treat a restart as a hiccup: bring the processes back up and carry on. That works until a restart catches something mid-write and the runner starts serving a project that's quietly older than it claims to be.