OpenClaw sandbox mode vs full access: which should you use?

If you just installed OpenClaw and hit npm start, the setup wizard quietly asked a deceptively important question: Sandbox or full access? Get that choice wrong and you either hamstring your new agent or give it more power than you’re comfortable with. This guide compares OpenClaw’s two execution modes, digs into the exact technical limits, and offers a progressive trust workflow that most teams (including ours) now follow.

Why OpenClaw ships with two execution modes

The original Clawdbot prototype ran with unrestricted shell access because it was a weekend hack. A month later someone wired it to GitHub Actions and accidentally deleted half their monorepo. The community asked for a safety rail, so v0.19.0 introduced --sandbox. By default the hosted ClawCloud runtime still runs sandboxed; self-hosting gives you the toggle.

Two modes exist because users fall into two camps:

• Explorers – building chat or help-desk integrations, no need for arbitrary shell or root access. They want to guarantee the agent can’t trash the host.
• Automators – wiring OpenClaw to CI/CD, incident response, or home-lab orchestration. For them the agent’s ability to run kubectl, ansible-playbook, or even rm -rf is the feature, not a bug.

What sandbox mode actually restricts

The term “sandbox” gets thrown around in docs, but here’s what it means in OpenClaw as of v0.32.4:

1. File system boundary

Sandboxed agents see a chroot-like directory ($OPENCLAW_HOME/tmpfs/<agent-id>). Any path outside that tree returns EACCES. File reads/writes are ephemeral; the directory is tmpfs-backed and wiped on restart.

2. Shell execution disabled

When the LLM tries shell.exec("ls -la") the gateway intercepts and returns an error stub. The agent can still respond to the user (“I don’t have shell permissions”) but gets no output.

3. Network egress limited

Only HTTPS outbound to known API domains is allowed: OpenAI, Anthropic, ClawCloud’s vector store, and any connectors you explicitly whitelisted in connections.yaml. No raw TCP or SSH. The goal is to stop data exfiltration or lateral movement.

4. Persistent memory off by default

Sandbox translates memory.write to an in-memory LRU buffer. Restart the daemon and the context is gone. This sidesteps GDPR headaches during experimentation.

There’s no CPU cap or seccomp profile yet, so yes, an infinite loop still burns cores. That’s on the roadmap (issue #5871).

Full access: where the magic (and risk) happens

Flip the switch and the daemon launches as the same Unix user running OpenClaw. The gateway’s shell and fs tools map straight to Node’s child_process and native fs APIs.

• Shell freedom – The agent can spawn interactive shells, pipe scripts, and run Docker or systemctl. If that user is in docker or sudo, so is the agent.
• Real file IO – Reads and writes respect regular POSIX permissions. Uploading a PDF through Telegram and asking the agent to prepend a page? Totally possible.
• Long-term memory – Vector embeddings persist to $OPENCLAW_HOME/memory.db (SQLite) or your configured Postgres. Great for help-desk agents that need to remember every customer over months.
• Unrestricted network – Whatever the host can reach, the agent can reach.

That’s great until you typo a prompt: “Delete every old log older than a week” turns into “Delete every log.” Remember, LLMs are fuzzy. So you’ll want guardrails (next sections).

Decision matrix: sandbox vs full access use cases

Below are patterns we’ve seen across 400+ ClawCloud tenants and our own dog-food instances:

Scenario	Recommended mode	Reasoning
QA chatbot on Slack	Sandbox	No shell needed, regulatory safe.
Continuous deployment assistant	Full	Must run helm, update k8s.
Personal knowledge base	Sandbox → Full	Start safe; once comfy, enable memory to persist notes.
Incident responder in on-call channel	Full (with judicious sudoers)	Needs to tail logs, restart services.
Student demo at a hackathon	Sandbox	No time to audit security.

Progressive trust workflow

You don’t have to decide once and live with it. Most teams adopt a phased model:

1. Week 0 – Sandbox only. Wire messaging connectors, check prompts, confirm the agent respects content boundaries.
2. Week 1 – Read-only full access. Add --allow-shell read. The daemon maps cat, ls, grep but blocks rm, chmod, etc. Good for monitoring tasks.
3. Week 2 – Scoped write. Whitelist directories with claw.toml:

[fs] allowed = ["/var/log/myapp", "/srv/uploads"]

4. Week 4 – Full access on staging. Test destructive commands against non-prod.
5. Week 6 – Promote to prod. Require human approval tokens for any command matching ^(rm|systemctl|kubectl delete).

The key is observable increments. Deploy metrics on shell.exec calls, watch what the LLM tries before removing the handcuffs.

How to switch modes in practice

1. Local / self-hosted

Update .env (or claw.toml if you prefer TOML) and restart:

# .env OPENCLAW_MODE=sandbox # or "full"

Or pass it on the CLI:

$ npx openclaw daemon --mode full --allow-shell read

Remember: the gateway and daemon must agree. If you run multiple daemons behind one gateway, they all need the same flag or chaos ensues (issue #6432).

2. ClawCloud dashboard

Settings → Security → Execution Mode. Flip the toggle, hit Save. The container restarts in about 5 seconds. Logs show:

boot: execution_mode=full user=clawcloud-uid-10077

For auditability, every switch writes an event to audit.log (downloadable).

Mitigations when you must go full access

You’re convinced full access is required. Cool, but add guardrails:

• Run as a non-privileged user – Create openclaw Unix user with limited groups. Avoid sudo. If you need sudo, lock to specific commands via /etc/sudoers.d/openclaw.
• Use AppArmor/SELinux – Wrap the process in an AppArmor profile generated by the community script scripts/gen_apparmor.sh. Blocks unexpected file access even in full mode.
• Prompt firewall – Add a mandatory system prompt: “You must prefix any destructive command with CONFIRM.” Human operator then sends “CONFIRM” if they really want deletion.
• Rate limit shells – Gateway env var SHELL_RATE_LIMIT=30/m stops runaway loops.
• Log everything – Enable OPENCLAW_AUDIT=1. Logs stream to JSONL; ship to Loki/Splunk.

Community war stories (and fixes)

Worth scanning before you flip the switch:

• @jennym builds – Forgot to mount /etc/ssh read-only; agent regenerated host keys and broke Ansible. Now runs with AppArmor.
• @styfle – Let the agent npm install without cache; disk filled 20 GB in an hour. Adds tmpfs quota + telemetry alert.
• @peter-steinberger himself – Internal bot deployed with sudo. Prompt injection through Discord made it restart Docker on Friday night. Patched by sandboxing Discord connector separately.

Takeaway: start small, expand deliberately

Sandbox mode keeps OpenClaw from touching the real world. That’s perfect for chatbots, prototyping, or anyone under tight compliance. Full access unleashes the agent on your file system and infrastructure—the whole reason many of us are excited—but you inherit every LLM hallucination as potential shell commands.

My recommendation: spin up in sandbox, watch the logs, move to scoped read-only, then full access with least privilege. Ten minutes of setup today saves a weekend of firefighting later.

If you hit roadblocks or have a guardrail recipe that works, drop a note in #security on the OpenClaw Discord. We merge the best ideas into the default config every release.