OpenClaw: Advanced features
This is the seventh of eight OpenClaw pages. It covers five power features for after your first week, each with what it is for, how OpenClaw's docs turn it on, and what it trades away.
These steps match OpenClaw 2026.11.3 and its docs as of 14 November
2026. None of them is needed for the jobs on the earlier pages, so take
them one at a time, and keep the approval switch on ask and
the file tools inside the workspace throughout.
A real sandbox with Docker
What it is for. The sandbox moves the agent's commands off your real computer and into a container. A mistake or a prompt injection then lands there instead of on your files. It is the step that makes longer or unattended jobs reasonable.
How to turn it on. Install Docker Desktop and start it first, because Docker is OpenClaw's default sandbox backend. Then paste these lines one at a time.
openclaw config set agents.defaults.sandbox.mode all
openclaw doctor --fix
openclaw gateway restart
The docs say to set the mode to all or
non-main and then run openclaw doctor --fix,
which offers to build the sandbox image,
openclaw-sandbox:trixie-slim. Accept that build. Use
all, because non-main leaves your main chat on
your real computer. To see what the sandbox is actually doing, run
openclaw sandbox explain.
Once it is on, the defaults are strict. Commands get no internet, and
the sandbox works in its own folder under
~/.openclaw/sandboxes instead of your workspace. The
setting agents.defaults.sandbox.workspaceAccess changes
that: none is the default, ro lets the sandbox
read your workspace without changing it, and rw lets it
change your workspace files.
Commands and the file tools move into the sandbox, but the Gateway
itself, add-ons, and MCP servers stay on your computer. This guide could
not confirm that the Docker sandbox works with the native Windows
install from the PowerShell path. On Windows, check
openclaw sandbox explain before you rely on it.
- You gain: a wall between your files and the agent's commands and file tools, so you can let it do more without approving every step.
- You risk: Docker is more to install and keep
running. The docs also call the sandbox "not a perfect security
boundary," so it limits damage rather than ruling it out. Typing
/elevatedin the chat can lift a command back out onto your computer. - Makes sense when: you are comfortable with Docker,
you want longer or unattended jobs, and you keep elevated mode off.
Leave
workspaceAccessonnoneorrounless a job truly needs to change your workspace.
Your own skills
What it is for. A skill is a saved set of
instructions the agent loads when it needs them, so you stop repeating
the same request. OpenClaw reads skills from the skills
folder in your workspace, and each skill is a folder with one
SKILL.md file. The shared Skills and MCP page
compares skills and MCP across every agent in this guide and explains
how to choose safe ones.
How to turn it on. Make a folder for the skill. On a Mac, paste this into Terminal.
mkdir -p ~/.openclaw/workspace/skills/summary-style
On Windows, paste this into PowerShell.
New-Item -ItemType Directory -Force "$env:USERPROFILE\.openclaw\workspace\skills\summary-style"
In that folder, save a plain text file named SKILL.md
with the text below inside it.
---
name: summary-style
description: Write summaries as four short lines with the most useful fact first.
---
# Summary style
When the user asks for a summary, write four short lines.
Put the most useful fact first, and skip any greeting.
Do not run commands, and do not open any website.
The name uses lowercase letters, digits, and hyphens,
and it should match the folder name. The description stays
on one line, under 160 characters. Check that OpenClaw found it with
openclaw skills list, type /new in the chat,
and then use /skill summary-style to call it by name.
The agent can also write skills for itself, through a feature called
Skill Workshop. Those skills apply at once, but each change keeps the
previous version, so you can review them with
openclaw skills workshop list and
openclaw skills workshop changes, and hide one with
openclaw skills workshop archive <name>.
Skills from ClawHub are someone else's code. OpenClaw's docs say to
treat third-party skills as untrusted code and read them before you turn
them on, and openclaw skills verify @owner/<slug>
shows ClawHub's check of a skill.
- You gain: repeated jobs get shorter and more consistent, and a skill you wrote yourself contains only what you put in it.
- You risk: a skill runs with the agent's full powers. A third-party skill can read your keys, and a skill the agent wrote for itself changes its behavior without asking you first.
- Makes sense when: you write the skill yourself and keep it to instructions, or you have read every line of a ClawHub skill first. Check Skill Workshop's changes now and then.
Tools from MCP servers
What it is for. An MCP server is a program or online service that lends the agent extra tools. One might search a particular website, and another might read a calendar. OpenClaw connects to the server and adds its tools to the agent's list.
How to turn it on. In the chat page, open Settings → MCP and select Add server under Configured servers. Give it a name, and pick a transport: Streamable HTTP, SSE, or Stdio. For the first two you enter the server's web address. For Stdio you enter a command, which means OpenClaw starts that program on your computer. Then check that it answers.
openclaw mcp doctor <name> --probe
Saving a server does not prove it works, and the docs say this check
is the proof. You can limit a server to some of its tools with the
--include option of openclaw mcp add, or the
tool filter in Settings. The docs also say a server's tools go through
the same tool rules as everything else, so connecting one does not get
around your settings. Keep passwords and keys out of the server's
settings, and use OpenClaw's secret storage instead.
- You gain: the agent can reach services and data it has no built-in tool for.
- You risk: a Stdio server is a program running as you, and an online server sees whatever the agent sends it. Tools that read email or calendars also open new paths for prompt injection.
- Makes sense when: the server comes from a source you trust, it does one clear job, and you have limited it to the tools that job needs. Do not connect one that can reach your email, bank, or files until you are well past the first week.
Several agents at once
What it is for. One Gateway can run several separate agents, each with its own workspace, its own settings, and its own chat history. That lets you keep a cautious agent apart from one you trust with more.
How to turn it on. Add an agent by name:
openclaw agents add work
Then check the list with
openclaw agents list --bindings. In the chat page, the
Agents page shows each agent, and Manage
agents changes them.
Each agent can have its own sandbox and tool limits, set under
agents.entries.*.sandbox and
agents.entries.*.tools. The docs' example gives a family
agent a sandbox mode of all and lets it use only the
read tool, denying exec, write,
edit, and apply_patch. For commands, each
agent's workspace is still only a starting place, not a wall, unless its
sandbox is on. An agent's own tools.fs.workspaceOnly
setting overrides the one from page 2, so never set it to
false for a new agent.
- You gain: you can give one agent a narrow, safe job and another a wider one, without mixing their memory or files.
- You risk: more agents mean more settings to check, and a new agent can read the keys you already saved. An agent with chat apps attached can be reached by whoever those apps let in.
- Makes sense when: you have a clear reason for each agent, such as a read-only agent for summaries. Give each new agent the narrowest tools and the strictest sandbox the job allows.
A local model with Ollama
What it is for. A local model runs on your own computer, so it costs nothing per use and your prompts stay on your machine.
How to turn it on. Install Ollama from ollama.com/download, then download a model:
ollama pull gemma4
Run openclaw onboard, choose Ollama,
and then choose Local only. Setup prefers a model that
supports tools and has at least 16K of context. Check that OpenClaw sees
it, then make it the main model:
openclaw models list --provider ollama
openclaw models set ollama/gemma4
After setup, run openclaw exec-policy show again to
confirm the approval switch still says ask, and
openclaw config get tools.fs.workspaceOnly to confirm the
file tools still say true.
OpenClaw's docs warn that smaller or heavily compressed models are easier to trick with a prompt injection. They recommend a large model for any agent with tools, and loop detection for smaller models, which Fixes shows how to turn on.
- You gain: no bill, no free-tier limit, and prompts that never leave your computer.
- You risk: a local model needs a lot of RAM, and it is weaker than the best cloud models. It is also more likely to follow hidden instructions on a web page, and more likely to loop.
- Makes sense when: your computer has plenty of RAM, the job is low-stakes and offline, and loop detection is on. Keep jobs that browse the web on a strong cloud model.
Shared advanced topics
These pages apply to every agent, and these are the ones that fit OpenClaw:
- Local models in depth, because OpenClaw works with Ollama and other local servers.
- Mix a cheap model with a strong one, because OpenClaw can keep backup models and switch models per chat.
- Host access and unattended runs, because OpenClaw runs on your real computer and has schedules built in.
- An always-on machine, because schedules and chat apps work only while the Gateway is running.
- Use a chat plan you already pay for, because OpenClaw can reuse Copilot, Claude, and ChatGPT sign-ins, and Google bans its Antigravity login.
- Relays and aggregators, because OpenClaw supports OpenRouter, which forwards your requests to other providers.
Sources
All checked 14 November 2026.
- Sandbox modes, Docker backend, and
openclaw sandbox explain: https://docs.openclaw.ai/gateway/sandboxing and https://docs.openclaw.ai/gateway/sandboxing/docker-backend - File tools in the sandbox, while add-ons and MCP tools stay on the Gateway: https://docs.openclaw.ai/gateway/sandboxing/supported-capability-matrix
tools.fs.workspaceOnly, its per-agent override, andopenclaw config get: https://docs.openclaw.ai/gateway/security/tool-permissions, https://docs.openclaw.ai/gateway/cli-backends, and https://docs.openclaw.ai/gateway/configuration- Building the sandbox image with
openclaw doctor --fix: https://docs.openclaw.ai/gateway/sandboxing/images-and-setup - Workspace access
none,ro, andrw, and avoidingnon-main: https://docs.openclaw.ai/gateway/sandboxing/workspace-access and the safety chapter - Elevated mode: https://docs.openclaw.ai/elevated
- Creating skills,
SKILL.md, and/skill: https://docs.openclaw.ai/tools/creating-skills - Skill Workshop, ClawHub installs, and
openclaw skills verify: https://docs.openclaw.ai/tools/skills - Skills and credential risk: https://docs.openclaw.ai/clawhub/security-audits
- MCP servers, Settings → MCP, and
openclaw mcp doctor: https://docs.openclaw.ai/tools/mcp - Several agents and per-agent limits: https://docs.openclaw.ai/concepts/multi-agent
- Ollama setup and
openclaw models set: https://docs.openclaw.ai/providers/ollama/setup - Small models and prompt injection: https://docs.openclaw.ai/help/faq-models
- Loop detection for smaller models: https://docs.openclaw.ai/tools/loop-detection
- Backup models: https://docs.openclaw.ai/help/faq-models
- Model routes, sign-ins, and the Antigravity ban: OpenClaw research notes
Next
Continue to Persona and rules.