How to Use OpenClaw More Effectively (and Safely)

Quick answer: OpenClaw is Peter Steinberger's free, open-source, local-first personal AI agent that runs on your own Mac and answers you through messaging apps like WhatsApp, Telegram, and iMessage. It is not the unrelated Captain Claw game-engine project of the same name. The thing to understand before you install it is the security model: by default its tools run directly on your machine with full access, sandboxing is off until you turn it on, and the maintainers say plainly that prompt injection is an unsolved problem. Used carefully, with sandboxing on and clear instructions, it is powerful. Used carelessly, one bad injection can run code or delete files on your computer.

If you have seen "OpenClaw" going around in 2026, it is worth knowing there are two unrelated projects with that exact name, and this guide is only about one of them.

The OpenClaw this article covers is Peter Steinberger's open-source personal AI agent, at github.com/openclaw/openclaw. It is a program you run on your own machine that can use tools, run shell commands, and answer you through the messaging apps you already use. The other OpenClaw is an open-source reimplementation of the game engine behind the 1997 Captain Claw platformer, a C++ project with nothing to do with AI. Same name, totally different thing. Everyone else, read on, because the AI one is genuinely powerful and genuinely worth being careful with.

What OpenClaw actually is

Strip away the hype and OpenClaw is a self-hosted, local-first personal AI agent. It is free, MIT-licensed, and community-driven, created by Steinberger (who cheerfully calls himself the "Clawfather"). It runs on macOS, Windows, or Linux, and a defining choice is that your state lives on your machine, not in a vendor cloud. It is also model-agnostic and bring-your-own-key, so you point it at Anthropic, OpenAI, Google, or a local model, whatever you want to run and pay for.

The part that makes it feel different from a chatbot is how you talk to it. Instead of a dedicated app, you drive OpenClaw through consumer messaging apps. It advertises support for a large number of channels, WhatsApp, Telegram, Discord, Slack, Signal, iMessage, Microsoft Teams, and more, so in practice it is an assistant you text like a person. Only a few channels ship in the core install; most are one-command plugins you add.

Under the hood, all of that runs through a single local process called the Gateway. The Gateway is a local-first control plane, listening on a loopback port on your own machine, and it is the single source of truth for sessions, routing, and channel connections. In OpenClaw's own framing, the Gateway is just the control plane and the real product is the assistant it routes messages to.

And that assistant has real tools. It can read and write files, run shell commands, execute scripts, browse the web (filling forms and extracting data from pages), and run web searches. This is the whole point and also the whole risk: it is not answering questions in a sandboxed chat window, it is doing things on your computer.

Two more pieces are worth knowing. OpenClaw has a skills system: skills are SKILL.md directories, plain markdown with a bit of YAML frontmatter, that teach the agent reusable procedures. You can write your own, install them from the community registry (ClawHub), or have the agent draft one for you, with agent-authored skills routed through a review queue rather than written silently. And it has persistent local memory: each agent keeps a local database on disk so facts carry across sessions instead of being re-explained every time.

Installing and setting it up

Installation is light. OpenClaw is an npm package, so you run npm i -g openclaw and then openclaw onboard. The onboarding flow walks you through choosing a model provider, entering an API key, and configuring the Gateway. OpenClaw estimates about five minutes to a running Gateway, configured auth, and a working chat session. Take the five minutes as the vendor's own best case: it is the time to a basic session, and pairing every messaging channel plus installing the background daemon can take longer.

Because this project is young and moved fast, treat the exact commands, file paths, and config keys as current-as-of-writing and check them against the version you install. More on that in a moment, because it matters more here than for most tools.

The security model, stated honestly

This is the section you cannot skip. An always-on agent that can run shell commands on your machine and is reachable from your chat apps is a fundamentally different risk category from a chatbot, and OpenClaw's own documentation is refreshingly direct about it.

Start with the default. By default, for your own solo session, the agent's tools run directly on the host. That means full access to your machine. Docker-backed sandboxing exists, but it is off by default and opt-in. When you do turn it on, only the tool execution (the shell commands, the file reads and writes) moves into isolated containers, while the Gateway process itself always stays on the host. Group and shared sessions are treated as untrusted and get sandboxed when sandboxing is enabled.

Now the honest part, in the maintainers' own words. The docs say the sandbox is "not a perfect security boundary," only something that "materially limits filesystem and process access when the model does something dumb." They also state plainly that prompt injection is still an unsolved, industry-wide problem, and that the right response is to use strong models and follow security best practices, not to pretend it is solved. Read that carefully. It means a single malicious prompt injection, hidden in a web page the agent reads, a file it opens, or a message it receives, can escalate from manipulating a chat reply into real remote code execution, arbitrary file deletion, or quietly exfiltrating your data. That is not a hypothetical: a specific one-click flaw, tracked as CVE-2026-25253, was documented and patched, and it sits alongside the broader, unpatched-by-nature category of injection-to-tool-misuse.

So what do you actually do about it?

Turn sandboxing on for anything that is not just you. The moment other people or untrusted channels can reach the agent, run its tools inside the Docker sandbox rather than on the host. The official Docker image is set up sensibly for this, running as a non-root user with a hardened, network-restricted default.

Never mount the host Docker socket into the sandbox. The docs call this out explicitly, and it is the one mistake most likely to undo everything. The sandbox's isolation comes from container namespaces; mounting the host Docker socket hands the agent host-level root and defeats the entire boundary. OpenClaw blocks the obvious socket paths by default, but do not go out of your way to expose it.

Be deliberate about what you connect and expose. Every messaging channel you wire up is another door into an agent with machine access, and every data source you point it at is a possible injection vector. Fewer doors, fewer problems. Do not connect an agent with shell access to a public or shared channel and walk away.

Use a strong model. Because model quality is one of your only real defenses against an injection, this is a place not to cut corners. OpenClaw lets you switch providers freely, so run something capable.

Write crisp SKILL.md skills. Clear, tightly scoped skills give the agent a reliable, reviewed way to do the things you actually want, which reduces how often it improvises with raw shell commands.

It is young, and it keeps changing

One more caution that colors everything above. OpenClaw is a very new project, first published in late 2025, and it was renamed twice in early 2026: it started as Warelay, became Moltbot, and then became OpenClaw. A project moving that fast changes its file paths, config keys, and defaults between versions. So the specifics here, and anywhere else you read about it, may have drifted by the time you install. Any star counts or skill-registry totals you see quoted are point-in-time snapshots, not fixed facts. Verify the security-relevant settings, especially the sandbox configuration, against your installed version's own docs before you trust them. With a tool that can run code on your machine, "I read this somewhere" is not good enough.

Where dictation fits

Here is the throughline. An agent this capable is only ever as safe and as useful as the instruction you hand it. A vague instruction to a tool with shell access is how you get work you did not want, or worse. A specific one, the exact file, the exact constraint, the exact thing to do and the exact thing never to do, is how you get what you meant.

The catch is the same one that trips people up with any agent: the specific instruction is the long one, and typing the long one feels like work, so people trim it down. They send "clean up my downloads folder" instead of the two sentences naming which files, which extensions, and what absolutely not to touch. With a normal app that just produces a worse answer. With an agent that runs commands, the missing sentence is the one that mattered.

Talking is the cheapest way to make the complete instruction the easy one. When you can say the whole thing out loud, the full scope, the guardrails, the "and do not delete anything in this folder," you tend to actually include it, instead of shrinking it to fit what you are willing to type. That is the same argument we make more broadly in whether talking to AI beats typing, and it is exactly why we walk through it for another agent in how to use Hermes Agent.

That is what Ducktate is for. You hold a key and talk your full, specific instruction into a chat window or a note, and it transcribes on your Mac, so the audio never leaves your computer. You are not trying to talk faster than you type. You are trying to give a powerful agent the complete, careful instruction it needed, because with this class of tool, the details you leave out are the ones that bite you.