OpenClaw is the AI that actually does things. It runs on your devices, in your channels, with your rules.
This document explains the current state and direction of the project.
We are still early, so iteration is fast.
Project overview and developer docs: README.md
Contribution guide: CONTRIBUTING.md
OpenClaw started as a personal playground to learn AI and build something genuinely useful: an assistant that can run real tasks on a real computer. It evolved through several names and shells: Warelay -> Clawdbot -> Moltbot -> OpenClaw.
The goal: a personal assistant that is easy to use, supports a wide range of platforms, and respects privacy and security.
OpenClaw is a great personal assistant and a great team assistant. A personal install is yours alone; a shared Gateway is a place people work together, so the same session can carry several humans, their credit, and their history. We build OpenClaw with OpenClaw on team.openclaw.ai, and we sometimes invite visitors there.
Run OpenClaw locally or on your own infrastructure. Hosted services and shared sign-in should simplify setup and account linking, but stay optional.
Our priorities, in order:
Quality and developer experience:
- Security and safe defaults
- Bug fixes, stability, reliable updates, and clear errors
- Easy, reliable first-run setup across CLI, web, and apps
- Performance, reliable end-to-end tests, and clear plugin APIs, tools, and docs
Runtime:
- Reliable sessions, automations, and subagents
- Simpler memory and knowledge
- All major model providers
- Reliable major messaging channels, plus a few high-demand additions
- Better computer use and agent harnesses
Operations and apps:
- Reliable self-hosting and optional hosted services
- Efficient infrastructure, CI, and releases
- Usability and consistency across CLI, web, and apps on macOS, iOS, Android, Windows, and Linux
Errors should explain what went wrong and what to do next. Show what ran, failed, or was canceled, and how to recover after an interruption.
Contribution rules:
- One PR = one issue/topic. Do not bundle multiple unrelated fixes/features.
- PRs over ~5,000 changed lines are reviewed only in exceptional circumstances.
- Do not open large batches of tiny PRs at once; each PR has review cost.
- For very small related fixes, grouping into one focused PR is encouraged.
Configuration compatibility:
OpenClaw runtime code reads the current configuration schema only. We do not keep long-lived aliases or compatibility branches that silently accept old, renamed, or malformed config keys.
When a config change makes existing user config invalid, the same change needs a doctor migration.
openclaw doctor --fix should detect the old shape, explain it, back it up when needed, and rewrite it to the current format.
Core-owned config and auth state are repaired in core doctor code; plugin-owned config is repaired by that plugin's doctor contract.
Security in OpenClaw is a deliberate tradeoff: strong defaults without killing capability. The goal is to stay powerful for real work while making risky paths explicit and operator-controlled.
A shared Gateway is for people who trust each other. Mutually untrusted users need separate Gateways, host or container isolation, and access controls.
Security policy and reporting:
We prioritize secure defaults, but also expose clear knobs for trusted high-power workflows.
Privacy follows the same default rule. OpenClaw sends no usage analytics, tracking identifiers, or telemetry attribution to the project unless the operator turned that on themselves. This rule governs what leaves your install. It is not a rule about shared Gateways: when you join a team Gateway, the people you share it with see the work you do there, and features like Git co-author credit exist to attribute that work to you. The setup wizard offers optional anonymous feature statistics, with no selected by default; the daily update check reports version and platform and can be disabled. See Usage telemetry and update checks.
OpenClaw has an extensive plugin API. Core stays lean; optional capabilities should usually ship as plugins. We are generally slimming down core while expanding what plugins can do. If a useful feature cannot be built as a plugin yet, we welcome PRs and design discussions that extend the plugin API instead of adding one-off core behavior.
Two layers, two bars. The core carries a per-call tax: each core tool, prompt line, and config key reaches every operator on every model request, so additions there face the strictest scrutiny. Plugins, skills, channels, and apps carry no such tax, and we want that surface to keep growing. When our contribution rules read as hostile to a feature, re-check the layer: usually they object to where it plugs in, not to the feature existing.
Recurring demand defines interfaces. Once several independent PRs or requests wire in the same kind of capability, the right response is a contract, not a queue of merges: add the shared interface in core or the SDK, update the bundled implementation to use it, and let the remaining candidates ship as plugins against it.
There are two broad plugin styles:
- Code plugins run OpenClaw plugin code and are appropriate for deeper runtime extension.
- Bundle-style plugins package stable external surfaces such as skills, MCP servers, and related configuration.
Prefer bundle-style plugins when they can express the capability. They have a smaller, more stable interface and better security boundaries. Use code plugins when the capability needs runtime hooks, providers, channels, tools, or other in-process extension points.
Preferred plugin path is npm package distribution plus local extension loading for development.
If you build a plugin, host and maintain it in your own repository.
The bar for adding optional plugins to core is intentionally high.
Plugin docs: docs/tools/plugin.md
Plugin discovery, official publisher status, provenance, and security review live in ClawHub.
OpenClaw docs should document core extension points; plugin promotion belongs in ClawHub, preferably under vetted org publishers for official plugins.
Memory is a special plugin slot where only one memory plugin can be active at a time. Today we ship multiple memory options; over time we plan to converge on one recommended default path.
We still ship some bundled skills for baseline UX. New skills should be published through ClawHub first, not added to core by default. Official or bundled promotion should require a clear product, security, or maintainer-ownership reason.
OpenClaw supports MCP as both a server and a runtime integration surface.
MCP details live in docs/cli/mcp.md.
The project goal is pragmatic MCP support without duplicating existing agent, tool, ACPX, plugin, or ClawHub paths.
Keep CLI setup and daily use fully supported. Make browser and app onboarding easier. All setup flows should use safe defaults and explain authentication, permissions, and security choices.
Translate CLI and app text, including errors and setup guidance. Keep commands, identifiers, and protocol values unchanged. Full-document translations remain deferred.
OpenClaw is primarily an orchestration system: prompts, tools, protocols, and integrations. TypeScript was chosen to keep OpenClaw hackable by default. It is widely known, fast to iterate in, and easy to read, modify, and extend.
- New core skills when they can live on ClawHub
- Full-doc translation sets for all docs (deferred; we plan AI-generated translations later)
- Vendor-specific service integrations in core; use plugins or companion projects
- Cloud-based sandbox providers as OpenClaw plugins; implement provider support in Crabbox instead
- Wrapper channels around already supported channels without a clear capability or security gap
- MCP work that duplicates existing MCP, ACPX, plugin, or ClawHub paths without a clear product or security gap
- Heavy orchestration layers that duplicate existing agent and tool infrastructure
This list is a roadmap guardrail, not a law of physics. Strong user demand and strong technical rationale can change it.