Quick answers plus deeper troubleshooting for real-world setups (local dev, VPS, multi-agent, OAuth/API keys, model failover). For runtime diagnostics, see Troubleshooting. For the full config reference, see Configuration.
OpenClaw is a personal AI assistant you run on your own devices. It replies on the messaging surfaces you already use (WhatsApp, Telegram, Slack, Mattermost, Discord, Google Chat, Signal, iMessage, WebChat, and bundled channel plugins such as QQ Bot) and can also do voice + a live Canvas on supported platforms. The Gateway is the always-on control plane; the assistant is the product.
Value proposition
OpenClaw is not “just a Claude wrapper.” It’s a local-first control plane that lets you run a
capable assistant on your own hardware, reachable from the chat apps you already use, with
stateful sessions, memory, and tools - without handing control of your workflows to a hosted
SaaS.
Highlights:
Your devices, your data: run the Gateway wherever you want (Mac, Linux, VPS) and keep the
workspace + session history local.
Real channels, not a web sandbox: WhatsApp/Telegram/Slack/Discord/Signal/iMessage/etc,
plus mobile voice and Canvas on supported platforms.
Model-agnostic: use Anthropic, OpenAI, MiniMax, OpenRouter, etc., with per-agent routing
and failover.
Local-only option: run local models so all data can stay on your device if you want.
Multi-agent routing: separate agents per channel, account, or task, each with its own
workspace and defaults.
Open source and hackable: inspect, extend, and self-host without vendor lock-in.
Build a website (WordPress, Shopify, or a simple static site).
Prototype a mobile app (outline, screens, API plan).
Organize files and folders (cleanup, naming, tagging).
Connect Gmail and automate summaries or follow ups.
It can handle large tasks, but it works best when you split them into phases and
use sub agents for parallel work.
What are the top five everyday use cases for OpenClaw?
Everyday wins usually look like:
Personal briefings: summaries of inbox, calendar, and news you care about.
Research and drafting: quick research, summaries, and first drafts for emails or docs.
Reminders and follow ups: cron or heartbeat driven nudges and checklists.
Browser automation: filling forms, collecting data, and repeating web tasks.
Cross device coordination: send a task from your phone, let the Gateway run it on a server, and get the result back in chat.
Can OpenClaw help with lead gen, outreach, ads, and blogs for a SaaS?
Yes for research, qualification, and drafting. It can scan sites, build shortlists,
summarize prospects, and write outreach or ad copy drafts.
For outreach or ad runs, keep a human in the loop. Avoid spam, follow local laws and
platform policies, and review anything before it is sent. The safest pattern is to let
OpenClaw draft and you approve.
What are the advantages vs Claude Code for web development?
OpenClaw is a personal assistant and coordination layer, not an IDE replacement. Use
Claude Code or Codex for the fastest direct coding loop inside a repo. Use OpenClaw when you
want durable memory, cross-device access, and tool orchestration.
How do I customize skills without keeping the repo dirty?
Use managed overrides instead of editing the repo copy. Put your changes in `~/.openclaw/skills/
/SKILL.md(or add a folder viaskills.load.extraDirsin~/.openclaw/openclaw.json). Precedence is
/skills→
/.agents/skills→/.agents/skills→/.openclaw/skills→ bundled →skills.load.extraDirs, so managed overrides still win over bundled skills without touching git. If you need the skill installed globally but only visible to some agents, keep the shared copy in ~/.openclaw/skillsand control visibility withagents.defaults.skillsandagents.list[].skills`. Only upstream-worthy edits should live in the repo and go out as PRs.
Can I load skills from a custom folder?
Yes. Add extra directories via skills.load.extraDirs in ~/.openclaw/openclaw.json (lowest precedence). Default precedence is `
/skills→
/.agents/skills→/.agents/skills→/.openclaw/skills→ bundled →skills.load.extraDirs. clawhubinstalls into./skillsby default, which OpenClaw treats as
/skillson the next session. If the skill should only be visible to certain agents, pair that withagents.defaults.skillsoragents.list[].skills`.
How can I use different models for different tasks?
Today the supported patterns are:
Cron jobs: isolated jobs can set a model override per job.
Sub-agents: route tasks to separate agents with different default models.
On-demand switch: use /model to switch the current session model at any time.
The bot freezes while doing heavy work. How do I offload that?
Use sub-agents for long or parallel tasks. Sub-agents run in their own session,
return a summary, and keep your main chat responsive.
Ask your bot to “spawn a sub-agent for this task” or use /subagents.
Use /status in chat to see what the Gateway is doing right now (and whether it is busy).
Token tip: long tasks and sub-agents both consume tokens. If cost is a concern, set a
cheaper model for sub-agents via agents.defaults.subagents.model.
A subagent finished, but the completion update went to the wrong place or never posted. What should I check?
Check the resolved requester route first:
Completion-mode subagent delivery prefers any bound thread or conversation route when one exists.
If the completion origin only carries a channel, OpenClaw falls back to the requester session’s stored route (lastChannel / lastTo / lastAccountId) so direct delivery can still succeed.
If neither a bound route nor a usable stored route exists, direct delivery can fail and the result falls back to queued session delivery instead of posting immediately to chat.
Invalid or stale targets can still force queue fallback or final delivery failure.
If the child’s last visible assistant reply is the exact silent token NO_REPLY / no_reply, or exactly ANNOUNCE_SKIP, OpenClaw intentionally suppresses the announce instead of posting stale earlier progress.
Tool/toolResult output is not promoted into child result text; the result is the child’s latest visible assistant reply.
Cron fired, but nothing was sent to the channel. Why?
Check the delivery mode first:
--no-deliver / delivery.mode: "none" means no runner fallback send is expected.
Missing or invalid announce target (channel / to) means the runner skipped outbound delivery.
Channel auth failures (unauthorized, Forbidden) mean the runner tried to deliver but credentials blocked it.
A silent isolated result (NO_REPLY / no_reply only) is treated as intentionally non-deliverable, so the runner also suppresses queued fallback delivery.
For isolated cron jobs, the agent can still send directly with the message
tool when a chat route is available. --announce only controls the runner
fallback path for final text that the agent did not already send.
Why did an isolated cron run switch models or retry once?
That is usually the live model-switch path, not duplicate scheduling.
Isolated cron can persist a runtime model handoff and retry when the active
run throws LiveSessionModelSwitchError. The retry keeps the switched
provider/model, and if the switch carried a new auth profile override, cron
persists that too before retrying.
Related selection rules:
Gmail hook model override wins first when applicable.
Then per-job model.
Then any stored cron-session model override.
Then the normal agent/default model selection.
The retry loop is bounded. After the initial attempt plus 2 switch retries,
cron aborts instead of looping forever.
Use native openclaw skills commands or drop skills into your workspace. The macOS Skills UI isn’t available on Linux.
Browse skills at https://clawhub.ai.
Not directly. macOS skills are gated by metadata.openclaw.os plus required binaries, and skills only appear in the system prompt when they are eligible on the Gateway host. On Linux, darwin-only skills (like apple-notes, apple-reminders, things-mac) will not load unless you override the gating.
You have three supported patterns:
Option A - run the Gateway on a Mac (simplest).
Run the Gateway where the macOS binaries exist, then connect from Linux in remote mode or over Tailscale. The skills load normally because the Gateway host is macOS.
Option B - use a macOS node (no SSH).
Run the Gateway on Linux, pair a macOS node (menubar app), and set Node Run Commands to “Always Ask” or “Always Allow” on the Mac. OpenClaw can treat macOS-only skills as eligible when the required binaries exist on the node. The agent runs those skills via the nodes tool. If you choose “Always Ask”, approving “Always Allow” in the prompt adds that command to the allowlist.
Option C - proxy macOS binaries over SSH (advanced).
Keep the Gateway on Linux, but make the required CLI binaries resolve to SSH wrappers that run on a Mac. Then override the skill to allow Linux so it stays eligible.
Create an SSH wrapper for the binary (example: memo for Apple Notes):
#!/usr/bin/env bash
set-euopipefail
execssh-Tuser@mac-host/opt/homebrew/bin/memo"$@"
Put the wrapper on PATH on the Linux host (for example ~/bin/memo).
Override the skill metadata (workspace or ~/.openclaw/skills) to allow Linux:
---
name: apple-notes
description: Manage Apple Notes via the memo CLI on macOS.
Start a new session so the skills snapshot refreshes.
Do you have a Notion or HeyGen integration?
Not built-in today.
Options:
Custom skill / plugin: best for reliable API access (Notion/HeyGen both have APIs).
Browser automation: works without code but is slower and more fragile.
If you want to keep context per client (agency workflows), a simple pattern is:
One Notion page per client (context + preferences + active work).
Ask the agent to fetch that page at the start of a session.
If you want a native integration, open a feature request or build a skill
targeting those APIs.
Install skills:
Terminal window
openclawskillsinstall
openclaw skills update —all
Native installs land in the active workspace `skills/` directory. For shared skills across all local agents, use `openclaw skills install
—global(or place them manually in~/.openclaw/skills/
/SKILL.md). If only some agents should see a shared install, configure agents.defaults.skillsoragents.list[].skills`. Some skills expect binaries installed via Homebrew; on Linux that means Linuxbrew (see the Homebrew Linux FAQ entry above). See Skills, Skills config, and ClawHub.
How do I use my existing signed-in Chrome with OpenClaw?
Use the built-in user browser profile, which attaches through Chrome DevTools MCP:
Terminal window
openclawbrowser--browser-profileusertabs
openclawbrowser--browser-profileusersnapshot
If you want a custom name, create an explicit MCP profile:
This path can use the local host browser or a connected browser node. If the Gateway runs elsewhere, either run a node host on the browser machine or use remote CDP instead.
Current limits on existing-session / user:
actions are ref-driven, not CSS-selector driven
uploads require ref / inputRef and currently support one file at a time
responsebody, PDF export, download interception, and batch actions still need a managed browser or raw CDP profile
Yes. See Sandboxing. For Docker-specific setup (full gateway in Docker or sandbox images), see Docker.
Docker feels limited - how do I enable full features?
The default image is security-first and runs as the node user, so it does not
include system packages, Homebrew, or bundled browsers. For a fuller setup:
Persist /home/node with OPENCLAW_HOME_VOLUME so caches survive.
Bake system deps into the image with OPENCLAW_IMAGE_APT_PACKAGES.
Install Playwright browsers via the bundled CLI:
node /app/node_modules/playwright-core/cli.js install chromium
Set PLAYWRIGHT_BROWSERS_PATH and ensure the path is persisted.
Can I keep DMs personal but make groups public/sandboxed with one agent?
Yes - if your private traffic is DMs and your public traffic is groups.
Use agents.defaults.sandbox.mode: "non-main" so group/channel sessions (non-main keys) run in the configured sandbox backend, while the main DM session stays on-host. Docker is the default backend if you do not choose one. Then restrict what tools are available in sandboxed sessions via tools.sandbox.tools.
Set agents.defaults.sandbox.docker.binds to ["host:path:mode"] (e.g., "/home/user/src:/src:ro"). Global + per-agent binds merge; per-agent binds are ignored when scope: "shared". Use :ro for anything sensitive and remember binds bypass the sandbox filesystem walls.
OpenClaw validates bind sources against both the normalized path and the canonical path resolved through the deepest existing ancestor. That means symlink-parent escapes still fail closed even when the last path segment does not exist yet, and allowed-root checks still apply after symlink resolution.
OpenClaw memory is just Markdown files in the agent workspace:
Daily notes in memory/YYYY-MM-DD.md
Curated long-term notes in MEMORY.md (main/private sessions only)
OpenClaw also runs a silent pre-compaction memory flush to remind the model
to write durable notes before auto-compaction. This only runs when the workspace
is writable (read-only sandboxes skip it). See Memory.
Memory keeps forgetting things. How do I make it stick?
Ask the bot to write the fact to memory. Long-term notes belong in MEMORY.md,
short-term context goes into memory/YYYY-MM-DD.md.
This is still an area we are improving. It helps to remind the model to store memories;
it will know what to do. If it keeps forgetting, verify the Gateway is using the same
workspace on every run.
Memory files live on disk and persist until you delete them. The limit is your
storage, not the model. The session context is still limited by the model
context window, so long conversations can compact or truncate. That is why
memory search exists - it pulls only the relevant parts back into context.
Does semantic memory search require an OpenAI API key?
Only if you use OpenAI embeddings. Codex OAuth covers chat/completions and
does not grant embeddings access, so signing in with Codex (OAuth or the
Codex CLI login) does not help for semantic memory search. OpenAI embeddings
still need a real API key (OPENAI_API_KEY or models.providers.openai.apiKey).
If you don’t set a provider explicitly, OpenClaw auto-selects a provider when it
can resolve an API key (auth profiles, models.providers.*.apiKey, or env vars).
It prefers OpenAI if an OpenAI key resolves, otherwise Gemini if a Gemini key
resolves, then Voyage, then Mistral. If no remote key is available, memory
search stays disabled until you configure it. If you have a local model path
configured and present, OpenClaw
prefers local. Ollama is supported when you explicitly set
memorySearch.provider = "ollama".
If you’d rather stay local, set memorySearch.provider = "local" (and optionally
memorySearch.fallback = "none"). If you want Gemini embeddings, set
memorySearch.provider = "gemini" and provide GEMINI_API_KEY (or
memorySearch.remote.apiKey). We support OpenAI, Gemini, Voyage, Mistral, Ollama, or local embedding
models - see Memory for the setup details.
No - OpenClaw’s state is local, but external services still see what you send them.
Local by default: sessions, memory files, config, and workspace live on the Gateway host
(~/.openclaw + your workspace directory).
Remote by necessity: messages you send to model providers (Anthropic/OpenAI/etc.) go to
their APIs, and chat platforms (WhatsApp/Telegram/Slack/etc.) store message data on their
servers.
You control the footprint: using local models keeps prompts on your machine, but channel
traffic still goes through the channel’s servers.
Legacy single-agent path: `~/.openclaw/agent/*` (migrated by `openclaw doctor`).
Your **workspace** (AGENTS.md, memory files, skills, etc.) is separate and configured via `agents.defaults.workspace` (default: `~/.openclaw/workspace`).
Where should AGENTS.md / SOUL.md / USER.md / MEMORY.md live?
These files live in the agent workspace, not ~/.openclaw.
Workspace (per agent): AGENTS.md, SOUL.md, IDENTITY.md, USER.md,
MEMORY.md, memory/YYYY-MM-DD.md, optional HEARTBEAT.md.
Lowercase root memory.md is legacy repair input only; openclaw doctor --fix
can merge it into MEMORY.md when both files exist.
State dir (~/.openclaw): config, channel/provider state, auth profiles, sessions, logs,
and shared skills (~/.openclaw/skills).
Default workspace is ~/.openclaw/workspace, configurable via:
If the bot “forgets” after a restart, confirm the Gateway is using the same
workspace on every launch (and remember: remote mode uses the gateway host’s
workspace, not your local laptop).
Tip: if you want a durable behavior or preference, ask the bot to write it into
AGENTS.md or MEMORY.md rather than relying on chat history.
Put your agent workspace in a private git repo and back it up somewhere
private (for example GitHub private). This captures memory + AGENTS/SOUL/USER
files, and lets you restore the assistant’s “mind” later.
Do not commit anything under ~/.openclaw (credentials, sessions, tokens, or encrypted secrets payloads).
If you need a full restore, back up both the workspace and the state directory
separately (see the migration question above).
Yes. The workspace is the default cwd and memory anchor, not a hard sandbox.
Relative paths resolve inside the workspace, but absolute paths can access other
host locations unless sandboxing is enabled. If you need isolation, use
agents.defaults.sandbox or per-agent sandbox settings. If you
want a repo to be the default working directory, point that agent’s
workspace to the repo root. The OpenClaw repo is just source code; keep the
workspace separate unless you intentionally want the agent to work inside it.
Example (repo as default cwd):
{
agents: {
defaults: {
workspace: "~/Projects/my-repo",
},
},
}
Remote mode: where is the session store?
Session state is owned by the gateway host. If you’re in remote mode, the session store you care about is on the remote machine, not your local laptop. See Session management.
OpenClaw reads an optional JSON5 config from $OPENCLAW_CONFIG_PATH (default: ~/.openclaw/openclaw.json):
$OPENCLAW_CONFIG_PATH
If the file is missing, it uses safe-ish defaults (including a default workspace of ~/.openclaw/workspace).
I set gateway.bind: "lan" (or "tailnet") and now nothing listens / the UI says unauthorized
Non-loopback binds require a valid gateway auth path. In practice that means:
shared-secret auth: token or password
gateway.auth.mode: "trusted-proxy" behind a correctly configured identity-aware reverse proxy
{
gateway: {
bind: "lan",
auth: {
mode: "token",
token: "replace-me",
},
},
}
Notes:
gateway.remote.token / .password do not enable local gateway auth by themselves.
Local call paths can use gateway.remote.* as fallback only when gateway.auth.* is unset.
For password auth, set gateway.auth.mode: "password" plus gateway.auth.password (or OPENCLAW_GATEWAY_PASSWORD) instead.
If gateway.auth.token / gateway.auth.password is explicitly configured via SecretRef and unresolved, resolution fails closed (no remote fallback masking).
Shared-secret Control UI setups authenticate via connect.params.auth.token or connect.params.auth.password (stored in app/UI settings). Identity-bearing modes such as Tailscale Serve or trusted-proxy use request headers instead. Avoid putting shared secrets in URLs.
With gateway.auth.mode: "trusted-proxy", same-host loopback reverse proxies require explicit gateway.auth.trustedProxy.allowLoopback = true and a loopback entry in gateway.trustedProxies.
Why do I need a token on localhost now?
OpenClaw enforces gateway auth by default, including loopback. In the normal default path that means token auth: if no explicit auth path is configured, gateway startup resolves to token mode and generates a runtime-only token for that startup, so local WS clients must authenticate. Configure gateway.auth.token, gateway.auth.password, OPENCLAW_GATEWAY_TOKEN, or OPENCLAW_GATEWAY_PASSWORD explicitly when clients need a stable secret across restarts. This blocks other local processes from calling the Gateway.
If you prefer a different auth path, you can explicitly choose password mode (or, for identity-aware reverse proxies, trusted-proxy). If you really want open loopback, set gateway.auth.mode: "none" explicitly in your config. Doctor can generate a token for you any time: openclaw doctor --generate-gateway-token.
Do I have to restart after changing config?
The Gateway watches the config and supports hot-reload:
gateway.reload.mode: "hybrid" (default): hot-apply safe changes, restart for critical ones
hot, restart, off are also supported
How do I disable funny CLI taglines?
Set cli.banner.taglineMode in config:
{
cli: {
banner: {
taglineMode: "off", // random | default | off
},
},
}
off: hides tagline text but keeps the banner title/version line.
default: uses All your chats, one OpenClaw. every time.
If you want no banner at all, set env OPENCLAW_HIDE_BANNER=1.
How do I enable web search (and web fetch)?
web_fetch works without an API key. web_search depends on your selected
provider:
API-backed providers such as Brave, Exa, Firecrawl, Gemini, Kimi, MiniMax Search, Perplexity, and Tavily require their normal API key setup.
Grok can reuse xAI OAuth from model auth, or fall back to XAI_API_KEY / plugin web-search config.
Ollama Web Search is key-free, but it uses your configured Ollama host and requires ollama signin.
DuckDuckGo is key-free, but it is an unofficial HTML-based integration.
SearXNG is key-free/self-hosted; configure SEARXNG_BASE_URL or plugins.entries.searxng.config.webSearch.baseUrl.
Recommended: run openclaw configure --section web and choose a provider.
Environment alternatives:
Brave: BRAVE_API_KEY
Exa: EXA_API_KEY
Firecrawl: FIRECRAWL_API_KEY
Gemini: GEMINI_API_KEY
Grok: xAI OAuth, XAI_API_KEY
Kimi: KIMI_API_KEY or MOONSHOT_API_KEY
MiniMax Search: MINIMAX_CODE_PLAN_KEY, MINIMAX_CODING_API_KEY, or MINIMAX_API_KEY
Perplexity: PERPLEXITY_API_KEY or OPENROUTER_API_KEY
SearXNG: SEARXNG_BASE_URL
Tavily: TAVILY_API_KEY
{
plugins: {
entries: {
brave: {
config: {
webSearch: {
apiKey: "BRAVE_API_KEY_HERE",
},
},
},
},
},
tools: {
web: {
search: {
enabled: true,
provider: "brave",
maxResults: 5,
},
fetch: {
enabled: true,
provider: "firecrawl", // optional; omit for auto-detect
},
},
},
}
Provider-specific web-search config now lives under `plugins.entries.
.config.webSearch.. Legacy tools.web.search.provider paths still load temporarily for compatibility, but they should not be used for new configs. Firecrawl web-fetch fallback config lives underplugins.entries.firecrawl.config.webFetch.*`.
Notes:
- If you use allowlists, add `web_search`/`web_fetch`/`x_search` or `group:web`.
- `web_fetch` is enabled by default (unless explicitly disabled).
- If `tools.web.fetch.provider` is omitted, OpenClaw auto-detects the first ready fetch fallback provider from available credentials. Today the bundled provider is Firecrawl.
- Daemons read env vars from `~/.openclaw/.env` (or the service environment).
Docs: [Web tools](/en/tools/web).
config.apply wiped my config. How do I recover and avoid this?
config.apply replaces the entire config. If you send a partial object, everything
else is removed.
Current OpenClaw protects many accidental clobbers:
OpenClaw-owned config writes validate the full post-change config before writing.
Invalid or destructive OpenClaw-owned writes are rejected and saved as openclaw.json.rejected.*.
If a direct edit breaks startup or hot reload, Gateway fails closed or skips the reload; it does not rewrite openclaw.json.
openclaw doctor --fix owns repair and can restore last-known-good while saving the rejected file as openclaw.json.clobbered.*.
Recover:
Check openclaw logs --follow for Invalid config at, Config write rejected:, or config reload skipped (invalid config).
Inspect the newest openclaw.json.clobbered.* or openclaw.json.rejected.* beside the active config.
Run openclaw config validate and openclaw doctor --fix.
Copy only the intended keys back with openclaw config set or config.patch.
If you have no last-known-good or rejected payload, restore from backup, or re-run openclaw doctor and reconfigure channels/models.
If this was unexpected, file a bug and include your last known config or any backup.
A local coding agent can often reconstruct a working config from logs or history.
Avoid it:
Use openclaw config set for small changes.
Use openclaw configure for interactive edits.
Use config.schema.lookup first when you are not sure about an exact path or field shape; it returns a shallow schema node plus immediate child summaries for drill-down.
Use config.patch for partial RPC edits; keep config.apply for full-config replacement only.
If you are using the agent-facing gateway tool from an agent run, it will still reject writes to tools.exec.ask / tools.exec.security (including legacy tools.bash.* aliases that normalize to the same protected exec paths).
How do commands propagate between Telegram, the gateway, and nodes?
Telegram messages are handled by the gateway. The gateway runs the agent and
only then calls nodes over the Gateway WebSocket when a node tool is needed:
Nodes don’t see inbound provider traffic; they only receive node RPC calls.
How can my agent access my computer if the Gateway is hosted remotely?
Short answer: pair your computer as a node. The Gateway runs elsewhere, but it can
call node.* tools (screen, camera, system) on your local machine over the Gateway WebSocket.
Typical setup:
Run the Gateway on the always-on host (VPS/home server).
Put the Gateway host + your computer on the same tailnet.
Ensure the Gateway WS is reachable (tailnet bind or SSH tunnel).
Open the macOS app locally and connect in Remote over SSH mode (or direct tailnet)
so it can register as a node.
Approve the node on the Gateway:
Terminal window
openclawdeviceslist
openclawdevicesapprove
No separate TCP bridge is required; nodes connect over the Gateway WebSocket.
Security reminder: pairing a macOS node allows `system.run` on that machine. Only
pair devices you trust, and review [Security](/en/gateway/security).
Can two OpenClaw instances talk to each other (local + VPS)?
Yes. There is no built-in “bot-to-bot” bridge, but you can wire it up in a few
reliable ways:
Simplest: use a normal chat channel both bots can access (Telegram/Slack/WhatsApp).
Have Bot A send a message to Bot B, then let Bot B reply as usual.
CLI bridge (generic): run a script that calls the other Gateway with
openclaw agent --message ... --deliver, targeting a chat where the other bot
listens. If one bot is on a remote VPS, point your CLI at that remote Gateway
via SSH/Tailscale (see Remote access).
Example pattern (run from a machine that can reach the target Gateway):
Terminal window
openclawagent--message"Hello from local bot"--deliver--channeltelegram--reply-to
Tip: add a guardrail so the two bots do not loop endlessly (mention-only, channel
allowlists, or a "do not reply to bot messages" rule).
No. One Gateway can host multiple agents, each with its own workspace, model defaults,
and routing. That is the normal setup and it is much cheaper and simpler than running
one VPS per agent.
Use separate VPSes only when you need hard isolation (security boundaries) or very
different configs that you do not want to share. Otherwise, keep one Gateway and
use multiple agents or sub-agents.
Is there a benefit to using a node on my personal laptop instead of SSH from a VPS?
Yes - nodes are the first-class way to reach your laptop from a remote Gateway, and they
unlock more than shell access. The Gateway runs on macOS/Linux (Windows via WSL2) and is
lightweight (a small VPS or Raspberry Pi-class box is fine; 4 GB RAM is plenty), so a common
setup is an always-on host plus your laptop as a node.
No inbound SSH required. Nodes connect out to the Gateway WebSocket and use device pairing.
Safer execution controls.system.run is gated by node allowlists/approvals on that laptop.
More device tools. Nodes expose canvas, camera, and screen in addition to system.run.
Local browser automation. Keep the Gateway on a VPS, but run Chrome locally through a node host on the laptop, or attach to local Chrome on the host via Chrome MCP.
SSH is fine for ad-hoc shell access, but nodes are simpler for ongoing agent workflows and
device automation.
No. Only one gateway should run per host unless you intentionally run isolated profiles (see Multiple gateways). Nodes are peripherals that connect
to the gateway (iOS/Android nodes, or macOS “node mode” in the menubar app). For headless node
hosts and CLI control, see Node host CLI.
A full restart is required for gateway, discovery, and hosted plugin surface changes.
Is there an API / RPC way to apply config?
Yes.
config.schema.lookup: inspect one config subtree with its shallow schema node, matched UI hint, and immediate child summaries before writing
config.get: fetch the current snapshot + hash
config.patch: safe partial update (preferred for most RPC edits); hot-reloads when possible and restarts when required
config.apply: validate + replace the full config; hot-reloads when possible and restarts when required
The agent-facing gateway runtime tool still refuses to rewrite tools.exec.ask / tools.exec.security; legacy tools.bash.* aliases normalize to the same protected exec paths
Should I install on a second laptop or just add a node?
If you only need local tools (screen/camera/exec) on the second laptop, add it as a
node. That keeps a single Gateway and avoids duplicated config. Local node tools are
currently macOS-only, but we plan to extend them to other OSes.
Install a second Gateway only when you need hard isolation or two fully separate bots.
I started the Gateway via the service and my env vars disappeared. What now?
Two common fixes:
Put the missing keys in ~/.openclaw/.env so they’re picked up even when the service doesn’t inherit your shell env.
Enable shell import (opt-in convenience):
{
env: {
shellEnv: {
enabled: true,
timeoutMs: 15000,
},
},
}
This runs your login shell and imports only missing expected keys (never overrides). Env var equivalents:
OPENCLAW_LOAD_SHELL_ENV=1, OPENCLAW_SHELL_ENV_TIMEOUT_MS=15000.
I set COPILOT_GITHUB_TOKEN, but models status shows "Shell env: off." Why?
openclaw models status reports whether shell env import is enabled. “Shell env: off”
does not mean your env vars are missing - it just means OpenClaw won’t load
your login shell automatically.
If the Gateway runs as a service (launchd/systemd), it won’t inherit your shell
environment. Fix by doing one of these:
Put the token in ~/.openclaw/.env:
COPILOT_GITHUB_TOKEN=...
Or enable shell import (env.shellEnv.enabled: true).
Or add it to your config env block (applies only if missing).
Do sessions reset automatically if I never send /new?
Sessions can expire after session.idleMinutes, but this is disabled by default (default 0).
Set it to a positive value to enable idle expiry. When enabled, the next
message after the idle period starts a fresh session id for that chat key.
This does not delete transcripts - it just starts a new session.
{
session: {
idleMinutes: 240,
},
}
Is there a way to make a team of OpenClaw instances (one CEO and many agents)?
Yes, via multi-agent routing and sub-agents. You can create one coordinator
agent and several worker agents with their own workspaces and models.
That said, this is best seen as a fun experiment. It is token heavy and often
less efficient than using one bot with separate sessions. The typical model we
envision is one bot you talk to, with different sessions for parallel work. That
bot can also spawn sub-agents when needed.
Why am I seeing "LLM request rejected: messages.content.tool_use.input field required"?
This is a provider validation error: the model emitted a tool_use block without the required
input. It usually means the session history is stale or corrupted (often after long threads
or a tool/schema change).
Fix: start a fresh session with /new (standalone message).
Why am I getting heartbeat messages every 30 minutes?
Heartbeats run every 30m by default (1h when using OAuth auth). Tune or disable them:
{
agents: {
defaults: {
heartbeat: {
every: "2h", // or "0m" to disable
},
},
},
}
If HEARTBEAT.md exists but is effectively empty (only blank lines and markdown
headers like # Heading), OpenClaw skips the heartbeat run to save API calls.
If the file is missing, the heartbeat still runs and the model decides what to do.
Per-agent overrides use agents.list[].heartbeat. Docs: Heartbeat.
Do I need to add a "bot account" to a WhatsApp group?
No. OpenClaw runs on your own account, so if you’re in the group, OpenClaw can see it.
By default, group replies are blocked until you allow senders (groupPolicy: "allowlist").
If you want only you to be able to trigger group replies:
{
channels: {
whatsapp: {
groupPolicy: "allowlist",
groupAllowFrom: ["+15551234567"],
},
},
}
How do I get the JID of a WhatsApp group?
Option 1 (fastest): tail logs and send a test message in the group:
Direct chats collapse to the main session by default. Groups/channels have their own session keys, and Telegram topics / Discord threads are separate sessions. See Groups and Group messages.
How many workspaces and agents can I create?
No hard limits. Dozens (even hundreds) are fine, but watch for:
Disk growth: sessions + transcripts live under `~/.openclaw/agents/
/sessions/`.
- Token cost: more agents means more concurrent model usage.
- Ops overhead: per-agent auth profiles, workspaces, and channel routing.
Tips:
- Keep one **active** workspace per agent (`agents.defaults.workspace`).
- Prune old sessions (delete JSONL or store entries) if disk grows.
- Use `openclaw doctor` to spot stray workspaces and profile mismatches.
Can I run multiple bots or chats at the same time (Slack), and how should I set that up?
Yes. Use Multi-Agent Routing to run multiple isolated agents and route inbound messages by
channel/account/peer. Slack is supported as a channel and can be bound to specific agents.
Browser access is powerful but not “do anything a human can” - anti-bot, CAPTCHAs, and MFA can
still block automation. For the most reliable browser control, use local Chrome MCP on the host,
or use CDP on the machine that actually runs the browser.
Best-practice setup:
Always-on Gateway host (VPS/Mac mini).
One agent per role (bindings).
Slack channel(s) bound to those agents.
Local browser via Chrome MCP or a node when needed.
Why does openclaw gateway status say "Runtime: running" but "Connectivity probe: failed"?
Because “running” is the supervisor’s view (launchd/systemd/schtasks). The connectivity probe is the CLI actually connecting to the gateway WebSocket.
Use openclaw gateway status and trust these lines:
Probe target: (the URL the probe actually used)
Listening: (what’s actually bound on the port)
Last gateway error: (common root cause when the process is alive but the port isn’t listening)
Why does openclaw gateway status show "Config (cli)" and "Config (service)" different?
You’re editing one config file while the service is running another (often a --profile / OPENCLAW_STATE_DIR mismatch).
Fix:
Terminal window
openclawgatewayinstall--force
Run that from the same --profile / environment you want the service to use.
What does "another gateway instance is already listening" mean?
OpenClaw enforces a runtime lock by binding the WebSocket listener immediately on startup (default ws://127.0.0.1:18789). If the bind fails with EADDRINUSE, it throws GatewayLockError indicating another instance is already listening.
Fix: stop the other instance, free the port, or run with `openclaw gateway —port
`.
How do I run OpenClaw in remote mode (client connects to a Gateway elsewhere)?
Set gateway.mode: "remote" and point to a remote WebSocket URL, optionally with shared-secret remote credentials:
{
gateway: {
mode: "remote",
remote: {
url: "ws://gateway.tailnet:18789",
token: "your-token",
password: "your-password",
},
},
}
Notes:
openclaw gateway only starts when gateway.mode is local (or you pass the override flag).
The macOS app watches the config file and switches modes live when these values change.
gateway.remote.token / .password are client-side remote credentials only; they do not enable local gateway auth by themselves.
The Control UI says "unauthorized" (or keeps reconnecting). What now?
Your gateway auth path and the UI’s auth method do not match.
Facts (from code):
The Control UI keeps the token in sessionStorage for the current browser tab session and selected gateway URL, so same-tab refreshes keep working without restoring long-lived localStorage token persistence.
On AUTH_TOKEN_MISMATCH, trusted clients can attempt one bounded retry with a cached device token when the gateway returns retry hints (canRetryWithDeviceToken=true, recommendedNextStep=retry_with_device_token).
That cached-token retry now reuses the cached approved scopes stored with the device token. Explicit deviceToken / explicit scopes callers still keep their requested scope set instead of inheriting cached scopes.
Outside that retry path, connect auth precedence is explicit shared token/password first, then explicit deviceToken, then stored device token, then bootstrap token.
Built-in setup-code bootstrap is node-only. After approval, it returns a node device token with scopes: [] and does not return a handed-off operator token.
Fix:
Fastest: openclaw dashboard (prints + copies the dashboard URL, tries to open; shows SSH hint if headless).
If you don’t have a token yet: openclaw doctor --generate-gateway-token.
If remote, tunnel first: ssh -N -L 18789:127.0.0.1:18789 user@host then open http://127.0.0.1:18789/.
Shared-secret mode: set gateway.auth.token / OPENCLAW_GATEWAY_TOKEN or gateway.auth.password / OPENCLAW_GATEWAY_PASSWORD, then paste the matching secret in Control UI settings.
Tailscale Serve mode: make sure gateway.auth.allowTailscale is enabled and you are opening the Serve URL, not a raw loopback/tailnet URL that bypasses Tailscale identity headers.
Trusted-proxy mode: make sure you are coming through the configured identity-aware proxy, not a raw gateway URL. Same-host loopback proxies also need gateway.auth.trustedProxy.allowLoopback = true.
If mismatch persists after the one retry, rotate/re-approve the paired device token:
openclaw devices list
`openclaw devices rotate —device
—role operator`
If that rotate call says it was denied, check two things:
paired-device sessions can rotate only their own device unless they also have operator.admin
explicit --scope values cannot exceed the caller’s current operator scopes
Still stuck? Run openclaw status --all and follow Troubleshooting. See Dashboard for auth details.
I set gateway.bind tailnet but it cannot bind and nothing listens
tailnet bind picks a Tailscale IP from your network interfaces (100.64.0.0/10). If the machine isn’t on Tailscale (or the interface is down), there’s nothing to bind to.
Fix:
Start Tailscale on that host (so it has a 100.x address), or
Switch to gateway.bind: "loopback" / "lan".
Note: tailnet is explicit. auto prefers loopback; use gateway.bind: "tailnet" when you want a tailnet-only bind.
Can I run multiple Gateways on the same host?
Usually no - one Gateway can run multiple messaging channels and agents. Use multiple Gateways only when you need redundancy (ex: rescue bot) or hard isolation.
Yes, but you must isolate:
OPENCLAW_CONFIG_PATH (per-instance config)
OPENCLAW_STATE_DIR (per-instance state)
agents.defaults.workspace (workspace isolation)
gateway.port (unique ports)
Quick setup (recommended):
Use `openclaw —profile
…per instance (auto-creates~/.openclaw-
). - Set a unique gateway.portin each profile config (or pass—portfor manual runs). - Install a per-profile service:openclaw —profile
The Gateway is a WebSocket server, and it expects the very first message to
be a connect frame. If it receives anything else, it closes the connection
with code 1008 (policy violation).
Common causes:
You opened the HTTP URL in a browser (http://...) instead of a WS client.
You used the wrong port or path.
A proxy or tunnel stripped auth headers or sent a non-Gateway request.
Quick fixes:
Use the WS URL: `ws://
:18789(orwss://…if HTTPS). 2. Don't open the WS port in a normal browser tab. 3. If auth is on, include the token/password in theconnect` frame.
If you're using the CLI or TUI, the URL should look like:
You can set a stable path via logging.file. File log level is controlled by logging.level. Console verbosity is controlled by --verbose and logging.consoleLevel.
Fastest log tail:
Terminal window
openclawlogs--follow
Service/supervisor logs (when the gateway runs via launchd/systemd):
macOS launchd stdout: ~/Library/Logs/openclaw/gateway.log (profiles use `gateway-
.log; stderr is suppressed) - Linux: journalctl —user -u openclaw-gateway[-
Telegram setMyCommands fails. What should I check?
Start with logs and channel status:
Terminal window
openclawchannelsstatus
openclawchannelslogs--channeltelegram
Then match the error:
BOT_COMMANDS_TOO_MUCH: the Telegram menu has too many entries. OpenClaw already trims to the Telegram limit and retries with fewer commands, but some menu entries still need to be dropped. Reduce plugin/skill/custom commands, or disable channels.telegram.commands.native if you do not need the menu.
TypeError: fetch failed, Network request for 'setMyCommands' failed!, or similar network errors: if you are on a VPS or behind a proxy, confirm outbound HTTPS is allowed and DNS works for api.telegram.org.
If the Gateway is remote, make sure you are looking at logs on the Gateway host.
- The target channel supports outbound media and isn't blocked by allowlists.
- The file is within the provider's size limits (images are resized to max 2048px).
- `tools.fs.workspaceOnly=true` keeps local-path sends limited to workspace, temp/media-store, and sandbox-validated files.
- `tools.fs.workspaceOnly=false` lets `MEDIA:` send host-local files the agent can already read, but only for media plus safe document types (images, audio, video, PDF, and Office docs). Plain text and secret-like files are still blocked.
Treat inbound DMs as untrusted input. Defaults are designed to reduce risk:
Default behavior on DM-capable channels is pairing:
Unknown senders receive a pairing code; the bot does not process their message.
Approve with: `openclaw pairing approve —channel
[—account
]
- Pending requests are capped at **3 per channel**; checkopenclaw pairing list —channel
[—account
] if a code didn't arrive. - Opening DMs publicly requires explicit opt-in (dmPolicy: “open”and allowlist”*”`).
Run `openclaw doctor` to surface risky DM policies.
Is prompt injection only a concern for public bots?
No. Prompt injection is about untrusted content, not just who can DM the bot.
If your assistant reads external content (web search/fetch, browser pages, emails,
docs, attachments, pasted logs), that content can include instructions that try
to hijack the model. This can happen even if you are the only sender.
The biggest risk is when tools are enabled: the model can be tricked into
exfiltrating context or calling tools on your behalf. Reduce the blast radius by:
using a read-only or tool-disabled “reader” agent to summarize untrusted content
keeping web_search / web_fetch / browser off for tool-enabled agents
treating decoded file/document text as untrusted too: OpenResponses
input_file and media-attachment extraction both wrap extracted text in
explicit external-content boundary markers instead of passing raw file text
Is OpenClaw less safe because it uses TypeScript/Node instead of Rust/WASM?
Language and runtime matter, but they are not the main risk for a personal
agent. The practical OpenClaw risks are gateway exposure, who can message the
bot, prompt injection, tool scope, credential handling, browser access, exec
access, and third-party skill or plugin trust.
Rust and WASM can provide stronger isolation for some classes of code, but
they do not solve prompt injection, bad allowlists, public gateway exposure,
overbroad tools, or a browser profile that is already logged in to sensitive
accounts. Treat those as the primary controls:
keep the Gateway private or authenticated
use pairing and allowlists for DMs and groups
deny or sandbox risky tools for untrusted inputs
install only trusted plugins and skills
run openclaw security audit --deep after config changes
I saw reports about exposed OpenClaw instances. What should I check?
First check your actual deployment:
Terminal window
openclawsecurityaudit--deep
openclawgatewaystatus
A safer baseline is:
Gateway bound to loopback, or exposed only through authenticated private
access such as a tailnet, SSH tunnel, token/password auth, or a correctly
configured trusted proxy
DMs in pairing or allowlist mode
groups allowlisted and mention-gated unless every member is trusted
high-risk tools (exec, browser, gateway, cron) denied or tightly
scoped for agents that read untrusted content
sandboxing enabled where tool execution needs a smaller blast radius
Public binds without auth, open DMs/groups with tools, and exposed browser
control are the findings to fix first. Details:
Security audit checklist.
Are ClawHub skills and third-party plugins safe to install?
Treat third-party skills and plugins as code you are choosing to trust.
ClawHub skill pages expose scan state before install, and OpenClaw plugin
install/update flows run built-in dangerous-code checks, but scans are not a
complete security boundary.
Safer pattern:
prefer trusted authors and pinned versions
read the skill or plugin before enabling it
keep plugin and skill allowlists narrow
run untrusted-input workflows in a sandbox with minimal tools
Should my bot have its own email, GitHub account, or phone number?
Yes, for most setups. Isolating the bot with separate accounts and phone numbers
reduces the blast radius if something goes wrong. This also makes it easier to rotate
credentials or revoke access without impacting your personal accounts.
Start small. Give access only to the tools and accounts you actually need, and expand
later if required.
Can I give it autonomy over my text messages and is that safe?
We do not recommend full autonomy over your personal messages. The safest pattern is:
Keep DMs in pairing mode or a tight allowlist.
Use a separate number or account if you want it to message on your behalf.
Let it draft, then approve before sending.
If you want to experiment, do it on a dedicated account and keep it isolated. See
Security.
Can I use cheaper models for personal assistant tasks?
Yes, if the agent is chat-only and the input is trusted. Smaller tiers are
more susceptible to instruction hijacking, so avoid them for tool-enabled agents
or when reading untrusted content. If you must use a smaller model, lock down
tools and run inside a sandbox. See Security.
I ran /start in Telegram but did not get a pairing code
Pairing codes are sent only when an unknown sender messages the bot and
dmPolicy: "pairing" is enabled. /start by itself doesn’t generate a code.
Check pending requests:
Terminal window
openclawpairinglisttelegram
If you want immediate access, allowlist your sender id or set dmPolicy: "open"
for that account.
WhatsApp: will it message my contacts? How does pairing work?
No. Default WhatsApp DM policy is pairing. Unknown senders only get a pairing code and their message is not processed. OpenClaw only replies to chats it receives or to explicit sends you trigger.
Approve pairing with:
Terminal window
openclawpairingapprovewhatsapp
List pending requests:
```bash
openclaw pairing list whatsapp
Wizard phone number prompt: it’s used to set your allowlist/owner so your own DMs are permitted. It’s not used for auto-sending. If you run on your personal WhatsApp number, use that number and enable channels.whatsapp.selfChatMode.
Chat commands, aborting tasks, and “it will not stop”
How do I stop internal system messages from showing in chat?
Most internal or tool messages only appear when verbose, trace, or reasoning is enabled
for that session.
Fix in the chat where you see it:
/verbose off
/trace off
/reasoning off
If it is still noisy, check the session settings in the Control UI and set verbose
to inherit. Also confirm you are not using a bot profile with verboseDefault set
to on in config.
What is the default model for Anthropic with an API key?
In OpenClaw, credentials and model selection are separate. Setting ANTHROPIC_API_KEY (or storing an Anthropic API key in auth profiles) enables authentication, but the actual default model is whatever you configure in agents.defaults.model.primary (for example, anthropic/claude-sonnet-4-6 or anthropic/claude-opus-4-6). If you see No credentials found for profile "anthropic:default", it means the Gateway couldn’t find Anthropic credentials in the expected auth-profiles.json for the agent that’s running.