fa9c3209d3
* fix(outbound): keep queued TTS/local media alive past its producer process Outbound TTS synthesizes into a producer-owned temp and the raw path is persisted into the durable delivery queue with no copy. The temp is removed when its producer exits (and by a 5-minute timer well inside the queue's ~22-minute retry budget), so a deferred delivery replayed by a fresh recovery process reads a path whose owner already deleted it: the send burns all five retries on a missing file and the voice is never delivered. Give the queue its own copy. Before a deliverable row is published, each authorized local source is read through the same media access the live send uses and copied into a process-generation-owned artifact root outside the media TTL sweep; only the queue payload is rewritten, so the live send stays copy-free on the original path. Custody is proven by owner identity rather than by a marker file or lease table: artifacts are grouped under <pid>-<processStartTime>-<nonce>, and reclaim touches a generation only when its owner is provably gone. A live owner, an unverifiable owner, or a recycled PID whose start time no longer matches are all handled without deleting media that a pending row still needs. Wall-clock age is never an ownership signal. Ordering is durable-state-first: rows commit before artifacts are unlinked, so a crash between the two leaves an orphan for reclaim rather than a delivery that lost its media. Sensitive media reaches neither the spool nor the row, so required sends fail closed and best-effort sends go live-only instead of persisting a row that cannot replay. No schema change, no public SDK surface, no lease/owner table. * fix(outbound): resolve queue media owner identity on every platform Generation ownership read process start time through the Linux/Darwin lock reader only, so on Windows every generation stayed unverifiable and its artifacts were never reclaimed. gateway-lock already paired that reader with the Windows CIM/WMIC creation-time reader behind its own private helper, so the pairing was duplicated policy waiting to drift. Move the pair behind one owner-identity helper and route both callers through it. No new process inspection: Windows still resolves through readWindowsProcessStartTimeSync, Linux/Darwin still through getFileLockProcessStartTime, and neither platform's behavior changes. Also cover the production crash boundary end to end: a real child process stages media, commits the row, and is killed before dispatch; a fresh process then reclaims the dead generation while retaining the artifact its pending row still needs, reads the same bytes after the producer's source is deleted, and drops the artifact once the row is acked. * fix(outbound): close reclaim race and partial-stage leak in queue media Two defects found by external review of the previous commits. Reclaim built its retain set before proving generation ownership, so a short-lived producer (`openclaw message send`) that staged, committed its row, and exited while a sweep was running would have its artifact judged against a snapshot taken before that commit: the sweep saw a dead owner, missed the new reference, and unlinked media a pending row still needed. The retain set is now read after each death proof. That is sufficient rather than merely narrower: a process only ever stages into its own generation, so once an owner is proven dead no further references to it can appear, and everything it committed before exiting is already durable. Staging also leaked on partial failure. When a later source in an entry failed, earlier copies were already published, no row would ever reference them, and reclaim deliberately never touches a live owner's generation, so they accumulated for the process lifetime. Failed staging now releases what it published. Per-payload media staging is sequential for the same reason: a concurrent copy could land after the cleanup ran and orphan itself anyway, and one source at a time also bounds peak memory. * fix(outbound): resolve queue media access exactly as the live send does Queue staging read media through params.mediaAccess directly, while the live send resolves an agent-scoped capability first. The two gates therefore disagreed: agent-generated media under the agent workspace is reachable only through the agent-scoped roots, so staging rejected sources the send itself would have delivered. A required send failed outright, and a best-effort send silently lost its write-ahead row for exactly the media class this change is meant to protect. Resolve the capability once and share it, so staging can neither reject media the send would deliver nor read more than the send may. The live send now routes through the same helper rather than keeping a second copy of the argument list. The spool test previously fabricated an explicit localRoots and placeholder bytes, which hid the gap; it now uses the production shape (no explicit media access, source in the OpenClaw temp root that TTS writes to) and real buffer-verifiable audio, because host-local sends are content-verified. * test(outbound): cover agent-workspace media that only the scoped capability reads The existing staging test used a source in the OpenClaw temp root, which both the raw and the agent-scoped capability permit, so it could not tell the two apart and would have passed against the defect it was meant to guard. Add a case whose source lives in an agent workspace at <state>/workspace-<agentId>. The unscoped default roots reject that path by construction, so a durable row exists only when staging resolves the same agent-scoped capability the live send resolves. Reverting staging to the raw media access, or bypassing the shared resolver, fails this test. * test(outbound): pin agent-workspace staging to the agent-scoped capability The regression case admitted its source two ways that had nothing to do with agent scoping: the state dir sat inside the OpenClaw temp root, which is itself a default media root, and parent-root expansion grants any declared source directory. Either would keep the test green after the agent identity was dropped from the resolver. Move the state dir outside the temp root and set tools.fs.workspaceOnly, which suppresses source-derived root expansion. The agent workspace is then reachable only through the agent-scoped capability, so removing the agent identity, the shared resolver, or reverting to the raw media access each fail the test. * test(gateway): pin queue media retention across retry backoff * fix(outbound): retain queued media for retries Co-authored-by: Masato Hoshino <g515hoshino@gmail.com> * fix(outbound): retain queued media for retries Co-authored-by: Masato Hoshino <g515hoshino@gmail.com> * fix(outbound): retain queued media for retries Co-authored-by: Masato Hoshino <g515hoshino@gmail.com> * docs(changelog): avoid queued TTS merge conflict Co-authored-by: Masato Hoshino <g515hoshino@gmail.com> --------- Co-authored-by: Peter Steinberger <steipete@gmail.com> Co-authored-by: Peter Steinberger <peter@steipete.me>
🦞 OpenClaw — Personal AI Assistant
OpenClaw is a personal AI assistant you run on your own devices. It answers you on the channels you already use. It can speak and listen on macOS/iOS/Android, and can render a live Canvas you control. The Gateway is just the control plane — the product is the assistant.
If you want a personal, single-user assistant that feels local, fast, and always-on, this is it.
Supported channels include: WhatsApp, Telegram, Slack, Discord, Google Chat, Signal, iMessage, IRC, Microsoft Teams, Matrix, Feishu, LINE, Mattermost, Nextcloud Talk, Nostr, Synology Chat, Tlon, Twitch, Zalo, Zalo Personal, WeChat, QQ, WebChat.
Website · Docs · Vision · Third-party notices · DeepWiki · Getting Started · Updating · Showcase · FAQ · Onboarding · Nix · Docker · Discord
New install? Start here: Getting started
Preferred setup: run openclaw onboard in your terminal.
OpenClaw Onboard guides you step by step through setting up the gateway, workspace, channels, and skills. It is the recommended CLI setup path and works on macOS, Linux, and Windows.
Windows desktop users can start with the native Windows Hub companion app for setup, tray status, chat, node mode, and local MCP mode.
Works with npm, pnpm, or bun.
Sponsors
|
|
|
|
|
|
Subscriptions (OAuth):
- OpenAI (ChatGPT/Codex)
Model note: while many providers and models are supported, prefer a current flagship model from the provider you trust and already use. See Onboarding.
Install (recommended)
Runtime: Node 24.15+ (recommended), Node 22.22.3+, or Node 25.9+.
npm install -g openclaw@latest
# or: pnpm add -g openclaw@latest
openclaw onboard --install-daemon
OpenClaw Onboard installs the Gateway daemon (launchd/systemd user service) so it stays running.
Quick start (TL;DR)
Runtime: Node 24.15+ (recommended), Node 22.22.3+, or Node 25.9+.
Full beginner guide (auth, pairing, channels): Getting started
Recommended daemon mode:
openclaw onboard --install-daemon
openclaw gateway status
Foreground/debug mode:
openclaw gateway stop
openclaw gateway --port 18789 --verbose
Send a test message or ask the assistant after either startup mode is running:
# Send a message
openclaw message send --target +1234567890 --message "Hello from OpenClaw"
# Talk to the assistant (optionally deliver back to any connected channel: WhatsApp/Telegram/Slack/Discord/Google Chat/Signal/iMessage/IRC/Microsoft Teams/Matrix/Feishu/LINE/Mattermost/Nextcloud Talk/Nostr/Synology Chat/Tlon/Twitch/Zalo/Zalo Personal/WeChat/QQ/WebChat)
openclaw agent --message "Ship checklist" --thinking high
Upgrading? Updating guide (and run openclaw doctor).
Models config + CLI: Models. Auth profile rotation + fallbacks: Model failover.
Security defaults (DM access)
OpenClaw connects to real messaging surfaces. Treat inbound DMs as untrusted input.
Full security guide: Security. Before remote exposure, use the Gateway exposure runbook.
Default behavior on Telegram/WhatsApp/Signal/iMessage/Microsoft Teams/Discord/Google Chat/Slack:
- DM pairing (
dmPolicy="pairing"/channels.discord.dmPolicy="pairing"/channels.slack.dmPolicy="pairing"; legacy:channels.discord.dm.policy,channels.slack.dm.policy): unknown senders receive a short pairing code and the bot does not process their message. - Approve with:
openclaw pairing approve <channel> <code>(then the sender is added to a local allowlist store). - Public inbound DMs require an explicit opt-in: set
dmPolicy="open"and include"*"in the channel allowlist (allowFrom/channels.discord.allowFrom/channels.slack.allowFrom; legacy:channels.discord.dm.allowFrom,channels.slack.dm.allowFrom).
Run openclaw doctor to surface risky/misconfigured DM policies.
Highlights
- Local-first Gateway — single control plane for sessions, channels, tools, and events.
- Multi-channel inbox — WhatsApp, Telegram, Slack, Discord, Google Chat, Signal, iMessage, IRC, Microsoft Teams, Matrix, Feishu, LINE, Mattermost, Nextcloud Talk, Nostr, Synology Chat, Tlon, Twitch, Zalo, Zalo Personal, WeChat, QQ, WebChat, macOS, iOS/Android.
- Multi-agent routing — route inbound channels/accounts/peers to isolated agents (workspaces + per-agent sessions).
- Voice Wake + Talk Mode — wake words on macOS/iOS and continuous voice on Android (ElevenLabs + system TTS fallback).
- Live Canvas — agent-driven visual workspace with A2UI.
- First-class tools — browser, canvas, nodes, cron, sessions, and Discord/Slack actions.
- Companion apps — Windows Hub, macOS menu bar app, and iOS/Android nodes.
- Onboarding + skills — onboarding-driven setup with bundled/managed/workspace skills.
Security model (important)
- Default: tools run on the host for the
mainsession, so the agent has full access when it is just you. - Group/channel safety: set
agents.defaults.sandbox.mode: "non-main"to run non-mainsessions inside sandboxes. Docker is the default sandbox backend; SSH and OpenShell backends are also available. - Typical sandbox default: allow
bash,process,read,write,edit,sessions_list,sessions_history,sessions_send,sessions_spawn; denybrowser,canvas,nodes,cron,discord,gateway. - Before exposing anything remotely, read Security, Gateway exposure runbook, Sandboxing, and Configuration.
Operator quick refs
- Chat commands:
/status,/new,/reset,/compact,/think <level>,/verbose on|off,/trace on|off,/usage off|tokens|full,/restart,/activation mention|always - Session tools:
sessions_list,sessions_history,sessions_send - Skills registry: ClawHub
- Architecture overview: Architecture
Docs by goal
- New here: Getting started, Onboarding, Updating
- Channel setup: Channels index, WhatsApp, Telegram, Discord, Slack
- Apps + nodes: Windows Hub, macOS, iOS, Android, Nodes
- Config + security: Configuration, Security, Exposure runbook, Sandboxing
- Remote + web: Gateway, Remote access, Tailscale, Web surfaces
- Tools + automation: Tools, Skills, Cron jobs, Webhooks, Gmail Pub/Sub
- Internals: Architecture, Agent, Session model, Gateway protocol
- Troubleshooting: Channel troubleshooting, Logging, Docs home
Apps (optional)
The Gateway alone delivers a great experience. All apps are optional and add extra features.
If you plan to build/run companion apps, follow the platform runbooks below.
macOS (OpenClaw.app) (optional)
- Menu bar control for the Gateway and health.
- Voice Wake + push-to-talk overlay.
- WebChat + debug tools.
- Remote gateway control over SSH.
Note: signed builds required for macOS permissions to stick across rebuilds (see macOS Permissions).
iOS node (optional)
- Pairs as a node over the Gateway WebSocket (device pairing).
- Voice trigger forwarding + Canvas surface.
- Controlled via
openclaw nodes ….
Runbook: iOS connect.
Android node (optional)
- Pairs as a WS node via device pairing (
openclaw devices ...). - Exposes Connect/Chat/Voice tabs plus Canvas, Camera, Screen capture, and Android device command families.
- Runbook: Android connect.
From source (development)
Use pnpm for source checkouts. The repository is a pnpm workspace, and bundled
plugins load from extensions/* during development so their package-local
dependencies and your edits are used directly. Plain npm install at the repo
root is not a supported source setup.
For the dev loop:
git clone https://github.com/openclaw/openclaw.git
cd openclaw
pnpm install
# First run only (or after resetting local OpenClaw config/workspace)
pnpm openclaw setup
# Optional: prebuild Control UI before first startup
pnpm ui:build
# Dev loop (auto-reload on source/config changes)
pnpm gateway:watch
If you need a built dist/ from the checkout (for Node, packaging, or release validation), run:
pnpm build
pnpm ui:build
pnpm openclaw setup writes the local config/workspace needed for pnpm gateway:watch. It is safe to re-run, but you normally only need it on first setup or after resetting local state. pnpm gateway:watch hands the configured Gateway port from the installed service to a durable tmux pane; run pnpm openclaw gateway start when you want the installed service back. It does not rebuild dist/control-ui, so rerun pnpm ui:build after ui/ changes or use pnpm ui:dev when iterating on the Control UI. If you want this checkout to run onboarding directly, use pnpm openclaw onboard --install-daemon.
Note: pnpm openclaw ... runs TypeScript directly (via tsx). pnpm build produces dist/ for running via Node / the packaged openclaw binary, while pnpm gateway:watch rebuilds the runtime on demand during the dev loop.
Development channels
- stable: tagged releases (
vYYYY.M.DorvYYYY.M.D-<patch>), npm dist-taglatest. - beta: prerelease tags (
vYYYY.M.D-beta.N), npm dist-tagbeta(macOS app may be missing). - dev: moving head of
main, npm dist-tagdev(when published).
Switch channels (git + npm): openclaw update --channel stable|beta|dev.
Details: Development channels.
Agent workspace + skills
- Workspace root:
~/.openclaw/workspace(configurable viaagents.defaults.workspace). - Injected prompt files:
AGENTS.md,SOUL.md,TOOLS.md. - Skills:
~/.openclaw/workspace/skills/<skill>/SKILL.md.
Configuration
Minimal ~/.openclaw/openclaw.json (model + defaults):
{
agent: {
model: "<provider>/<model-id>",
},
}
Full configuration reference (all keys + examples).
Star History
Molty
OpenClaw was built for Molty, a space lobster AI assistant. 🦞 by Peter Steinberger and the community.
Community
See CONTRIBUTING.md for guidelines, maintainers, and how to submit PRs. Use the issue chooser for bugs, docs bugs, and feature requests; ask setup/support questions in Discord; and report vulnerabilities through SECURITY.md. PRs should link the relevant issue when possible and follow the PR template with problem, impact, and evidence. AI/vibe-coded PRs welcome! 🤖
Special thanks to Mario Zechner for his support and for pi-mono. Special thanks to Adam Doppelt for the lobster.bot domain.
Thanks to all clawtributors:
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?v=4&s=48)
![clawdinator[bot]](https://avatars.githubusercontent.com/in/2607181?v=4&s=48)
![google-labs-jules[bot]](https://avatars.githubusercontent.com/in/842251?v=4&s=48)
