Reference build — our own setup, one user
A fix from a moving train
Development normally waits for the laptop. You see the problem on a phone, and nothing can happen until you are back at a desk. So we moved the agent off the laptop entirely: it lives on a small server, it is awake all the time, and you reach it by sending it a message like you would a colleague.
Client
None — our own setup
Field
How we work, day to day
Runs on
Claude Code on a Hetzner VPS
Reached by
A messenger, from any phone
The request was typed on a phone on a train. The work ran on a server. No laptop was opened.
- 1person the bot will answeran allow-list with a single entry; an unknown sender gets nothing
- 0laptops open when the fix went outthe work happened on the server, not on a machine in a bag
- 24/7the session stays awakeit does not close when you shut the lid or board a train
The problem: the work waits for the laptop
You notice something on your phone — a broken page, a message from a client, a fix you can already picture. And then nothing happens, because the thing that can act on it is a laptop in a bag, or at home, or three hours away.
By the time you sit down, the moment has usually cost more than the fix was worth: the context has faded, the day has moved on, and the small job has become an item on a list.
What we built
Claude Code runs on a small server rather than on a laptop. The repositories are already checked out there, so a request arrives somewhere that can act on it immediately. The interface is a messenger: you send it a sentence, it works, it answers.
Nothing about that is exotic — that is rather the point. There is no new app to install, no dashboard, no VPN client to open on a phone. The thing you already carry is enough, and the server does not care whether your laptop is on.
Security is an allow-list of one
An agent with shell access, reachable from the internet, is a liability unless you are extremely clear about who may talk to it. The answer here is the plainest one available: pairing is required, the allow-list holds exactly one entry, no groups are approved, and nothing is left pending. Anyone else who finds the bot gets nothing at all.
That is a deliberate ceiling, not a limitation we plan to remove quietly. Opening this to a team is a different system with a different security story, and it should be built as one rather than by adding names to a list.
The trip that paid for it
The moment it justified itself was a fix sent from a train. The request was typed on a phone, the work ran on the server, the change went out. No laptop was opened, and the thing that would normally have waited for a desk simply did not wait.
One afternoon is not a productivity study, and we are not going to present it as one. But it is the kind of thing that either happens or does not, and before this setup existed it could not have.
What we can show
Nothing here is a screenshot, on purpose: the conversation with this bot is a live shell over our own repositories, so publishing it would publish client code. The verifiable part is the access policy — pairing required, one entry on the allow-list, no groups, nothing pending — and you are welcome to see it on a call.
What this case does not claim
One person uses this, and that person is us. There is no team behind it, no client, no uptime commitment, and no measurement of time saved — the train is a single afternoon recounted honestly, not a statistic. The access policy above was read from the running configuration; the rest is our own account of our own setup.
Want your team to work like this?
Getting an agent off the laptop is the easy half. Deciding who may talk to it, what it may touch, and what it must never do is the half that matters, and it is the half we would spend the call on.