Skip to content
Series
32 posts

Reading the OpenClaw Docs

Reading the 300+ official docs of OpenClaw, a self-hosted AI gateway, across 32 posts — installation and platforms, model providers, the agent runtime and memory, 24+ chat channels, sandboxing and threat model, tools and automation, gateway operations, plugins, and the user interfaces.

Series guide

OpenClaw Mobile Platforms: Phones Are Peripherals, Not Gateways — and the Apple Watch Has Its Own Transport

The iOS and Android apps are nodes, not Gateways: they do not run the Gateway service, and Telegram or WhatsApp messages land on the Gateway rather than on the phone. The Apple Watch is the exception — because watchOS blocks generic low-level networking for ordinary apps, it uses signed HTTPS polling instead.

OpenClaw's Model Requirements and Provider Ecosystem: Provider, Model, and Runtime Are Three Different Things

OpenClaw's hard requirement for a model is tool use plus a large enough context — onboarding only auto-suggests a local model when it confirms tool support and at least a 16K context window. The easier thing to get wrong is that provider, model, and agent runtime are three separate layers: an `openai/*` ref does not mean Codex.

OpenClaw Multi-Agent: An Agent Is a Whole Persona Boundary — and Agents Can Now Ask for New Agents

An agent is a complete persona scope — its own workspace, auth profiles, model registry, and session store. But the isolation is not absolute: when a secondary agent's OAuth credential expires, OpenClaw reads through to the main agent's profile of the same id, and a workspace is only a default working directory, not a hard sandbox.

OpenClaw Agent Runtime: The System Prompt Is Assembled, and a Cache Boundary Cuts It in Half

OpenClaw builds its own system prompt for every run; there is no runtime default prompt. What it builds is split by an internal cache boundary — the stable workspace prefix above, the per-turn channel context below — so backends with prefix caches can reuse the same prefix across channels.

The OpenClaw Agent Loop: Serialization, Writer Claims, and the Fence That Stops a Stale Turn From Committing

The agent loop is a serialized per-session run. The part worth studying is how it handles concurrency: an admitted run records an activeWriterRunId claim, every transcript write supplies expectedWriterRunId, and the commit transaction verifies the match — so a superseded run cannot commit stale data.

OpenClaw Sessions and Memory: One Rolling Conversation, Plus Four Files That Get Written to Disk

By default every DM lands in one main session, and group activity and background work report back into it. Memory is entirely Markdown on disk — the model only remembers what gets saved, with no hidden state. But if more than one person can DM your agent, DM isolation is something you have to turn on.

OpenClaw Channels Overview: 31 Channels, Nearly All Plugins — and Why 'Who Can Trigger' Is Not 'What the Model Sees'

OpenClaw supports 31 chat channels, but only WebChat lives in core — even Slack and WhatsApp are plugins you install. And group safety has two independent axes: allowlists govern who can trigger the agent, not which quotes and history the model sees. That second one is contextVisibility, and it defaults to wide open.

OpenClaw Enterprise Channels: Slack's Three Transports, and the 'Built-in' Column That No Longer Exists

Every enterprise channel is a plugin now, including Slack and Google Chat, which used to be built in. Slack has three transports — Socket Mode, HTTP Request URLs, and relay — and the docs say plainly that the first two have reached feature parity, so you pick by deployment shape, not by features.

OpenClaw Sandboxing: Four Backends, Three Independent Switches, and Thinking You're Sandboxed When You Aren't

Sandboxing is governed by three independent settings: mode (when it applies), scope (how many containers), and backend (where it runs). The most common failure is an expectation gap — `tools.exec.host` now defaults to auto, so 'unset means sandboxed' is no longer true, and the security audit has a check specifically for it.

OpenClaw Access Control: SecretRef Is Not Process Isolation — Here's What It Actually Solves

SecretRefs keep credentials out of plaintext config, and the model-call chain sees process-local sentinels instead of the real value. But the docs say it plainly: this is not process isolation — the real value still exists in the same process's memory, and any plaintext file the agent can read bypasses the whole mechanism.

OpenClaw Automation, Part 1: Choosing Among Six Mechanisms, and Why 'Exactly on Time' and 'Check on It' Are Different Jobs

Cron is now called Automations (openclaw cron remains an alias), and automation spans six mechanisms. The core trade-off is one line: Automations give you exact timing and isolated execution, Heartbeat gives you full main-session context on a roughly-every-30-minutes cadence.

The OpenClaw Plugin System: Treat Installs Like Running Code, and a Cold Check Proves Nothing About Runtime

The official framing is to treat plugin installs like running code — ClawHub and the bundled catalog are trusted sources, while arbitrary npm, git, and local paths require --force in noninteractive installs. And verification means inspect --runtime, because a bare inspect is only a cold manifest check.