agentos.guide › blog

Hermes Agent Sandbox: The Quick Start, And How To Fit It Into Your Agent OS

By Julian Goldie · 22 October 2026 · agentos.guide

A Hermes Agent sandbox is the isolated place where the Hermes AI agent runs its shell commands, so a bad command lands in a container instead of on your real machine.

Hermes Agent is the free, open-source agent from Nous Research, and you choose the sandbox with one setting called terminal.backend.

The default is local, which has no isolation, so switching to Docker or the new bubblewrap backend is one of the first jobs I'd do.

This page is the quick start, plus how a sandbox fits each profile in an Agent OS.

The Hermes Agent sandbox quick start

This is the shortest path from the default setup to a sandboxed Hermes inside your Agent OS.

The rest of this page explains each step and then shows how I'd map sandboxes to Agent OS jobs.

What a Hermes Agent sandbox is

Every shell command Hermes runs goes through a terminal backend, and the backend decides where that command really executes.

The official docs list seven backends, and Nous Research added an official bubblewrap backend for Linux to the plugin catalog on 21 October 2026.

The default is local, which has no isolation, and the docs warn that the agent then has the same filesystem access as your user account.

So a Hermes sandbox is simply any backend that puts a wall between the agent and your real files.

This table combines the docs' backend overview, their security comparison and the bubblewrap plugin page.

For the wider meaning of "backend" in Hermes, see my Hermes Agent backend guide.

Step 1 and 2: pick and prepare the backend

For Docker, install Docker Desktop or Docker Engine, then run docker version to check it works.

Podman is supported too, and the docs say you set HERMES_DOCKER_BINARY=podman when both are installed.

For bubblewrap, you need Linux, bubblewrap 0.9.0 or later, prlimit from util-linux and unprivileged user namespaces.

The plugin page gives sudo apt install bubblewrap for Debian and Ubuntu, sudo dnf install bubblewrap for Fedora and sudo pacman -S bubblewrap for Arch.

Then you run hermes plugins install bubblewrap to add the backend.

For SSH, you put TERMINAL_SSH_HOST and TERMINAL_SSH_USER in ~/.hermes/.env.

For the cloud, Modal needs MODAL_TOKEN_ID and MODAL_TOKEN_SECRET, Daytona needs DAYTONA_API_KEY, and Vercel Sandbox needs VERCEL_TOKEN, VERCEL_PROJECT_ID and VERCEL_TEAM_ID.

For Singularity, you need apptainer or singularity on your PATH.

🔥 Want the exact Hermes Agent setup I run inside my Agent OS?

Inside the AI Profit Boardroom you get the installable Agent OS, step-by-step video tutorials, four coaching calls a week and 3,400+ members building real automations.

→ Get access here

Step 3: switch Hermes to the sandbox

The switch is one command, and you swap in the backend name you want.

hermes config set terminal.backend docker

If you prefer a wizard, hermes setup terminal runs just the terminal section of setup.

For bubblewrap, the plugin page gives hermes config set terminal.backend bubblewrap after the plugin is installed.

Since v0.22.0 the default sandbox image is nousresearch/hermes-sandbox:desktop, and the release notes say existing sandboxes are kept.

Run hermes doctor afterwards, because it reports problems such as a missing Modal token or a failed bubblewrap probe.

If anything breaks, the docs say to set the backend back to local and check that commands work there first.

Step 4: keep secrets and the network out

A sandbox only protects you if you don't pass your keys straight into it.

On Docker, docker_forward_env is an explicit allowlist, and the docs say an empty list keeps secrets out of the container.

If you forward a token such as GITHUB_TOKEN, the docs warn that code in the container can read it and send it somewhere.

Setting docker_network: false runs the container with --network=none and cuts off all network access from agent commands.

The default resources are one CPU core, 5 GB of memory and 50 GB of disk, set with container_cpu, container_memory and container_disk.

The Docker hardening drops all Linux capabilities except DAC_OVERRIDE, CHOWN and FOWNER, blocks privilege escalation and caps the container at 256 processes.

Bubblewrap hides .ssh, .aws, .gnupg, .config/gcloud, .azure, .docker, .kube, .npmrc, .pypirc, .netrc, .env and the Hermes home inside every sandbox.

Its three profiles are restricted, workspace and network, and only network reaches the internet.

Step 5: add the commands that must never run

On docker, singularity, modal, daytona and vercel_sandbox, Hermes skips its dangerous-command prompts because the container is treated as the boundary.

Your own approvals.deny list still applies, and the v0.22.0 release notes say it now works in sandboxes.

approvals:
  deny:
    - "git push --force*"
    - "dd if=* of=/dev/*"

The security docs say deny rules run before --yolo, /yolo and approvals.mode: off are checked.

They also say deny rules are a command policy and not a full sandbox, so use them with an isolated backend rather than instead of one.

On local, SSH and bubblewrap, the normal approval prompts stay switched on.

🔥 Want the exact Hermes Agent setup I run inside my Agent OS?

Inside the AI Profit Boardroom you get the installable Agent OS, step-by-step video tutorials, four coaching calls a week and 3,400+ members building real automations.

→ Get access here

Step 6: one sandbox per Agent OS profile

My Agent OS runs Hermes as one of several agents, and I keep separate Hermes profiles for separate jobs.

The docs say each Docker container is labelled with its Hermes profile, so a container for one profile is invisible to another.

That gives you one sandbox per profile without any extra work.

If a profile handles separate clients in separate chats, container_persistent: false gives every chat its own fresh container.

The trade-off is that nothing carries over between those chats, including installed packages.

How the Hermes sandbox fits an Agent OS workflow

This is how I'd map common Agent OS jobs to a sandbox.

The way I'd roll it out is one profile at a time.

Move the riskiest profile, usually the public bot, into Docker first, then the coding agent, then everything else.

If you're picking a server for the always-on profiles, my best Hermes Agent VPS guide covers the hosting side.

Bot Screen, computer use and the browser inside the sandbox

v0.22 gave a bot on a Linux gateway its own desktop that Hermes Desktop streams live.

The release notes say that with a Docker, SSH or Singularity backend, the screen, computer use and the browser run inside the sandbox, never on your host.

The Bot Screen docs say Modal, Daytona and Vercel Sandbox can't host a display yet, so Hermes refuses to start the screen there.

bot_desktop.placement: gateway puts the screen back on the gateway host as an explicit opt-in.

If you're new to Hermes bots, start with my Hermes Agent bot mode guide.

The limits to know before you rely on a sandbox

• Bubblewrap is Linux only, and its file tools such as read_file and write_file still run on the host.
• Bubblewrap has no seccomp filter, no background processes and a default memory limit of 256 MB per process.
• Cloud sandboxes keep the filesystem but not live processes, so a dev server won't still be running next session.
• For SSH, Modal and Daytona, Hermes syncs its own state back, but you should copy your work files out yourself.
• Extra flags in docker_extra_args can silently weaken the Docker hardening.

If your agents also connect to outside tools, read my Hermes Agent MCP server guide, because MCP tools need the same care.

If you want to talk through where sandboxed agents fit your SEO business, you can book a free SEO strategy session with my team.

FAQ

What is a Hermes Agent sandbox?

It is the isolated environment where Hermes runs its terminal commands, chosen with terminal.backend. The docs list local, docker, ssh, modal, daytona, vercel_sandbox and singularity, and the official bubblewrap plugin adds a Linux option.

Is Hermes Agent sandboxed by default?

No. The default backend is local, which runs commands directly on your machine with no isolation and the same file access as your user account.

How do I turn on the Hermes Docker sandbox?

Check Docker with docker version, then run hermes config set terminal.backend docker, or run hermes setup terminal and pick Docker.

What is the Hermes bubblewrap backend?

It is an official Nous Research plugin for Linux that runs each command in its own bwrap sandbox with a read-only root, a writable working directory and hidden credentials. You install it with hermes plugins install bubblewrap.

Do approval prompts work inside a Hermes sandbox?

Container backends skip the dangerous-command prompts, but your approvals.deny rules apply on every backend. Local, SSH and bubblewrap keep the normal prompts.

Can each Agent OS profile have its own sandbox?

Yes. Docker containers are labelled per Hermes profile, so one profile cannot see another profile's container, and container_persistent: false gives each chat a fresh container.

Final word on the Hermes Agent sandbox

Switch off local, move your riskiest profile into Docker or bubblewrap, keep secrets out and write a short deny list.

If you run an agency and want help planning agent work for clients, you can book a free strategy session with my team.

If you want the whole Agent OS with the Hermes tab, the profiles and the training already set up, it lives inside the AI Profit Boardroom, with 3,400+ members and four coaching calls a week.

That is the safest way to run real work through a Hermes Agent sandbox.

Related guides on agentos.guide

→ Hermes Agent Backend: Every Option Explained

→ Hermes Agent v0.22: The Quick Start

→ The Best Hermes Agent VPS

→ Hermes Agent Bot Mode

📺 Video notes + links to the tools 👉

🎥 Learn how I make these videos 👉

🆓 Get a FREE AI Course + Community + 1,000 AI Agents 👉

← all guides on agentos.guide