Graduating from OpenClaw and Hermes to coding agents

What personal assistants already taught you

The interesting part of OpenClaw or Hermes Agent was never the chat window. It was the decision, somewhere under the hood, to give a language model a persistent process instead of a single request-response call. A resident assistant sits on a machine that stays powered on, holds state between conversations, and executes tool calls — reading your calendar, drafting an email, toggling a smart-home switch — on a schedule or in response to a message you send from your phone while you're nowhere near the machine itself.

That's a bigger trust leap than it looks like from the chat UI, and if you run one of these tools daily, you already made it. You gave a process standing credentials to real accounts and let it act while unsupervised. The interesting engineering wasn't the model getting smarter; it was infrastructure — an always-on server, a way to reach it from anywhere, a way for the agent to keep working after you close the laptop.

A coding agent is built on exactly that same shape: a long-lived process, reachable from anywhere, holding state, acting on standing permissions. What's different is what it's been handed permission to touch, and that difference is the entire subject of this page.

The capability ladder

Line up the tools you might hand an AI system and a pattern falls out: each rung keeps everything the rung below could do and adds one new class of access — and every new class of access is also a new class of risk. Climb it one step at a time and narrate both halves honestly:

Rung three is where this guide is headed, and it deserves its own page: what an AI coding agent actually is walks through the loop — prompt, tool call, observe, repeat — in detail. What matters here is the throughline: assistants and coding agents are the same architecture pointed at different, higher-stakes surfaces, and the discipline required scales with what's on the other end of the tool call.

What changes once the agent can write to a repo

An assistant's mistakes are mostly transient. A mis-sent email is embarrassing; a wrong calendar invite gets deleted. Annoying, recoverable, contained to the moment it happened. A repository does not forgive that way, because of one structural fact: a git repository is shared, mutable-by-convention, but permanently-recorded state. Every clone of it — your laptop, a teammate's machine, a CI runner, production's deploy source — is a copy of the same history, and once a commit is pushed to a branch others build on, it doesn't just describe a change; it becomes the foundation the next hundred commits are written on top of.

That changes what a mistake costs. A coding agent that commits a broken dependency bump doesn't waste a moment — it breaks the build for every clone until someone notices and reverts. One that commits a leaked credential doesn't just expose it once — the credential sits in history, retrievable by anyone with clone access, until someone rewrites history to remove it (which is its own hazard on a shared branch). Mistakes on a chat surface are ephemeral. Mistakes in a git history compound, because the next hundred actions — yours, a teammate's, another agent's — are built on top of whatever was there.

This is exactly why the practices that feel like overhead for a personal assistant — code review, small commits, isolated working copies per writer — stop being optional the moment an agent's actions land in a repository other things depend on. Not because coding agents are less trustworthy than assistants; because the medium they write to remembers, and shares, everything.

The 2026 reckoning: OpenClaw's security lesson

OpenClaw earned its popularity honestly — hundreds of thousands of people run a resident agent on a server because the model of "always on, reachable from anywhere" is genuinely useful, and the project proved it at scale. Then, in March 2026, that same scale became a liability, and it's worth understanding precisely what security researchers reported rather than the flattened version that spread afterward:

• Nine CVEs disclosed in four days, including one rated CVSS 9.9 — near the top of the severity scale, the kind of score reserved for flaws exploitable remotely, without authentication, with full impact on confidentiality, integrity, and availability.
• An audit of ClawHub, the community skill marketplace, found roughly 12% of an initial sampled batch of skills contained malicious code — credential exfiltration and hidden backdoors, installed with the same standing permissions as the assistant itself, because a marketplace skill runs as the agent, not as a sandboxed guest.
• A public internet scan found 135,000-plus reachable OpenClaw instances at default or near-default configuration — meaning the moment those CVEs were public, there was an enormous, pre-enumerated target list for anyone testing them.

None of that is a verdict on running a personal assistant, and it isn't a knock on OpenClaw's maintainers, who patched fast once the reports landed. It's a case study in what happens when a capable, tool-using process sits on a public port at scale: vulnerabilities in any widely deployed software are a matter of when, not if, and the instances that paid for it were the ones a scanner could reach in the first place.

Exposure surface: the fix isn't a stronger password

The general lesson underneath the OpenClaw timeline has nothing to do with OpenClaw specifically: an agent with real tool access needs a private network perimeter, not a public port. Internet-wide scanners don't guess at your domain name — they enumerate the public IPv4 address space directly, port by port, and fingerprint whatever answers. A service only gets scanned if it has a public address and an open port to answer on. Remove either one and the scanner gets nothing to fingerprint, patched or not.

A private network — a VPN, or a mesh overlay often called a tailnet — solves this at the network layer, before any application code runs. Machines on it get addresses that exist only inside that private routing table; no public listing points to them, and a scanner working through the public internet has no path in. Reaching the agent from your phone still works, over an encrypted tunnel from a device that's already a member of the network — which is the same reachable-from-anywhere property OpenClaw and Hermes rely on, just routed privately instead of broadcast to everyone. SSH keys are the other half of this: authenticate the human, not just the network, before anything with tool access accepts a command.

Nothing about the agent's code changed between the two toggles above — same skills, same tool access, same eventual bugs waiting to be found. What changed is whether a stranger's scanner can reach it at all. That's why network placement is the first control, not an optional hardening step for later: it's the one thing that protects you against vulnerabilities that haven't been disclosed yet.

The agent stack: two substrates, not one

The consensus that formed across 2026 is to stop running one resident process for everything. A personal assistant and a coding agent have different risk profiles, different lifecycles, and — this is the part that's easy to skip — different blast radii if either is ever compromised, so the practical answer is to keep them on separate, properly isolated substrates rather than one box wearing two hats.

• Different targets. An assistant holds credentials to your personal accounts, calendar, and smart-home controls. A coding agent holds credentials to source code, package registries, and often deploy keys or production secrets. Neither set of credentials belongs sitting next to the other on one compromised host.
• Different lifecycles. An assistant runs continuously, listening for a message at any hour. A coding agent typically runs task-scoped sessions — start, do bounded work, stop — even when that session lasts hours. Continuous listening processes are exactly the shape scanners find; task-scoped ones have a much smaller window to be found in.
• Different failure containment. If the assistant's process is compromised, the damage is contained to what it manages — bad, but bounded. If it shares a machine, network, and credential store with the coding agent, the damage is no longer bounded to either one.

In practice this means: your assistant and your coding agent can both live on a VPS — even the same provider, even the same private network — but as separate hosts or clearly separated environments with their own credentials, not one process granted both sets of permissions because it was convenient to set up once.

Git discipline: the boundary a coding agent needs

Network isolation keeps strangers out. Git discipline is the matching control for the agent you deliberately let in — the one you're paying to write code, whose mistakes now compound the way section 3 described. None of this is exotic; it's the same handful of habits that make git safe for AI agents in general, applied from day one instead of retrofitted after an incident:

None of this requires distrusting the agent more than you already trust OpenClaw or Hermes with your calendar. It requires recognizing that the medium changed. A calendar entry you can just delete; a pushed commit is something you have to consciously undo, on purpose, in front of whoever already pulled it.

The graduation path

None of the above requires a rebuild of how you already work — it's five concrete steps from "assistant on a box" to a first coding-agent session done safely:

1. Get a VPS if the coding agent isn't sharing infrastructure with your assistant already — a small always-on machine you don't have to keep your laptop open for. See why your agent needs a home that isn't your laptop for the failure modes a laptop introduces (sleep, wifi drops, a dead battery) that a server doesn't have.
2. Put it on a private network before anything else runs. VPN or tailnet, set up first — not bolted on after the agent is already live on a public port. Section 5's sim is the reason: exposure is a network-layer decision, made once, not a per-service setting you have to remember everywhere.
3. Set up persistent sessions. The same lesson your assistant already taught you — work should survive you closing the laptop — applies to a coding agent mid-task even more, since a task can run for hours. A session that dies with your SSH connection loses exactly the work in flight.
4. Run your first coding agent session against a real but low-stakes repo. Not production on day one. A side project or a well-tested internal tool, where a bad commit costs you an afternoon, not an incident.
5. Adopt the git discipline from section 7 from the first commit, not after the first collision. Small commits, a review gate, one writer per working copy. Retrofitting discipline after a mess is much harder than starting with it.

How TermRoam handles this

TermRoam is built for exactly this graduation: an always-on, private-network-friendly server with persistent terminal sessions that survive disconnects, and a coding-agent execution model with the review gates, one-writer-per-worktree isolation, and commit-by-commit verification from section 7 built in rather than left for you to assemble by hand.