@gguf/pigbot 0.0.1 → 0.0.2

package/docs/tools/chrome-extension.md

@@ -1,5 +1,5 @@
 ---
-summary: "Chrome extension: let Pigbot drive your existing Chrome tab"
+summary: "Chrome extension: let Moltbot drive your existing Chrome tab"
 read_when:
   - You want the agent to drive an existing Chrome tab (toolbar button)
   - You need remote Gateway + local browser automation via Tailscale
@@ -8,31 +8,31 @@ read_when:
 
 # Chrome extension (browser relay)
 
-The Pigbot Chrome extension lets the agent control your **existing Chrome tabs** (your normal Chrome window) instead of launching a separate clawd-managed Chrome profile.
+The Moltbot Chrome extension lets the agent control your **existing Chrome tabs** (your normal Chrome window) instead of launching a separate clawd-managed Chrome profile.
 
 Attach/detach happens via a **single Chrome toolbar button**.
 
 ## What it is (concept)
 
 There are three parts:
-- **Browser control server** (HTTP): the API the agent/tool calls (`browser.controlUrl`)
+- **Browser control service** (Gateway or node): the API the agent/tool calls (via the Gateway)
 - **Local relay server** (loopback CDP): bridges between the control server and the extension (`http://127.0.0.1:18792` by default)
 - **Chrome MV3 extension**: attaches to the active tab using `chrome.debugger` and pipes CDP messages to the relay
 
-Pigbot then controls the attached tab through the normal `browser` tool surface (selecting the right profile).
+Moltbot then controls the attached tab through the normal `browser` tool surface (selecting the right profile).
 
 ## Install / load (unpacked)
 
 1) Install the extension to a stable local path:
 
 ```bash
-pigbot browser extension install
+moltbot browser extension install
 ```
 
 2) Print the installed extension directory path:
 
 ```bash
-pigbot browser extension path
+moltbot browser extension path
 ```
 
 3) Chrome → `chrome://extensions`
@@ -43,24 +43,24 @@ pigbot browser extension path
 
 ## Updates (no build step)
 
-The extension ships inside the Pigbot release (npm package) as static files. There is no separate “build” step.
+The extension ships inside the Moltbot release (npm package) as static files. There is no separate “build” step.
 
-After upgrading Pigbot:
-- Re-run `pigbot browser extension install` to refresh the installed files under your Pigbot state directory.
+After upgrading Moltbot:
+- Re-run `moltbot browser extension install` to refresh the installed files under your Moltbot state directory.
 - Chrome → `chrome://extensions` → click “Reload” on the extension.
 
 ## Use it (no extra config)
 
-Pigbot ships with a built-in browser profile named `chrome` that targets the extension relay on the default port.
+Moltbot ships with a built-in browser profile named `chrome` that targets the extension relay on the default port.
 
 Use it:
-- CLI: `pigbot browser --browser-profile chrome tabs`
+- CLI: `moltbot browser --browser-profile chrome tabs`
 - Agent tool: `browser` with `profile="chrome"`
 
 If you want a different name or a different relay port, create your own profile:
 
 ```bash
-pigbot browser create-profile \
+moltbot browser create-profile \
   --name my-chrome \
   --driver extension \
   --cdp-url http://127.0.0.1:18792 \
@@ -69,7 +69,7 @@ pigbot browser create-profile \
 
 ## Attach / detach (toolbar button)
 
-- Open the tab you want Pigbot to control.
+- Open the tab you want Moltbot to control.
 - Click the extension icon.
   - Badge shows `ON` when attached.
 - Click again to detach.
@@ -82,28 +82,27 @@ pigbot browser create-profile \
 
 ## Badge + common errors
 
-- `ON`: attached; Pigbot can drive that tab.
+- `ON`: attached; Moltbot can drive that tab.
 - `…`: connecting to the local relay.
 - `!`: relay not reachable (most common: browser relay server isn’t running on this machine).
 
 If you see `!`:
-- Make sure the Gateway is running locally (default setup), or run `pigbot browser serve` on this machine (remote gateway setup).
+- Make sure the Gateway is running locally (default setup), or run a node host on this machine if the Gateway runs elsewhere.
 - Open the extension Options page; it shows whether the relay is reachable.
 
-## Do I need `pigbot browser serve`?
+## Remote Gateway (use a node host)
 
-### Local Gateway (same machine as Chrome) — usually **no**
+### Local Gateway (same machine as Chrome) — usually **no extra steps**
 
-If the Gateway is running on the same machine as Chrome and your `browser.controlUrl` is loopback (default),
-you typically **do not** need `pigbot browser serve`.
+If the Gateway runs on the same machine as Chrome, it starts the browser control service on loopback
+and auto-starts the relay server. The extension talks to the local relay; the CLI/tool calls go to the Gateway.
 
-The Gateway’s built-in browser control server will start on `http://127.0.0.1:18791/` and Pigbot will
-auto-start the local relay server on `http://127.0.0.1:18792/`.
+### Remote Gateway (Gateway runs elsewhere) — **run a node host**
 
-### Remote Gateway (Gateway runs elsewhere) — **yes**
+If your Gateway runs on another machine, start a node host on the machine that runs Chrome.
+The Gateway will proxy browser actions to that node; the extension + relay stay local to the browser machine.
 
-If your Gateway runs on another machine, run `pigbot browser serve` on the machine that runs Chrome
-(and publish it via Tailscale Serve / TLS). See the section below.
+If multiple nodes are connected, pin one with `gateway.nodes.browser.node` or set `gateway.nodes.browser.mode`.
 
 ## Sandboxing (tool containers)
 
@@ -132,34 +131,18 @@ Options:
 
 Then ensure the tool isn’t denied by tool policy, and (if needed) call `browser` with `target="host"`.
 
-Debugging: `pigbot sandbox explain`
+Debugging: `moltbot sandbox explain`
 
-## Remote Gateway (recommended: Tailscale Serve)
+## Remote access tips
 
-Goal: Gateway runs on one machine, but Chrome runs somewhere else.
-
-On the **browser machine**:
-
-```bash
-pigbot browser serve --bind 127.0.0.1 --port 18791 --token <token>
-tailscale serve https / http://127.0.0.1:18791
-```
-
-On the **Gateway machine**:
-- Set `browser.controlUrl` to the HTTPS Serve URL (MagicDNS/ts.net).
-- Provide the token (prefer env):
-
-```bash
-export PIGBOT_BROWSER_CONTROL_TOKEN="<token>"
-```
-
-Then the agent can drive the browser by calling the remote `browser.controlUrl` API, while the extension + relay stay local on the browser machine.
+- Keep the Gateway and node host on the same tailnet; avoid exposing relay ports to LAN or public Internet.
+- Pair nodes intentionally; disable browser proxy routing if you don’t want remote control (`gateway.nodes.browser.mode="off"`).
 
 ## How “extension path” works
 
-`pigbot browser extension path` prints the **installed** on-disk directory containing the extension files.
+`moltbot browser extension path` prints the **installed** on-disk directory containing the extension files.
 
-The CLI intentionally does **not** print a `node_modules` path. Always run `pigbot browser extension install` first to copy the extension to a stable location under your Pigbot state directory.
+The CLI intentionally does **not** print a `node_modules` path. Always run `moltbot browser extension install` first to copy the extension to a stable location under your Moltbot state directory.
 
 If you move or delete that install directory, Chrome will mark the extension as broken until you reload it from a valid path.
 
@@ -176,8 +159,8 @@ This is powerful and risky. Treat it like giving the model “hands on your brow
 
 Recommendations:
 - Prefer a dedicated Chrome profile (separate from your personal browsing) for extension relay usage.
-- Keep the browser control server tailnet-only (Tailscale) and require a token.
-- Avoid exposing browser control over LAN (`0.0.0.0`) and avoid Funnel (public).
+- Keep the Gateway and any node hosts tailnet-only; rely on Gateway auth + node pairing.
+- Avoid exposing relay ports over LAN (`0.0.0.0`) and avoid Funnel (public).
 
 Related:
 - Browser tool overview: [Browser](/tools/browser)

package/docs/tools/clawdhub.md

@@ -8,13 +8,13 @@ read_when:
 
 # ClawdHub
 
-ClawdHub is the **public skill registry for Pigbot**. It is a free service: all skills are public, open, and visible to everyone for sharing and reuse. A skill is just a folder with a `SKILL.md` file (plus supporting text files). You can browse skills in the web app or use the CLI to search, install, update, and publish skills.
+ClawdHub is the **public skill registry for Moltbot**. It is a free service: all skills are public, open, and visible to everyone for sharing and reuse. A skill is just a folder with a `SKILL.md` file (plus supporting text files). You can browse skills in the web app or use the CLI to search, install, update, and publish skills.
 
 Site: [clawdhub.com](https://clawdhub.com)
 
 ## Who this is for (beginner-friendly)
 
-If you want to add new capabilities to your Pigbot agent, ClawdHub is the easiest way to find and install skills. You do not need to know how the backend works. You can:
+If you want to add new capabilities to your Moltbot agent, ClawdHub is the easiest way to find and install skills. You do not need to know how the backend works. You can:
 
 - Search for skills by plain language.
 - Install a skill into your workspace.
@@ -28,7 +28,7 @@ If you want to add new capabilities to your Pigbot agent, ClawdHub is the easies
    - `clawdhub search "calendar"`
 3) Install a skill:
    - `clawdhub install <skill-slug>`
-4) Start a new Pigbot session so it picks up the new skill.
+4) Start a new Moltbot session so it picks up the new skill.
 
 ## Install the CLI
 
@@ -42,9 +42,9 @@ npm i -g clawdhub
 pnpm add -g clawdhub
 ```
 
-## How it fits into Pigbot
+## How it fits into Moltbot
 
-By default, the CLI installs skills into `./skills` under your current working directory. If a Pigbot workspace is configured, `clawdhub` falls back to that workspace unless you override `--workdir` (or `CLAWDHUB_WORKDIR`). Pigbot loads workspace skills from `<workspace>/skills` and will pick them up in the **next** session. If you already use `~/.pigbot/skills` or bundled skills, workspace skills take precedence.
+By default, the CLI installs skills into `./skills` under your current working directory. If a Moltbot workspace is configured, `clawdhub` falls back to that workspace unless you override `--workdir` (or `CLAWDHUB_WORKDIR`). Moltbot loads workspace skills from `<workspace>/skills` and will pick them up in the **next** session. If you already use `~/.clawdbot/skills` or bundled skills, workspace skills take precedence.
 
 For more detail on how skills are loaded, shared, and gated, see
 [Skills](/tools/skills).
@@ -63,7 +63,7 @@ For more detail on how skills are loaded, shared, and gated, see
 
 Global options (apply to all commands):
 
-- `--workdir <dir>`: Working directory (default: current dir; falls back to Pigbot workspace).
+- `--workdir <dir>`: Working directory (default: current dir; falls back to Moltbot workspace).
 - `--dir <dir>`: Skills directory, relative to workdir (default: `skills`).
 - `--site <url>`: Site base URL (browser login).
 - `--registry <url>`: Registry API base URL.
@@ -177,7 +177,7 @@ Updates compare the local skill contents to registry versions using a content ha
 
 ### Sync scanning and fallback roots
 
-`clawdhub sync` scans your current workdir first. If no skills are found, it falls back to known legacy locations (for example `~/pigbot/skills` and `~/.pigbot/skills`). This is designed to find older skill installs without extra flags.
+`clawdhub sync` scans your current workdir first. If no skills are found, it falls back to known legacy locations (for example `~/moltbot/skills` and `~/.clawdbot/skills`). This is designed to find older skill installs without extra flags.
 
 ### Storage and lockfile
 

package/docs/tools/creating-skills.md

@@ -0,0 +1,41 @@
+# Creating Custom Skills 🛠
+
+Moltbot is designed to be easily extensible. "Skills" are the primary way to add new capabilities to your assistant.
+
+## What is a Skill?
+A skill is a directory containing a `SKILL.md` file (which provides instructions and tool definitions to the LLM) and optionally some scripts or resources.
+
+## Step-by-Step: Your First Skill
+
+### 1. Create the Directory
+Skills live in your workspace, usually `~/clawd/skills/`. Create a new folder for your skill:
+```bash
+mkdir -p ~/clawd/skills/hello-world
+```
+
+### 2. Define the `SKILL.md`
+Create a `SKILL.md` file in that directory. This file uses YAML frontmatter for metadata and Markdown for instructions.
+
+```markdown
+---
+name: hello_world
+description: A simple skill that says hello.
+---
+
+# Hello World Skill
+When the user asks for a greeting, use the `echo` tool to say "Hello from your custom skill!".
+```
+
+### 3. Add Tools (Optional)
+You can define custom tools in the frontmatter or instruct the agent to use existing system tools (like `bash` or `browser`).
+
+### 4. Refresh Moltbot
+Ask your agent to "refresh skills" or restart the gateway. Moltbot will discover the new directory and index the `SKILL.md`.
+
+## Best Practices
+- **Be Concise**: Instruct the model on *what* to do, not how to be an AI.
+- **Safety First**: If your skill uses `bash`, ensure the prompts don't allow arbitrary command injection from untrusted user input.
+- **Test Locally**: Use `moltbot agent --message "use my new skill"` to test.
+
+## Shared Skills
+You can also browse and contribute skills to [ClawdHub](https://clawdhub.com).

package/docs/tools/elevated.md

@@ -23,6 +23,7 @@ read_when:
 - **Approvals**: `full` skips exec approvals; `on`/`ask` honor them when allowlist/ask rules require.
 - **Unsandboxed agents**: no-op for location; only affects gating, logging, and status.
 - **Tool policy still applies**: if `exec` is denied by tool policy, elevated cannot be used.
+- **Separate from `/exec`**: `/exec` adjusts per-session defaults for authorized senders and does not require elevated.
 
 ## Resolution order
 1. Inline directive on the message (applies only to that message).

package/docs/tools/exec-approvals.md

@@ -20,7 +20,7 @@ resolved by the **ask fallback** (default: deny).
 ## Where it applies
 
 Exec approvals are enforced locally on the execution host:
-- **gateway host** → `pigbot` process on the gateway machine
+- **gateway host** → `moltbot` process on the gateway machine
 - **node host** → node runner (macOS companion app or headless node host)
 
 macOS split:
@@ -31,14 +31,14 @@ macOS split:
 
 Approvals live in a local JSON file on the execution host:
 
-`~/.pigbot/exec-approvals.json`
+`~/.clawdbot/exec-approvals.json`
 
 Example schema:
 ```json
 {
   "version": 1,
   "socket": {
-    "path": "~/.pigbot/exec-approvals.sock",
+    "path": "~/.clawdbot/exec-approvals.sock",
     "token": "base64url-token"
   },
   "defaults": {
@@ -131,9 +131,9 @@ per pattern so you can keep the list tidy.
 The target selector chooses **Gateway** (local approvals) or a **Node**. Nodes
 must advertise `system.execApprovals.get/set` (macOS app or headless node host).
 If a node does not advertise exec approvals yet, edit its local
-`~/.pigbot/exec-approvals.json` directly.
+`~/.clawdbot/exec-approvals.json` directly.
 
-CLI: `pigbot approvals` supports gateway or node editing (see [Approvals CLI](/cli/approvals)).
+CLI: `moltbot approvals` supports gateway or node editing (see [Approvals CLI](/cli/approvals)).
 
 ## Approval flow
 
@@ -216,6 +216,9 @@ Approval-gated execs reuse the approval id as the `runId` in these messages for
 - **full** is powerful; prefer allowlists when possible.
 - **ask** keeps you in the loop while still allowing fast approvals.
 - Per-agent allowlists prevent one agent’s approvals from leaking into others.
+- Approvals only apply to host exec requests from **authorized senders**. Unauthorized senders cannot issue `/exec`.
+- `/exec security=full` is a session-level convenience for authorized operators and skips approvals by design.
+  To hard-block host exec, set approvals security to `deny` or deny the `exec` tool via tool policy.
 
 Related:
 - [Exec tool](/tools/exec)

package/docs/tools/exec.md

@@ -29,11 +29,14 @@ Background sessions are scoped per agent; `process` only sees sessions from the
 Notes:
 - `host` defaults to `sandbox`.
 - `elevated` is ignored when sandboxing is off (exec already runs on the host).
-- `gateway`/`node` approvals are controlled by `~/.pigbot/exec-approvals.json`.
+- `gateway`/`node` approvals are controlled by `~/.clawdbot/exec-approvals.json`.
 - `node` requires a paired node (companion app or headless node host).
 - If multiple nodes are available, set `exec.node` or `tools.exec.node` to select one.
 - On non-Windows hosts, exec uses `SHELL` when set; if `SHELL` is `fish`, it prefers `bash` (or `sh`)
   from `PATH` to avoid fish-incompatible scripts, then falls back to `SHELL` if neither exists.
+- Important: sandboxing is **off by default**. If sandboxing is off, `host=sandbox` runs directly on
+  the gateway host (no container) and **does not require approvals**. To require approvals, run with
+  `host=gateway` and configure exec approvals (or enable sandboxing).
 
 ## Config
 
@@ -64,7 +67,8 @@ Example:
   - macOS: `/opt/homebrew/bin`, `/usr/local/bin`, `/usr/bin`, `/bin`
   - Linux: `/usr/local/bin`, `/usr/bin`, `/bin`
 - `host=sandbox`: runs `sh -lc` (login shell) inside the container, so `/etc/profile` may reset `PATH`.
-  Pigbot prepends `env.PATH` after profile sourcing; `tools.exec.pathPrepend` applies here too.
+  Moltbot prepends `env.PATH` after profile sourcing via an internal env var (no shell interpolation);
+  `tools.exec.pathPrepend` applies here too.
 - `host=node`: only env overrides you pass are sent to the node. `tools.exec.pathPrepend` only applies
   if the exec call already sets `env.PATH`. Headless node hosts accept `PATH` only when it prepends
   the node host PATH (no replacement). macOS nodes drop `PATH` overrides entirely.
@@ -72,8 +76,8 @@ Example:
 Per-agent node binding (use the agent list index in config):
 
 ```bash
-pigbot config get agents.list
-pigbot config set agents.list[0].tools.exec.node "node-id-or-name"
+moltbot config get agents.list
+moltbot config set agents.list[0].tools.exec.node "node-id-or-name"
 ```
 
 Control UI: the Nodes tab includes a small “Exec node binding” panel for the same settings.
@@ -88,6 +92,13 @@ Example:
 /exec host=gateway security=allowlist ask=on-miss node=mac-1
 ```
 
+## Authorization model
+
+`/exec` is only honored for **authorized senders** (channel allowlists/pairing plus `commands.useAccessGroups`).
+It updates **session state only** and does not write config. To hard-disable exec, deny it via tool
+policy (`tools.deny: ["exec"]` or per-agent). Host approvals still apply unless you explicitly set
+`security=full` and `ask=off`.
+
 ## Exec approvals (companion app / node host)
 
 Sandboxed agents can require per-request approval before `exec` runs on the gateway or node host.

package/docs/tools/firecrawl.md

@@ -8,7 +8,7 @@ read_when:
 
 # Firecrawl
 
-Pigbot can use **Firecrawl** as a fallback extractor for `web_fetch`. It is a hosted
+Moltbot can use **Firecrawl** as a fallback extractor for `web_fetch`. It is a hosted
 content extraction service that supports bot circumvention and caching, which helps
 with JS-heavy sites or pages that block plain HTTP fetches.
 
@@ -44,7 +44,7 @@ Notes:
 ## Stealth / bot circumvention
 
 Firecrawl exposes a **proxy mode** parameter for bot circumvention (`basic`, `stealth`, or `auto`).
-Pigbot always uses `proxy: "auto"` plus `storeInCache: true` for Firecrawl requests.
+Moltbot always uses `proxy: "auto"` plus `storeInCache: true` for Firecrawl requests.
 If proxy is omitted, Firecrawl defaults to `auto`. `auto` retries with stealth proxies if a basic attempt fails, which may use more credits
 than basic-only scraping.
 

package/docs/tools/index.md

@@ -1,19 +1,19 @@
 ---
-summary: "Agent tool surface for Pigbot (browser, canvas, nodes, message, cron) replacing legacy `pigbot-*` skills"
+summary: "Agent tool surface for Moltbot (browser, canvas, nodes, message, cron) replacing legacy `moltbot-*` skills"
 read_when:
   - Adding or modifying agent tools
-  - Retiring or changing `pigbot-*` skills
+  - Retiring or changing `moltbot-*` skills
 ---
 
-# Tools (Pigbot)
+# Tools (Moltbot)
 
-Pigbot exposes **first-class agent tools** for browser, canvas, nodes, and cron.
-These replace the old `pigbot-*` skills: the tools are typed, no shelling,
+Moltbot exposes **first-class agent tools** for browser, canvas, nodes, and cron.
+These replace the old `moltbot-*` skills: the tools are typed, no shelling,
 and the agent should rely on them directly.
 
 ## Disabling tools
 
-You can globally allow/deny tools via `tools.allow` / `tools.deny` in `pigbot.json`
+You can globally allow/deny tools via `tools.allow` / `tools.deny` in `moltbot.json`
 (deny wins). This prevents disallowed tools from being sent to model providers.
 
 ```json5
@@ -25,7 +25,7 @@ You can globally allow/deny tools via `tools.allow` / `tools.deny` in `pigbot.js
 Notes:
 - Matching is case-insensitive.
 - `*` wildcards are supported (`"*"` means all tools).
-- If `tools.allow` only references unknown or unloaded plugin tool names, Pigbot logs a warning and ignores the allowlist so core tools stay available.
+- If `tools.allow` only references unknown or unloaded plugin tool names, Moltbot logs a warning and ignores the allowlist so core tools stay available.
 
 ## Tool profiles (base allowlist)
 
@@ -141,7 +141,7 @@ Available groups:
 - `group:automation`: `cron`, `gateway`
 - `group:messaging`: `message`
 - `group:nodes`: `nodes`
-- `group:pigbot`: all built-in Pigbot tools (excludes provider plugins)
+- `group:moltbot`: all built-in Moltbot tools (excludes provider plugins)
 
 Example (allow only file tools + browser):
 ```json5
@@ -190,7 +190,7 @@ Notes:
 - If `process` is disallowed, `exec` runs synchronously and ignores `yieldMs`/`background`.
 - `elevated` is gated by `tools.elevated` plus any `agents.list[].tools.elevated` override (both must allow) and is an alias for `host=gateway` + `security=full`.
 - `elevated` only changes behavior when the agent is sandboxed (otherwise it’s a no-op).
-- `host=node` can target a macOS companion app or a headless node host (`pigbot node run`).
+- `host=node` can target a macOS companion app or a headless node host (`moltbot node run`).
 - gateway/node approvals and allowlists: [Exec approvals](/tools/exec-approvals).
 
 ### `process`
@@ -212,7 +212,7 @@ Core parameters:
 - `count` (1–10; default from `tools.web.search.maxResults`)
 
 Notes:
-- Requires a Brave API key (recommended: `pigbot configure --section web`, or set `BRAVE_API_KEY`).
+- Requires a Brave API key (recommended: `moltbot configure --section web`, or set `BRAVE_API_KEY`).
 - Enable via `tools.web.search.enabled`.
 - Responses are cached (default 15 min).
 - See [Web tools](/tools/web) for setup.
@@ -249,16 +249,17 @@ Profile management:
 - `reset-profile` — kill orphan process on profile's port (local only)
 
 Common parameters:
-- `controlUrl` (defaults from config)
 - `profile` (optional; defaults to `browser.defaultProfile`)
+- `target` (`sandbox` | `host` | `node`)
+- `node` (optional; picks a specific node id/name)
 Notes:
 - Requires `browser.enabled=true` (default is `true`; set `false` to disable).
-- Uses `browser.controlUrl` unless `controlUrl` is passed explicitly.
 - All actions accept optional `profile` parameter for multi-instance support.
 - When `profile` is omitted, uses `browser.defaultProfile` (defaults to "chrome").
 - Profile names: lowercase alphanumeric + hyphens only (max 64 chars).
 - Port range: 18800-18899 (~100 profiles max).
 - Remote profiles are attach-only (no start/stop/reset).
+- If a browser-capable node is connected, the tool may auto-route to it (unless you pin `target`).
 - `snapshot` defaults to `ai` when Playwright is installed; use `aria` for the accessibility tree.
 - `snapshot` also supports role-snapshot options (`interactive`, `compact`, `depth`, `selector`) which return refs like `e12`.
 - `act` requires `ref` from `snapshot` (numeric `12` from AI snapshots, or `e12` from role snapshots); use `evaluate` for rare CSS selector needs.
@@ -278,7 +279,7 @@ Notes:
 - Uses gateway `node.invoke` under the hood.
 - If no `node` is provided, the tool picks a default (single connected node or local mac node).
 - A2UI is v0.8 only (no `createSurface`); the CLI rejects v0.9 JSONL with line errors.
-- Quick smoke: `pigbot nodes canvas a2ui push --node <id> --text "Hello from A2UI"`.
+- Quick smoke: `moltbot nodes canvas a2ui push --node <id> --text "Hello from A2UI"`.
 
 ### `nodes`
 Discover and target paired nodes; send notifications; capture camera/screen.
@@ -365,7 +366,7 @@ Notes:
 Restart or apply updates to the running Gateway process (in-place).
 
 Core actions:
-- `restart` (authorizes + sends `SIGUSR1` for in-process restart; `pigbot gateway` restart in-place)
+- `restart` (authorizes + sends `SIGUSR1` for in-process restart; `moltbot gateway` restart in-place)
 - `config.get` / `config.schema`
 - `config.apply` (validate + write config + restart + wake)
 - `config.patch` (merge partial update + restart + wake)
@@ -410,7 +411,9 @@ Gateway-backed tools (`canvas`, `nodes`, `cron`):
 - `timeoutMs`
 
 Browser tool:
-- `controlUrl` (defaults from config)
+- `profile` (optional; defaults to `browser.defaultProfile`)
+- `target` (`sandbox` | `host` | `node`)
+- `node` (optional; pin a specific node id/name)
 
 ## Recommended agent flows
 

package/docs/tools/llm-task.md

@@ -11,7 +11,7 @@ read_when:
 returns structured output (optionally validated against JSON Schema).
 
 This is ideal for workflow engines like Lobster: you can add a single LLM step
-without writing custom Pigbot code for each workflow.
+without writing custom Moltbot code for each workflow.
 
 ## Enable the plugin
 

package/docs/tools/lobster.md

@@ -1,7 +1,7 @@
 ---
 title: Lobster
-summary: "Typed workflow runtime for Pigbot with resumable approval gates."
-description: Typed workflow runtime for Pigbot — composable pipelines with approval gates.
+summary: "Typed workflow runtime for Moltbot with resumable approval gates."
+description: Typed workflow runtime for Moltbot — composable pipelines with approval gates.
 read_when:
   - You want deterministic multi-step workflows with explicit approvals
   - You need to resume a workflow without re-running earlier steps
@@ -9,7 +9,7 @@ read_when:
 
 # Lobster
 
-Lobster is a workflow shell that lets Pigbot run multi-step tool sequences as a single, deterministic operation with explicit approval checkpoints.
+Lobster is a workflow shell that lets Moltbot run multi-step tool sequences as a single, deterministic operation with explicit approval checkpoints.
 
 ## Hook
 
@@ -19,7 +19,7 @@ Your assistant can build the tools that manage itself. Ask for a workflow, and 3
 
 Today, complex workflows require many back-and-forth tool calls. Each call costs tokens, and the LLM has to orchestrate every step. Lobster moves that orchestration into a typed runtime:
 
-- **One call instead of many**: Pigbot runs one Lobster tool call and gets a structured result.
+- **One call instead of many**: Moltbot runs one Lobster tool call and gets a structured result.
 - **Approvals built in**: Side effects (send email, post comment) halt the workflow until explicitly approved.
 - **Resumable**: Halted workflows return a token; approve and resume without re-running everything.
 
@@ -35,7 +35,7 @@ Lobster is intentionally small. The goal is not "a new language," it's a predict
 
 ## How it works
 
-Pigbot launches the local `lobster` CLI in **tool mode** and parses a JSON envelope from stdout.
+Moltbot launches the local `lobster` CLI in **tool mode** and parses a JSON envelope from stdout.
 If the pipeline pauses for approval, the tool returns a `resumeToken` so you can continue later.
 
 ## Pattern: small CLI + JSON pipes + approvals
@@ -123,7 +123,7 @@ See [LLM Task](/tools/llm-task) for details and configuration options.
 
 ## Workflow files (.lobster)
 
-Lobster can run YAML/JSON workflow files with `name`, `args`, `steps`, `env`, `condition`, and `approval` fields. In Pigbot tool calls, set `pipeline` to the file path.
+Lobster can run YAML/JSON workflow files with `name`, `args`, `steps`, `env`, `condition`, and `approval` fields. In Moltbot tool calls, set `pipeline` to the file path.
 
 ```yaml
 name: inbox-triage
@@ -153,12 +153,24 @@ Notes:
 
 ## Install Lobster
 
-Install the Lobster CLI on the **same host** that runs the Pigbot Gateway (see the [Lobster repo](https://github.com/pigbot/lobster)), and ensure `lobster` is on `PATH`.
+Install the Lobster CLI on the **same host** that runs the Moltbot Gateway (see the [Lobster repo](https://github.com/moltbot/lobster)), and ensure `lobster` is on `PATH`.
 If you want to use a custom binary location, pass an **absolute** `lobsterPath` in the tool call.
 
 ## Enable the tool
 
-Lobster is an **optional** plugin tool (not enabled by default). Allow it per agent:
+Lobster is an **optional** plugin tool (not enabled by default).
+
+Recommended (additive, safe):
+
+```json
+{
+  "tools": {
+    "alsoAllow": ["lobster"]
+  }
+}
+```
+
+Or per-agent:
 
 ```json
 {
@@ -167,7 +179,7 @@ Lobster is an **optional** plugin tool (not enabled by default). Allow it per ag
       {
         "id": "main",
         "tools": {
-          "allow": ["lobster"]
+          "alsoAllow": ["lobster"]
         }
       }
     ]
@@ -175,10 +187,10 @@ Lobster is an **optional** plugin tool (not enabled by default). Allow it per ag
 }
 ```
 
-You can also allow it globally with `tools.allow` if every agent should see it.
+Avoid using `tools.allow: ["lobster"]` unless you intend to run in restrictive allowlist mode.
 
 Note: allowlists are opt-in for optional plugins. If your allowlist only names
-plugin tools (like `lobster`), Pigbot keeps core tools enabled. To restrict core
+plugin tools (like `lobster`), Moltbot keeps core tools enabled. To restrict core
 tools, include the core tools or groups you want in the allowlist too.
 
 ## Example: Email triage

package/docs/tools/skills-config.md

@@ -6,7 +6,7 @@ read_when:
 ---
 # Skills Config
 
-All skills-related configuration lives under `skills` in `~/.pigbot/pigbot.json`.
+All skills-related configuration lives under `skills` in `~/.clawdbot/moltbot.json`.
 
 ```json5
 {
@@ -60,7 +60,7 @@ Per-skill fields:
 ## Notes
 
 - Keys under `entries` map to the skill name by default. If a skill defines
-  `metadata.pigbot.skillKey`, use that key instead.
+  `metadata.clawdbot.skillKey`, use that key instead.
 - Changes to skills are picked up on the next agent turn when the watcher is enabled.
 
 ### Sandboxed skills + env vars