Modern CLI Agents
The agents compared below wrap the same handful of capabilities:
- a working directory
- a tool palette
- a memory
- optional ways to run without a person actively typing, such as cron, long tasks, or queued jobs
- a network
Their security profiles depend on which capabilities are open by default and whether unattended execution is enabled. The runtime underneath must also catch a bad call.
Module 4a separated application decisions from operating-system enforcement. Application wrappers sit above that boundary. You will compare them before building a browser-based CLI agent of your own.
Shared loop, different application defaults
Each product runs a model in a loop with tools. Defaults and built-in capabilities differ. Implementation detail varies too. Their combined cost and convenience form the harness weight used below.
- Claude Code (Anthropic).
Beacon
CLAUDE.mdat the project root, plus~/.claude/CLAUDE.mdfor user-wide rules. A rich palette (edit, bash, web, sub-agents, long tasks) with hooks that intercept tool calls, and conservative defaults: you opt into broader file and network reach. - Codex CLI (OpenAI).
Beacon
AGENTS.md. Its default sandbox is approval mode: every write or shell command waits for your nod unless you pass--full-auto. The palette centres on shell, and even file-edit is shell. - Cursor (IDE-resident).
Beacon
.cursor/rules/*.mdc. The agent is wired through your editor, so the palette is editor-shaped ("apply this diff to file X") and the sandbox is whatever your editor and OS already grant. - Hermes (Nous Research). A self-improving terminal agent: it creates skills from experience, persists memory across sessions, runs a built-in cron, and is reachable from Telegram, Discord, and Slack through its gateway. The same application shape as OpenClaw, with self-modification and a messaging surface turned on.
- OpenClaw (in NVIDIA NemoClaw).
The one you have been driving. Its beacon is the whole
workspace/folder (SOUL.md, AGENTS.md, IDENTITY.md, and the rest). It supports unattended operation through gateway-managed triggers, and in the NemoClaw reference stack it runs inside the OpenShell sandbox, so its tool palette is gated by a kernel policy regardless of what the model decides.
Note that Hermes seems to differ from the editor CLIs because "automatic learning" is supported by default as a flagship feature. This system still uses the same fundamental primitives as the other agents (skills/cron/memory updates with write permissions), so the risk is not unique to Hermes.
The degrees of freedom are the attack surface
Every one of these agents is configured along the same axes, and each axis names a capability you grant or withhold. The NemoClaw column below reads straight from the OpenShell policy your launchable is running, the one you read live and proved in Module 4a.
| Degree of freedom | The knob | NemoClaw default (live policy) |
|---|---|---|
| Filesystem | which paths are readable / writable | write only /tmp, /sandbox/.openclaw, /sandbox/.nemoclaw, and the workdir; system paths read-only. Enforced by Landlock (best_effort). |
| Network egress | host + port + HTTP method/path, per binary | deny by default; a short allowlist (NVIDIA inference, inference.local, clawhub/npm), each scoped to one HTTP shape and bound to a specific binary. |
| Process identity | which user the agent runs as | non-root sandbox user; ptrace, mount, setuid blocked by seccomp. |
| Binary identity | which executable may use a grant | resolved by exe path plus an ancestor walk with a trust-on-first-use hash; argv[0] is distrusted because it is spoofable. |
| Persistence | cron, skills, and the SOUL.md persona | writable inside the workspace. The policy schema cannot make a single file read-only, so SOUL.md protection is DAC plus chattr +i under "shields up", not the sandbox. |
| Inference routing | which model endpoint calls leave through | routed through the managed inference.local gateway; the Privacy Router decides what context may leave on the operator's policy, not the agent's. |
Try it · the same task, weighed across harnesses
The artifact compares harness weight along these axes:
- Abstractions the harness hides, so you write less code and also see less of what runs.
- Assumptions and defaults it bakes in, which decide how far it reaches before you ask.
- First-class features it ships built in, against the same capability left for you to hand-roll.
Describe a task and compare how much machinery each harness supplies. The editable cell exposes its system prompt and response logic. It also shows the examples. Rerun the cell after an edit to rebuild the artifact.
Deep · BrowserBuild an agent around the browser runtime?
Build a CLI agent whose shell is this browser
The CLIs above attach an agent to a terminal on a real machine. You can build the same
shape with the browser's own JavaScript runtime as the shell. The agent below has one
tool, js, with which it writes JavaScript that runs in this live page and
returns a result the agent reads before deciding what to run next. The runtime is already
loaded, so the harness weighs nothing to stand up. Its reach is still wide: the agent can
read the DOM, call fetch, and use the course helpers, all inside the tab you
are reading.
Module 4c returns to this browser form factor and separates the transferable part—an interactive web surface with visible state and controls—from the authentication, storage, network, and tool adapters supplied by a particular host.
Applied · ShellOpen the launchable shell and sandbox shortcut?
Open a real shell on your launchable
Your NemoClaw launchable gives you a real host shell over the same /ws/terminal
connection Module 4a's policy probes use. That host carries the openshell CLI, the
operator tool that manages your sandboxed agent. Every line you type below runs on the launchable, and
the output is its own.
Connect your launchable on Module 3a first. Type a command, click a
chip, or press Tab to autocomplete. On the host, openshell sandbox list shows your agent
and openshell status reports the gateway. Your agent runs inside a sandbox, so prefix a
command with agent to run it there: agent ls lists its files through
openshell sandbox exec. Each command runs in its own short-lived shell, so to chat with the
agent interactively, use the panel below rather than the openclaw tui.
Chat with your agent
The openclaw tui is an interactive, full-screen chat that a one-shot terminal cannot hold
open. The panel below talks to the same live agent over the OpenClaw gateway, the
/cli/gateway connection Modules 3b and
3c use, so you can chat with it without leaving the page. It streams the agent's
reply and shows each tool or command the agent runs. Connect your launchable on
Module 3a first (its URL and token). Ask it anything, click a prompt,
or press Tab to autocomplete.
The terminal above is the operator plane. From your launchable's host shell,
openshell manages the sandboxed agent, so the host is the control plane that sits above the policy, the
perimeter Module 4a flagged. Commands you push into the agent with
agent <cmd> run under its deny-by-default policy. The host shell answers to the
operator instead.
- Cost to stand up. The launchable was provisioned for you and is already running. On your own machine a CLI takes an install and a configured runtime before its first turn.
- Reach. Inside the agent the kernel policy gates every call, the deny-by-default rules you read in Module 4a. On your own machine the CLI can read and write your files and reach your whole network.
- Blast radius. A prompt injection inside the agent hits that sandbox and its audit trail. The same injection on your own machine runs against your real files, which is the degrees-of-freedom argument from the top of this page, now in your hands.
A heavier harness earns its weight whenever a task calls for persistence and real work that a tab cannot carry. The skill worth building is reading a task well enough to pick the weight it needs, which is the layered view Module 4c closes on.