What Is OpenClaw? The Self-Hosted AI Assistant, Explained

Most AI assistants live behind a tab. You open a website, type into a box, read the answer, close the tab. The assistant knows nothing about your filesystem, can’t act while you’re asleep, and forgets you the moment the session ends. It is a very capable stranger you have to re-introduce yourself to every morning.

OpenClaw takes the opposite position. It is an open-source personal AI agent that runs on hardware you control, keeps its memory as plain files on your disk, and reaches you through the messaging apps you already have open — WhatsApp, Telegram, Slack, Discord, Signal, iMessage. You text it like a person. It texts back. And because it’s a process running on your machine rather than a page you visit, it can keep working when you’re not looking.

That last property is the one people underestimate, and it’s also the one that makes this a genuinely different kind of tool with a genuinely different risk profile. This guide starts there.

The One-Paragraph Definition

OpenClaw is an MIT-licensed personal AI agent, created by PSPDFKit founder Peter Steinberger, that you install on your own Mac, Linux box, or Windows machine via WSL2. A local process called the Gateway connects a large language model (Claude, GPT, a local model — your choice) to a set of tools (shell, filesystem, browser, calendar, HTTP) and a set of messaging channels. You send it a message from your phone; the Gateway routes that message into an agent session, the model decides which tools to call, the tools run on your machine, and the reply comes back to the same chat thread.

It shipped under two earlier names — Clawdbot, then Moltbot — before settling on OpenClaw, which is why search results are a confusing archaeology of three names for one project. They are the same thing.

Three Properties That Actually Distinguish It

Plenty of projects claim to be “an open-source AI assistant.” Most are a chat UI wrapped around an API key. OpenClaw is structurally different in three specific ways, and understanding them is the difference between using it well and being surprised by it.

1. It is local-first, not local-optional

The Gateway runs on your machine. Your configuration lives at ~/.openclaw/openclaw.json. Memory and workspace files are Markdown and JSON on your disk, readable with cat, diffable with git, deletable with rm. There is no vendor account holding your assistant’s history hostage.

This is not merely a privacy talking point. It has a practical consequence: you can inspect and edit what your assistant believes. When it gets something wrong about you, you open a file and fix the sentence. Compare that to trying to correct a hosted assistant’s mental model of you through conversation alone.

The model itself is usually still a hosted API call — you’re sending prompts to Anthropic or OpenAI unless you’ve wired up a local model. Local-first describes the control plane and the data, not necessarily the inference.

2. It is chat-native, not app-native

There is no OpenClaw app you must open. There is a Control UI in the browser for configuration, but the primary interface is a chat thread in software you already use. This sounds cosmetic. It isn’t.

The friction cost of “open a new app, wait for it to load, find the right conversation” is what kills most personal-automation tools. They work for two weeks and then you stop opening them. An assistant that answers in the same thread where your partner is asking what’s for dinner has effectively zero activation energy. You use it because using it costs nothing.

It also means the assistant is reachable from a locked phone on a train, which is where most of the useful requests actually happen.

3. It is scheduled, not just reactive

This is the property that turns a chatbot into an agent. OpenClaw supports cron jobs and a heartbeat — a recurring wake-up where the agent gets a turn to think and act without anyone having prompted it. You can also expose webhooks, so external systems can poke it.

A reactive assistant answers questions. A scheduled one can notice things: that an invoice hasn’t been paid, that a certificate expires in nine days, that you said you’d follow up with someone on Tuesday and it’s now Thursday. The value shifts from “saves me typing” to “catches things I would have dropped.”

It is also, obviously, the property that means an unattended process on your machine is making decisions and calling tools while you sleep. Hold that thought.

What a Day Actually Looks Like

Abstract descriptions of agents are useless. Here is a concrete, unremarkable sequence — the kind of thing people actually end up using it for after the novelty wears off.

07:40 — Heartbeat fires. The agent checks a calendar tool, notices you have a 09:00 that requires a 40-minute drive, cross-references a traffic API, and sends you a WhatsApp message: “Leaving by 08:05 for the Henderson meeting — traffic is 15 min worse than usual.” You didn’t ask. That’s the point.

11:15 — You text from your phone: “what’s eating disk on the build server?” The agent SSHes in (because you gave it a tool that can), runs du, and replies with the top five directories and a note that the Docker overlay directory has grown 12 GB since Friday.

14:30 — You forward it a PDF contract in Telegram. “summarise the termination clauses.” It reads the attachment and answers in the thread.

18:00 — A cron job you set up weeks ago runs. It pulls your open pull requests, finds two with review comments you haven’t answered, and drops a short list in your Slack DM.

22:50 — You text: “remind me tomorrow that the Henderson quote needs revising.” It writes that to its memory file. Tomorrow’s heartbeat surfaces it.

None of these are impressive individually. Collectively, they’re a competent assistant. And every single one required the agent to have real access to real systems — which is the whole bargain.

The Architecture in One Diagram

You don’t need the full internals yet, but the shape matters because almost every configuration question later maps onto one of these boxes.

The Gateway is the piece that matters most. It is the local control plane: it owns sessions, decides which messages are allowed in, holds the tool policy, runs the scheduler, and multiplexes WebSocket and HTTP on a single port (18789 by default). Every security decision in this guide is ultimately a Gateway decision.

Everything else plugs into it. Channels are adapters. Agents are configurations. Tools are capabilities. The Gateway is the thing standing between an inbound text message and a shell command running as your user.

What OpenClaw Is Not

Being clear about this saves a lot of disappointment.

It is not a multi-tenant product. The documented trust model is explicitly one trusted operator per Gateway — a personal assistant, not a shared team bot. You can let other people message it, but you are then trusting them roughly as much as you trust yourself, unless you have done real isolation work. It is not designed to be adversary-resistant against people who are supposed to be using it.

It is not a coding agent. There is overlap — it can edit files and run commands — but tools like Claude Code are purpose-built for repository work with much better ergonomics for that job. OpenClaw’s centre of gravity is life-and-ops automation reachable from your pocket. If you want to know how to give a coding agent persistent project context, that’s a different tool with a different config file.

It is not zero-maintenance. It’s a fast-moving open-source project. Configuration keys change. Channels break when upstream APIs shift. Treat it as infrastructure you maintain, not an appliance.

It is not free of running costs. The software is free; the model calls are not. A heartbeat that fires every 30 minutes and thinks for a few thousand tokens each time is a real monthly bill. Budget deliberately — this catches people out.

The Bargain You Are Making

Here is the part most introductions skip, and it’s the most important paragraph on this page.

An OpenClaw agent that is useful is an agent that can execute shell commands, read and write your files, reach network services, and send messages as you. An inbound WhatsApp message is untrusted input that ends up in the context window of a model that holds those capabilities. So does the content of any webpage it fetches, any email it reads, any log you paste, any PDF you forward.

This is the prompt injection problem, and it is not solved by asking the model nicely in a system prompt. The project’s own documentation is refreshingly blunt about this: hard enforcement comes from tool policy, execution approvals, sandboxing, and channel allowlists — layered — not from instructions.

Which is why the defaults are conservative. DM-capable channels default to a pairing policy: an unknown sender gets a one-time code, and nothing happens until you approve it from the CLI. The Gateway binds to loopback. Group chats require an explicit mention. These defaults exist because the failure mode isn’t theoretical — it’s someone messaging your bot and it simply doing what they asked.

The honest framing: you are trading a meaningful increase in attack surface for a meaningful increase in capability. That’s a reasonable trade for many people. It is a bad trade if you install it, wire up every tool, open the Gateway to your LAN, and never think about it again.

Who Should Run This

Good fit if you:

• Are comfortable in a terminal and reading logs when something breaks
• Already self-host things and have opinions about where your data lives
• Have repetitive multi-step chores that touch systems an API-only assistant can’t reach
• Want to actually understand how agent systems work, from the inside

Poor fit if you:

• Want an assistant that works perfectly out of the box with no maintenance
• Would be storing genuinely sensitive third-party data with no plan for isolation
• Can’t currently articulate what “sandboxing” would mean for your setup
• Are looking for a team tool — that is not what this is

There’s an honest middle path worth naming: run it with a deliberately narrow tool set. Messaging and read-only tools, no shell, no browser. You lose the flashiest demos and keep most of the daily value, at a fraction of the risk. Starting there and expanding as you build confidence is a genuinely better plan than starting wide and hoping.

What You Need Before Starting

A short checklist:

• A machine that stays on. A Mac mini, a home server, a small VPS, or a laptop you rarely close. An assistant that’s asleep half the day is a worse assistant.
• A supported Node.js runtime. Node 22.22.3+, 24.15+, or 25.9+ — the installer can provision one for you if your system Node is the wrong vintage.
• An API key for a model provider, or a local model already running.
• One messaging account you’re willing to connect. Telegram is the gentlest first choice: bot tokens are trivial to get and nothing is tied to your personal phone number.
• Thirty minutes, and the willingness to read the security page before you widen anything.

Where to Go Next

The natural order through this series is:

1. Installing OpenClaw — onboarding, Node versions, and the first successful message.
2. How OpenClaw Works — the Gateway, sessions, agents and nodes in proper detail.
3. Understanding openclaw.json — the config file, section by section.

If you only take one idea from this page: OpenClaw is not a smarter chatbot, it’s a small autonomous process with your permissions. Set it up like you’d set up anything else with your permissions — narrowly at first, and widened only on purpose.