@takibeiy/moltbot_cn 2026.1.28 → 2026.2.1-beta.1

package/docs/diagnostics/flags.md

@@ -3,7 +3,9 @@ summary: "Diagnostics flags for targeted debug logs"
 read_when:
   - You need targeted debug logs without raising global logging levels
   - You need to capture subsystem-specific logs for support
+title: "Diagnostics Flags"
 ---
+
 # Diagnostics Flags
 
 Diagnostics flags let you enable targeted debug logs without turning on verbose logging everywhere. Flags are opt-in and have no effect unless a subsystem checks them.
@@ -41,13 +43,13 @@ Restart the gateway after changing flags.
 ## Env override (one-off)
 
 ```bash
-CLAWDBOT_DIAGNOSTICS=telegram.http,telegram.payload
+OPENCLAW_DIAGNOSTICS=telegram.http,telegram.payload
 ```
 
 Disable all flags:
 
 ```bash
-CLAWDBOT_DIAGNOSTICS=0
+OPENCLAW_DIAGNOSTICS=0
 ```
 
 ## Where logs go
@@ -55,7 +57,7 @@ CLAWDBOT_DIAGNOSTICS=0
 Flags emit logs into the standard diagnostics log file. By default:
 
 ```
-/tmp/moltbot/moltbot-YYYY-MM-DD.log
+/tmp/openclaw/openclaw-YYYY-MM-DD.log
 ```
 
 If you set `logging.file`, use that path instead. Logs are JSONL (one JSON object per line). Redaction still applies based on `logging.redactSensitive`.
@@ -65,22 +67,22 @@ If you set `logging.file`, use that path instead. Logs are JSONL (one JSON objec
 Pick the latest log file:
 
 ```bash
-ls -t /tmp/moltbot/moltbot-*.log | head -n 1
+ls -t /tmp/openclaw/openclaw-*.log | head -n 1
 ```
 
 Filter for Telegram HTTP diagnostics:
 
 ```bash
-rg "telegram http error" /tmp/moltbot/moltbot-*.log
+rg "telegram http error" /tmp/openclaw/openclaw-*.log
 ```
 
 Or tail while reproducing:
 
 ```bash
-tail -f /tmp/moltbot/moltbot-$(date +%F).log | rg "telegram http error"
+tail -f /tmp/openclaw/openclaw-$(date +%F).log | rg "telegram http error"
 ```
 
-For remote gateways, you can also use `moltbot logs --follow` (see [/cli/logs](/cli/logs)).
+For remote gateways, you can also use `openclaw logs --follow` (see [/cli/logs](/cli/logs)).
 
 ## Notes
 

package/docs/docs.json

@@ -1,6 +1,6 @@
 {
   "$schema": "https://mintlify.com/docs.json",
-  "name": "Moltbot",
+  "name": "OpenClaw",
   "theme": "mint",
   "logo": {
     "light": "/assets/pixel-lobster.svg",
@@ -13,11 +13,11 @@
   "topbarLinks": [
     {
       "name": "GitHub",
-      "url": "https://github.com/moltbot/moltbot"
+      "url": "https://github.com/openclaw/openclaw"
     },
     {
       "name": "Releases",
-      "url": "https://github.com/moltbot/moltbot/releases"
+      "url": "https://github.com/openclaw/openclaw/releases"
     }
   ],
   "redirects": [
@@ -69,6 +69,14 @@
       "source": "/minimax/",
       "destination": "/providers/minimax"
     },
+    {
+      "source": "/xiaomi",
+      "destination": "/providers/xiaomi"
+    },
+    {
+      "source": "/xiaomi/",
+      "destination": "/providers/xiaomi"
+    },
     {
       "source": "/openai",
       "destination": "/providers/openai"
@@ -351,11 +359,27 @@
     },
     {
       "source": "/clawd",
-      "destination": "/start/clawd"
+      "destination": "/start/openclaw"
+    },
+    {
+      "source": "/start/clawd",
+      "destination": "/start/openclaw"
+    },
+    {
+      "source": "/start/clawd/",
+      "destination": "/start/openclaw"
+    },
+    {
+      "source": "/clawhub",
+      "destination": "/tools/clawhub"
     },
     {
       "source": "/clawdhub",
-      "destination": "/tools/clawdhub"
+      "destination": "/tools/clawhub"
+    },
+    {
+      "source": "/tools/clawdhub",
+      "destination": "/tools/clawhub"
     },
     {
       "source": "/configuration",
@@ -824,7 +848,7 @@
           "start/wizard",
           "start/setup",
           "start/pairing",
-          "start/clawd",
+          "start/openclaw",
           "start/showcase",
           "start/hubs",
           "start/onboarding",
@@ -833,11 +857,7 @@
       },
       {
         "group": "Help",
-        "pages": [
-          "help/index",
-          "help/troubleshooting",
-          "help/faq"
-        ]
+        "pages": ["help/index", "help/troubleshooting", "help/faq"]
       },
       {
         "group": "Install & Updates",
@@ -936,7 +956,7 @@
       {
         "group": "Gateway & Ops",
         "pages": [
-          "gateway",
+          "gateway/index",
           "gateway/protocol",
           "gateway/bridge-protocol",
           "gateway/pairing",
@@ -955,7 +975,7 @@
           "gateway/heartbeat",
           "gateway/doctor",
           "gateway/logging",
-          "gateway/security",
+          "gateway/security/index",
           "security/formal-verification",
           "gateway/sandbox-vs-tool-policy-vs-elevated",
           "gateway/sandboxing",
@@ -970,13 +990,7 @@
       },
       {
         "group": "Web & Interfaces",
-        "pages": [
-          "web",
-          "web/control-ui",
-          "web/dashboard",
-          "web/webchat",
-          "tui"
-        ]
+        "pages": ["web/index", "web/control-ui", "web/dashboard", "web/webchat", "tui"]
       },
       {
         "group": "Channels",
@@ -1035,7 +1049,7 @@
       {
         "group": "Tools & Skills",
         "pages": [
-          "tools",
+          "tools/index",
           "tools/lobster",
           "tools/llm-task",
           "plugin",
@@ -1057,13 +1071,13 @@
           "tools/reactions",
           "tools/skills",
           "tools/skills-config",
-          "tools/clawdhub"
+          "tools/clawhub"
         ]
       },
       {
         "group": "Nodes & Media",
         "pages": [
-          "nodes",
+          "nodes/index",
           "nodes/camera",
           "nodes/images",
           "nodes/audio",
@@ -1075,7 +1089,7 @@
       {
         "group": "Platforms",
         "pages": [
-          "platforms",
+          "platforms/index",
           "platforms/macos",
           "platforms/macos-vm",
           "platforms/ios",

package/docs/environment.md

@@ -1,21 +1,23 @@
 ---
-summary: "Where Moltbot loads environment variables and the precedence order"
+summary: "Where OpenClaw loads environment variables and the precedence order"
 read_when:
   - You need to know which env vars are loaded, and in what order
   - You are debugging missing API keys in the Gateway
   - You are documenting provider auth or deployment environments
+title: "Environment Variables"
 ---
+
 # Environment variables
 
-Moltbot pulls environment variables from multiple sources. The rule is **never override existing values**.
+OpenClaw pulls environment variables from multiple sources. The rule is **never override existing values**.
 
 ## Precedence (highest → lowest)
 
-1) **Process environment** (what the Gateway process already has from the parent shell/daemon).
-2) **`.env` in the current working directory** (dotenv default; does not override).
-3) **Global `.env`** at `~/.clawdbot/.env` (aka `$CLAWDBOT_STATE_DIR/.env`; does not override).
-4) **Config `env` block** in `~/.clawdbot/moltbot.json` (applied only if missing).
-5) **Optional login-shell import** (`env.shellEnv.enabled` or `CLAWDBOT_LOAD_SHELL_ENV=1`), applied only for missing expected keys.
+1. **Process environment** (what the Gateway process already has from the parent shell/daemon).
+2. **`.env` in the current working directory** (dotenv default; does not override).
+3. **Global `.env`** at `~/.openclaw/.env` (aka `$OPENCLAW_STATE_DIR/.env`; does not override).
+4. **Config `env` block** in `~/.openclaw/openclaw.json` (applied only if missing).
+5. **Optional login-shell import** (`env.shellEnv.enabled` or `OPENCLAW_LOAD_SHELL_ENV=1`), applied only for missing expected keys.
 
 If the config file is missing entirely, step 4 is skipped; shell import still runs if enabled.
 
@@ -28,9 +30,9 @@ Two equivalent ways to set inline env vars (both are non-overriding):
   env: {
     OPENROUTER_API_KEY: "sk-or-...",
     vars: {
-      GROQ_API_KEY: "gsk-..."
-    }
-  }
+      GROQ_API_KEY: "gsk-...",
+    },
+  },
 }
 ```
 
@@ -43,15 +45,16 @@ Two equivalent ways to set inline env vars (both are non-overriding):
   env: {
     shellEnv: {
       enabled: true,
-      timeoutMs: 15000
-    }
-  }
+      timeoutMs: 15000,
+    },
+  },
 }
 ```
 
 Env var equivalents:
-- `CLAWDBOT_LOAD_SHELL_ENV=1`
-- `CLAWDBOT_SHELL_ENV_TIMEOUT_MS=15000`
+
+- `OPENCLAW_LOAD_SHELL_ENV=1`
+- `OPENCLAW_SHELL_ENV_TIMEOUT_MS=15000`
 
 ## Env var substitution in config
 
@@ -62,10 +65,10 @@ You can reference env vars directly in config string values using `${VAR_NAME}`
   models: {
     providers: {
       "vercel-gateway": {
-        apiKey: "${VERCEL_GATEWAY_API_KEY}"
-      }
-    }
-  }
+        apiKey: "${VERCEL_GATEWAY_API_KEY}",
+      },
+    },
+  },
 }
 ```
 

package/docs/experiments/onboarding-config-protocol.md

@@ -1,6 +1,7 @@
 ---
 summary: "RPC protocol notes for onboarding wizard and config schema"
 read_when: "Changing onboarding wizard steps or config schema endpoints"
+title: "Onboarding and Config Protocol"
 ---
 
 # Onboarding + Config Protocol
@@ -8,6 +9,7 @@ read_when: "Changing onboarding wizard steps or config schema endpoints"
 Purpose: shared onboarding + config surfaces across CLI, macOS app, and Web UI.
 
 ## Components
+
 - Wizard engine (shared session + prompts + onboarding state).
 - CLI onboarding uses the same wizard flow as the UI clients.
 - Gateway RPC exposes wizard + config schema endpoints.
@@ -15,6 +17,7 @@ Purpose: shared onboarding + config surfaces across CLI, macOS app, and Web UI.
 - Web UI renders config forms from JSON Schema + UI hints.
 
 ## Gateway RPC
+
 - `wizard.start` params: `{ mode?: "local"|"remote", workspace?: string }`
 - `wizard.next` params: `{ sessionId, answer?: { stepId, value? } }`
 - `wizard.cancel` params: `{ sessionId }`
@@ -22,13 +25,16 @@ Purpose: shared onboarding + config surfaces across CLI, macOS app, and Web UI.
 - `config.schema` params: `{}`
 
 Responses (shape)
+
 - Wizard: `{ sessionId, done, step?, status?, error? }`
 - Config schema: `{ schema, uiHints, version, generatedAt }`
 
 ## UI Hints
+
 - `uiHints` keyed by path; optional metadata (label/help/group/order/advanced/sensitive/placeholder).
 - Sensitive fields render as password inputs; no redaction layer.
 - Unsupported schema nodes fall back to the raw JSON editor.
 
 ## Notes
+
 - This doc is the single place to track protocol refactors for onboarding/config.

package/docs/experiments/plans/cron-add-hardening.md

@@ -1,16 +1,19 @@
 ---
 summary: "Harden cron.add input handling, align schemas, and improve cron UI/agent tooling"
-owner: "moltbot"
+owner: "openclaw"
 status: "complete"
 last_updated: "2026-01-05"
+title: "Cron Add Hardening"
 ---
 
 # Cron Add Hardening & Schema Alignment
 
 ## Context
+
 Recent gateway logs show repeated `cron.add` failures with invalid parameters (missing `sessionTarget`, `wakeMode`, `payload`, and malformed `schedule`). This indicates that at least one client (likely the agent tool call path) is sending wrapped or partially specified job payloads. Separately, there is drift between cron provider enums in TypeScript, gateway schema, CLI flags, and UI form types, plus a UI mismatch for `cron.status` (expects `jobCount` while gateway returns `jobs`).
 
 ## Goals
+
 - Stop `cron.add` INVALID_REQUEST spam by normalizing common wrapper payloads and inferring missing `kind` fields.
 - Align cron provider lists across gateway schema, cron types, CLI docs, and UI forms.
 - Make agent cron tool schema explicit so the LLM produces correct job payloads.
@@ -18,11 +21,13 @@ Recent gateway logs show repeated `cron.add` failures with invalid parameters (m
 - Add tests to cover normalization and tool behavior.
 
 ## Non-goals
+
 - Change cron scheduling semantics or job execution behavior.
 - Add new schedule kinds or cron expression parsing.
 - Overhaul the UI/UX for cron beyond the necessary field fixes.
 
 ## Findings (current gaps)
+
 - `CronPayloadSchema` in gateway excludes `signal` + `imessage`, while TS types include them.
 - Control UI CronStatus expects `jobCount`, but gateway returns `jobs`.
 - Agent cron tool schema allows arbitrary `job` objects, enabling malformed inputs.
@@ -53,5 +58,6 @@ See [Cron jobs](/automation/cron-jobs) for the normalized shape and examples.
 - Manual Control UI smoke: add a cron job per provider + verify status job count.
 
 ## Open Questions
+
 - Should `cron.add` accept explicit `state` from clients (currently disallowed by schema)?
 - Should we allow `webchat` as an explicit delivery provider (currently filtered in delivery resolution)?

package/docs/experiments/plans/group-policy-hardening.md

@@ -2,7 +2,9 @@
 summary: "Telegram allowlist hardening: prefix + whitespace normalization"
 read_when:
   - Reviewing historical Telegram allowlist changes
+title: "Telegram Allowlist Hardening"
 ---
+
 # Telegram Allowlist Hardening
 
 **Date**: 2026-01-05  
@@ -25,7 +27,7 @@ All of these are accepted for the same ID:
 
 - `telegram:123456`
 - `TG:123456`
-- ` tg:123456 `
+- `tg:123456`
 
 ## Why it matters
 

package/docs/experiments/plans/openresponses-gateway.md

@@ -1,15 +1,16 @@
 ---
 summary: "Plan: Add OpenResponses /v1/responses endpoint and deprecate chat completions cleanly"
-owner: "moltbot"
+owner: "openclaw"
 status: "draft"
 last_updated: "2026-01-19"
+title: "OpenResponses Gateway Plan"
 ---
 
 # OpenResponses Gateway Integration Plan
 
 ## Context
 
-Moltbot Gateway currently exposes a minimal OpenAI-compatible Chat Completions endpoint at
+OpenClaw Gateway currently exposes a minimal OpenAI-compatible Chat Completions endpoint at
 `/v1/chat/completions` (see [OpenAI Chat Completions](/gateway/openai-http-api)).
 
 Open Responses is an open inference standard based on the OpenAI Responses API. It is designed

package/docs/experiments/proposals/model-config.md

@@ -2,11 +2,14 @@
 summary: "Exploration: model config, auth profiles, and fallback behavior"
 read_when:
   - Exploring future model selection + auth profile ideas
+title: "Model Config Exploration"
 ---
+
 # Model Config (Exploration)
 
 This document captures **ideas** for future model configuration. It is not a
 shipping spec. For current behavior, see:
+
 - [Models](/concepts/models)
 - [Model failover](/concepts/model-failover)
 - [OAuth + profiles](/concepts/oauth)
@@ -14,6 +17,7 @@ shipping spec. For current behavior, see:
 ## Motivation
 
 Operators want:
+
 - Multiple auth profiles per provider (personal vs work).
 - Simple `/model` selection with predictable fallbacks.
 - Clear separation between text models and image-capable models.

package/docs/experiments/research/memory.md

@@ -1,26 +1,29 @@
 ---
 summary: "Research notes: offline memory system for Clawd workspaces (Markdown source-of-truth + derived index)"
 read_when:
-  - Designing workspace memory (~/clawd) beyond daily Markdown logs
-  - Deciding: standalone CLI vs deep Moltbot integration
+  - Designing workspace memory (~/.openclaw/workspace) beyond daily Markdown logs
+  - Deciding: standalone CLI vs deep OpenClaw integration
   - Adding offline recall + reflection (retain/recall/reflect)
+title: "Workspace Memory Research"
 ---
 
 # Workspace Memory v2 (offline): research notes
 
-Target: Clawd-style workspace (`agents.defaults.workspace`, default `~/clawd`) where “memory” is stored as one Markdown file per day (`memory/YYYY-MM-DD.md`) plus a small set of stable files (e.g. `memory.md`, `SOUL.md`).
+Target: Clawd-style workspace (`agents.defaults.workspace`, default `~/.openclaw/workspace`) where “memory” is stored as one Markdown file per day (`memory/YYYY-MM-DD.md`) plus a small set of stable files (e.g. `memory.md`, `SOUL.md`).
 
 This doc proposes an **offline-first** memory architecture that keeps Markdown as the canonical, reviewable source of truth, but adds **structured recall** (search, entity summaries, confidence updates) via a derived index.
 
 ## Why change?
 
 The current setup (one file per day) is excellent for:
+
 - “append-only” journaling
 - human editing
 - git-backed durability + auditability
 - low-friction capture (“just write it down”)
 
 It’s weak for:
+
 - high-recall retrieval (“what did we decide about X?”, “last time we tried Y?”)
 - entity-centric answers (“tell me about Alice / The Castle / warelay”) without rereading many files
 - opinion/preference stability (and evidence when it changes)
@@ -38,12 +41,14 @@ It’s weak for:
 
 Two pieces to blend:
 
-1) **Letta/MemGPT-style control loop**
+1. **Letta/MemGPT-style control loop**
+
 - keep a small “core” always in context (persona + key user facts)
 - everything else is out-of-context and retrieved via tools
 - memory writes are explicit tool calls (append/replace/insert), persisted, then re-injected next turn
 
-2) **Hindsight-style memory substrate**
+2. **Hindsight-style memory substrate**
+
 - separate what’s observed vs what’s believed vs what’s summarized
 - support retain/recall/reflect
 - confidence-bearing opinions that can evolve with evidence
@@ -53,12 +58,12 @@ Two pieces to blend:
 
 ### Canonical store (git-friendly)
 
-Keep `~/clawd` as canonical human-readable memory.
+Keep `~/.openclaw/workspace` as canonical human-readable memory.
 
 Suggested workspace layout:
 
 ```
-~/clawd/
+~/.openclaw/workspace/
   memory.md                    # small: durable facts + preferences (core-ish)
   memory/
     YYYY-MM-DD.md              # daily log (append; narrative)
@@ -74,6 +79,7 @@ Suggested workspace layout:
 ```
 
 Notes:
+
 - **Daily log stays daily log**. No need to turn it into JSON.
 - The `bank/` files are **curated**, produced by reflection jobs, and can still be edited by hand.
 - `memory.md` remains “small + core-ish”: the things you want Clawd to see every session.
@@ -83,10 +89,11 @@ Notes:
 Add a derived index under the workspace (not necessarily git tracked):
 
 ```
-~/clawd/.memory/index.sqlite
+~/.openclaw/workspace/.memory/index.sqlite
 ```
 
 Back it with:
+
 - SQLite schema for facts + entity links + opinion metadata
 - SQLite **FTS5** for lexical recall (fast, tiny, offline)
 - optional embeddings table for semantic recall (still offline)
@@ -100,6 +107,7 @@ The index is always **rebuildable from Markdown**.
 Hindsight’s key insight that matters here: store **narrative, self-contained facts**, not tiny snippets.
 
 Practical rule for `memory/YYYY-MM-DD.md`:
+
 - at end of day (or during), add a `## Retain` section with 2–5 bullets that are:
   - narrative (cross-turn context preserved)
   - self-contained (standalone makes sense later)
@@ -115,6 +123,7 @@ Example:
 ```
 
 Minimal parsing:
+
 - Type prefix: `W` (world), `B` (experience/biographical), `O` (opinion), `S` (observation/summary; usually generated)
 - Entities: `@Peter`, `@warelay`, etc (slugs map to `bank/entities/*.md`)
 - Opinion confidence: `O(c=0.0..1.0)` optional
@@ -124,12 +133,14 @@ If you don’t want authors to think about it: the reflect job can infer these b
 ### Recall: queries over the derived index
 
 Recall should support:
+
 - **lexical**: “find exact terms / names / commands” (FTS5)
 - **entity**: “tell me about X” (entity pages + entity-linked facts)
 - **temporal**: “what happened around Nov 27” / “since last week”
 - **opinion**: “what does Peter prefer?” (with confidence + evidence)
 
 Return format should be agent-friendly and cite sources:
+
 - `kind` (`world|experience|opinion|observation`)
 - `timestamp` (source day, or extracted time range if present)
 - `entities` (`["Peter","warelay"]`)
@@ -139,11 +150,13 @@ Return format should be agent-friendly and cite sources:
 ### Reflect: produce stable pages + update beliefs
 
 Reflection is a scheduled job (daily or heartbeat `ultrathink`) that:
+
 - updates `bank/entities/*.md` from recent facts (entity summaries)
 - updates `bank/opinions.md` confidence based on reinforcement/contradiction
 - optionally proposes edits to `memory.md` (“core-ish” durable facts)
 
 Opinion evolution (simple, explainable):
+
 - each opinion has:
   - statement
   - confidence `c ∈ [0,1]`
@@ -155,18 +168,20 @@ Opinion evolution (simple, explainable):
 
 ## CLI integration: standalone vs deep integration
 
-Recommendation: **deep integration in Moltbot**, but keep a separable core library.
+Recommendation: **deep integration in OpenClaw**, but keep a separable core library.
+
+### Why integrate into OpenClaw?
 
-### Why integrate into Moltbot?
-- Moltbot already knows:
+- OpenClaw already knows:
   - the workspace path (`agents.defaults.workspace`)
   - the session model + heartbeats
   - logging + troubleshooting patterns
 - You want the agent itself to call the tools:
-  - `moltbot memory recall "…" --k 25 --since 30d`
-  - `moltbot memory reflect --since 7d`
+  - `openclaw memory recall "…" --k 25 --since 30d`
+  - `openclaw memory reflect --since 7d`
 
 ### Why still split a library?
+
 - keep memory logic testable without gateway/runtime
 - reuse from other contexts (local scripts, future desktop app, etc.)
 
@@ -177,7 +192,8 @@ The memory tooling is intended to be a small CLI + library layer, but this is ex
 
 If “S-Collide” refers to **SuCo (Subspace Collision)**: it’s an ANN retrieval approach that targets strong recall/latency tradeoffs by using learned/structured collisions in subspaces (paper: arXiv 2411.14754, 2024).
 
-Pragmatic take for `~/clawd`:
+Pragmatic take for `~/.openclaw/workspace`:
+
 - **don’t start** with SuCo.
 - start with SQLite FTS + (optional) simple embeddings; you’ll get most UX wins immediately.
 - consider SuCo/HNSW/ScaNN-class solutions only once:
@@ -186,12 +202,14 @@ Pragmatic take for `~/clawd`:
   - recall quality is meaningfully bottlenecked by lexical search
 
 Offline-friendly alternatives (in increasing complexity):
+
 - SQLite FTS5 + metadata filters (zero ML)
 - Embeddings + brute force (works surprisingly far if chunk count is low)
 - HNSW index (common, robust; needs a library binding)
 - SuCo (research-grade; attractive if there’s a solid implementation you can embed)
 
 Open question:
+
 - what’s the **best** offline embedding model for “personal assistant memory” on your machines (laptop + desktop)?
   - if you already have Ollama: embed with a local model; otherwise ship a small embedding model in the toolchain.