@gguf/pigbot 0.0.1 → 0.0.3

package/docs/gateway/multiple-gateways.md

@@ -1,5 +1,5 @@
 ---
-summary: "Run multiple Pigbot Gateways on one host (isolation, ports, and profiles)"
+summary: "Run multiple Moltbot Gateways on one host (isolation, ports, and profiles)"
 read_when:
   - Running more than one Gateway on the same machine
   - You need isolated config/state/ports per Gateway
@@ -9,8 +9,8 @@ read_when:
 Most setups should use one Gateway because a single Gateway can handle multiple messaging connections and agents. If you need stronger isolation or redundancy (e.g., a rescue bot), run separate Gateways with isolated profiles/ports.
 
 ## Isolation checklist (required)
-- `PIGBOT_CONFIG_PATH` — per-instance config file
-- `PIGBOT_STATE_DIR` — per-instance sessions, creds, caches
+- `CLAWDBOT_CONFIG_PATH` — per-instance config file
+- `CLAWDBOT_STATE_DIR` — per-instance sessions, creds, caches
 - `agents.defaults.workspace` — per-instance workspace root
 - `gateway.port` (or `--port`) — unique per instance
 - Derived ports (browser/canvas) must not overlap
@@ -19,22 +19,22 @@ If these are shared, you will hit config races and port conflicts.
 
 ## Recommended: profiles (`--profile`)
 
-Profiles auto-scope `PIGBOT_STATE_DIR` + `PIGBOT_CONFIG_PATH` and suffix service names.
+Profiles auto-scope `CLAWDBOT_STATE_DIR` + `CLAWDBOT_CONFIG_PATH` and suffix service names.
 
 ```bash
 # main
-pigbot --profile main setup
-pigbot --profile main gateway --port 18789
+moltbot --profile main setup
+moltbot --profile main gateway --port 18789
 
 # rescue
-pigbot --profile rescue setup
-pigbot --profile rescue gateway --port 19001
+moltbot --profile rescue setup
+moltbot --profile rescue gateway --port 19001
 ```
 
 Per-profile services:
 ```bash
-pigbot --profile main gateway install
-pigbot --profile rescue gateway install
+moltbot --profile main gateway install
+moltbot --profile rescue gateway install
 ```
 
 ## Rescue-bot guide
@@ -54,11 +54,11 @@ Port spacing: leave at least 20 ports between base ports so the derived browser/
 ```bash
 # Main bot (existing or fresh, without --profile param)
 # Runs on port 18789 + Chrome CDC/Canvas/... Ports 
-pigbot onboard
-pigbot gateway install
+moltbot onboard
+moltbot gateway install
 
 # Rescue bot (isolated profile + ports)
-pigbot --profile rescue onboard
+moltbot --profile rescue onboard
 # Notes: 
 # - workspace name will be postfixed with -rescue per default
 # - Port should be at least 18789 + 20 Ports, 
@@ -66,14 +66,14 @@ pigbot --profile rescue onboard
 # - rest of the onboarding is the same as normal
 
 # To install the service (if not happened automatically during onboarding)
-pigbot --profile rescue gateway install
+moltbot --profile rescue gateway install
 ```
 
 ## Port mapping (derived)
 
-Base port = `gateway.port` (or `PIGBOT_GATEWAY_PORT` / `--port`).
+Base port = `gateway.port` (or `CLAWDBOT_GATEWAY_PORT` / `--port`).
 
-- `browser.controlUrl port = base + 2`
+- browser control service port = base + 2 (loopback only)
 - `canvasHost.port = base + 4`
 - Browser profile CDP ports auto-allocate from `browser.controlPort + 9 .. + 108`
 
@@ -81,27 +81,27 @@ If you override any of these in config or env, you must keep them unique per ins
 
 ## Browser/CDP notes (common footgun)
 
-- Do **not** pin `browser.controlUrl` or `browser.cdpUrl` to the same values on multiple instances.
-- Each instance needs its own browser control port and CDP range.
+- Do **not** pin `browser.cdpUrl` to the same values on multiple instances.
+- Each instance needs its own browser control port and CDP range (derived from its gateway port).
 - If you need explicit CDP ports, set `browser.profiles.<name>.cdpPort` per instance.
 - Remote Chrome: use `browser.profiles.<name>.cdpUrl` (per profile, per instance).
 
 ## Manual env example
 
 ```bash
-PIGBOT_CONFIG_PATH=~/.pigbot/main.json \
-PIGBOT_STATE_DIR=~/.pigbot-main \
-pigbot gateway --port 18789
+CLAWDBOT_CONFIG_PATH=~/.clawdbot/main.json \
+CLAWDBOT_STATE_DIR=~/.clawdbot-main \
+moltbot gateway --port 18789
 
-PIGBOT_CONFIG_PATH=~/.pigbot/rescue.json \
-PIGBOT_STATE_DIR=~/.pigbot-rescue \
-pigbot gateway --port 19001
+CLAWDBOT_CONFIG_PATH=~/.clawdbot/rescue.json \
+CLAWDBOT_STATE_DIR=~/.clawdbot-rescue \
+moltbot gateway --port 19001
 ```
 
 ## Quick checks
 
 ```bash
-pigbot --profile main status
-pigbot --profile rescue status
-pigbot --profile rescue browser status
+moltbot --profile main status
+moltbot --profile rescue status
+moltbot --profile rescue browser status
 ```

package/docs/gateway/openai-http-api.md

@@ -5,14 +5,14 @@ read_when:
 ---
 # OpenAI Chat Completions (HTTP)
 
-Pigbot’s Gateway can serve a small OpenAI-compatible Chat Completions endpoint.
+Moltbot’s Gateway can serve a small OpenAI-compatible Chat Completions endpoint.
 
 This endpoint is **disabled by default**. Enable it in config first.
 
 - `POST /v1/chat/completions`
 - Same port as the Gateway (WS + HTTP multiplex): `http://<gateway-host>:<port>/v1/chat/completions`
 
-Under the hood, requests are executed as a normal Gateway agent run (same codepath as `pigbot agent`), so routing/permissions/config match your Gateway.
+Under the hood, requests are executed as a normal Gateway agent run (same codepath as `moltbot agent`), so routing/permissions/config match your Gateway.
 
 ## Authentication
 
@@ -21,22 +21,22 @@ Uses the Gateway auth configuration. Send a bearer token:
 - `Authorization: Bearer <token>`
 
 Notes:
-- When `gateway.auth.mode="token"`, use `gateway.auth.token` (or `PIGBOT_GATEWAY_TOKEN`).
-- When `gateway.auth.mode="password"`, use `gateway.auth.password` (or `PIGBOT_GATEWAY_PASSWORD`).
+- When `gateway.auth.mode="token"`, use `gateway.auth.token` (or `CLAWDBOT_GATEWAY_TOKEN`).
+- When `gateway.auth.mode="password"`, use `gateway.auth.password` (or `CLAWDBOT_GATEWAY_PASSWORD`).
 
 ## Choosing an agent
 
 No custom headers required: encode the agent id in the OpenAI `model` field:
 
-- `model: "pigbot:<agentId>"` (example: `"pigbot:main"`, `"pigbot:beta"`)
+- `model: "moltbot:<agentId>"` (example: `"moltbot:main"`, `"moltbot:beta"`)
 - `model: "agent:<agentId>"` (alias)
 
-Or target a specific Pigbot agent by header:
+Or target a specific Moltbot agent by header:
 
-- `x-pigbot-agent-id: <agentId>` (default: `main`)
+- `x-moltbot-agent-id: <agentId>` (default: `main`)
 
 Advanced:
-- `x-pigbot-session-key: <sessionKey>` to fully control session routing.
+- `x-moltbot-session-key: <sessionKey>` to fully control session routing.
 
 ## Enabling the endpoint
 
@@ -91,9 +91,9 @@ Non-streaming:
 curl -sS http://127.0.0.1:18789/v1/chat/completions \
   -H 'Authorization: Bearer YOUR_TOKEN' \
   -H 'Content-Type: application/json' \
-  -H 'x-pigbot-agent-id: main' \
+  -H 'x-moltbot-agent-id: main' \
   -d '{
-    "model": "pigbot",
+    "model": "moltbot",
     "messages": [{"role":"user","content":"hi"}]
   }'
 ```
@@ -103,9 +103,9 @@ Streaming:
 curl -N http://127.0.0.1:18789/v1/chat/completions \
   -H 'Authorization: Bearer YOUR_TOKEN' \
   -H 'Content-Type: application/json' \
-  -H 'x-pigbot-agent-id: main' \
+  -H 'x-moltbot-agent-id: main' \
   -d '{
-    "model": "pigbot",
+    "model": "moltbot",
     "stream": true,
     "messages": [{"role":"user","content":"hi"}]
   }'

package/docs/gateway/openresponses-http-api.md

@@ -6,7 +6,7 @@ read_when:
 ---
 # OpenResponses API (HTTP)
 
-Pigbot’s Gateway can serve an OpenResponses-compatible `POST /v1/responses` endpoint.
+Moltbot’s Gateway can serve an OpenResponses-compatible `POST /v1/responses` endpoint.
 
 This endpoint is **disabled by default**. Enable it in config first.
 
@@ -14,7 +14,7 @@ This endpoint is **disabled by default**. Enable it in config first.
 - Same port as the Gateway (WS + HTTP multiplex): `http://<gateway-host>:<port>/v1/responses`
 
 Under the hood, requests are executed as a normal Gateway agent run (same codepath as
-`pigbot agent`), so routing/permissions/config match your Gateway.
+`moltbot agent`), so routing/permissions/config match your Gateway.
 
 ## Authentication
 
@@ -23,22 +23,22 @@ Uses the Gateway auth configuration. Send a bearer token:
 - `Authorization: Bearer <token>`
 
 Notes:
-- When `gateway.auth.mode="token"`, use `gateway.auth.token` (or `PIGBOT_GATEWAY_TOKEN`).
-- When `gateway.auth.mode="password"`, use `gateway.auth.password` (or `PIGBOT_GATEWAY_PASSWORD`).
+- When `gateway.auth.mode="token"`, use `gateway.auth.token` (or `CLAWDBOT_GATEWAY_TOKEN`).
+- When `gateway.auth.mode="password"`, use `gateway.auth.password` (or `CLAWDBOT_GATEWAY_PASSWORD`).
 
 ## Choosing an agent
 
 No custom headers required: encode the agent id in the OpenResponses `model` field:
 
-- `model: "pigbot:<agentId>"` (example: `"pigbot:main"`, `"pigbot:beta"`)
+- `model: "moltbot:<agentId>"` (example: `"moltbot:main"`, `"moltbot:beta"`)
 - `model: "agent:<agentId>"` (alias)
 
-Or target a specific Pigbot agent by header:
+Or target a specific Moltbot agent by header:
 
-- `x-pigbot-agent-id: <agentId>` (default: `main`)
+- `x-moltbot-agent-id: <agentId>` (default: `main`)
 
 Advanced:
-- `x-pigbot-session-key: <sessionKey>` to fully control session routing.
+- `x-moltbot-session-key: <sessionKey>` to fully control session routing.
 
 ## Enabling the endpoint
 
@@ -277,9 +277,9 @@ Non-streaming:
 curl -sS http://127.0.0.1:18789/v1/responses \
   -H 'Authorization: Bearer YOUR_TOKEN' \
   -H 'Content-Type: application/json' \
-  -H 'x-pigbot-agent-id: main' \
+  -H 'x-moltbot-agent-id: main' \
   -d '{
-    "model": "pigbot",
+    "model": "moltbot",
     "input": "hi"
   }'
 ```
@@ -289,9 +289,9 @@ Streaming:
 curl -N http://127.0.0.1:18789/v1/responses \
   -H 'Authorization: Bearer YOUR_TOKEN' \
   -H 'Content-Type: application/json' \
-  -H 'x-pigbot-agent-id: main' \
+  -H 'x-moltbot-agent-id: main' \
   -d '{
-    "model": "pigbot",
+    "model": "moltbot",
     "stream": true,
     "input": "hi"
   }'

package/docs/gateway/pairing.md

@@ -35,11 +35,11 @@ Pending requests expire automatically after **5 minutes**.
 ## CLI workflow (headless friendly)
 
 ```bash
-pigbot nodes pending
-pigbot nodes approve <requestId>
-pigbot nodes reject <requestId>
-pigbot nodes status
-pigbot nodes rename --node <id|name|ip> --name "Living Room iPad"
+moltbot nodes pending
+moltbot nodes approve <requestId>
+moltbot nodes reject <requestId>
+moltbot nodes status
+moltbot nodes rename --node <id|name|ip> --name "Living Room iPad"
 ```
 
 `nodes status` shows paired/connected nodes and their capabilities.
@@ -74,12 +74,12 @@ If silent approval fails, it falls back to the normal “Approve/Reject” promp
 
 ## Storage (local, private)
 
-Pairing state is stored under the Gateway state directory (default `~/.pigbot`):
+Pairing state is stored under the Gateway state directory (default `~/.clawdbot`):
 
-- `~/.pigbot/nodes/paired.json`
-- `~/.pigbot/nodes/pending.json`
+- `~/.clawdbot/nodes/paired.json`
+- `~/.clawdbot/nodes/pending.json`
 
-If you override `PIGBOT_STATE_DIR`, the `nodes/` folder moves with it.
+If you override `CLAWDBOT_STATE_DIR`, the `nodes/` folder moves with it.
 
 Security notes:
 - Tokens are secrets; treat `paired.json` as sensitive.

package/docs/gateway/protocol.md

@@ -9,7 +9,7 @@ read_when:
 # Gateway protocol (WebSocket)
 
 The Gateway WS protocol is the **single control plane + node transport** for
-Pigbot. All clients (CLI, web UI, macOS app, iOS/Android nodes, headless
+Moltbot. All clients (CLI, web UI, macOS app, iOS/Android nodes, headless
 nodes) connect over WebSocket and declare their **role** + **scope** at
 handshake time.
 
@@ -53,7 +53,7 @@ Client → Gateway:
     "permissions": {},
     "auth": { "token": "…" },
     "locale": "en-US",
-    "userAgent": "pigbot-cli/1.2.3",
+    "userAgent": "moltbot-cli/1.2.3",
     "device": {
       "id": "device_fingerprint",
       "publicKey": "…",
@@ -111,7 +111,7 @@ When a device token is issued, `hello-ok` also includes:
     "permissions": { "camera.capture": true, "screen.record": false },
     "auth": { "token": "…" },
     "locale": "en-US",
-    "userAgent": "pigbot-ios/1.2.3",
+    "userAgent": "moltbot-ios/1.2.3",
     "device": {
       "id": "device_fingerprint",
       "publicKey": "…",
@@ -180,7 +180,7 @@ The Gateway treats these as **claims** and enforces server-side allowlists.
 
 ## Auth
 
-- If `PIGBOT_GATEWAY_TOKEN` (or `--token`) is set, `connect.params.auth.token`
+- If `CLAWDBOT_GATEWAY_TOKEN` (or `--token`) is set, `connect.params.auth.token`
   must match or the socket is closed.
 - After pairing, the Gateway issues a **device token** scoped to the connection
   role + scopes. It is returned in `hello-ok.auth.deviceToken` and should be
@@ -198,7 +198,8 @@ The Gateway treats these as **claims** and enforces server-side allowlists.
 - **Local** connects include loopback and the gateway host’s own tailnet address
   (so same‑host tailnet binds can still auto‑approve).
 - All WS clients must include `device` identity during `connect` (operator + node).
-  Control UI can omit it **only** when `gateway.controlUi.allowInsecureAuth` is enabled.
+  Control UI can omit it **only** when `gateway.controlUi.allowInsecureAuth` is enabled
+  (or `gateway.controlUi.dangerouslyDisableDeviceAuth` for break-glass use).
 - Non-local connections must sign the server-provided `connect.challenge` nonce.
 
 ## TLS + pinning

package/docs/gateway/remote-gateway-readme.md

@@ -1,11 +1,11 @@
 ---
-summary: "SSH tunnel setup for Pigbot.app connecting to a remote gateway"
+summary: "SSH tunnel setup for Moltbot.app connecting to a remote gateway"
 read_when: "Connecting the macOS app to a remote gateway over SSH"
 ---
 
-# Running Pigbot.app with a Remote Gateway
+# Running Moltbot.app with a Remote Gateway
 
-Pigbot.app uses SSH tunneling to connect to a remote gateway. This guide shows you how to set it up.
+Moltbot.app uses SSH tunneling to connect to a remote gateway. This guide shows you how to set it up.
 
 ## Overview
 
@@ -13,7 +13,7 @@ Pigbot.app uses SSH tunneling to connect to a remote gateway. This guide shows y
 ┌─────────────────────────────────────────────────────────────┐
 │                        Client Machine                          │
 │                                                              │
-│  Pigbot.app ──► ws://127.0.0.1:18789 (local port)           │
+│  Moltbot.app ──► ws://127.0.0.1:18789 (local port)           │
 │                     │                                        │
 │                     ▼                                        │
 │  SSH Tunnel ────────────────────────────────────────────────│
@@ -56,7 +56,7 @@ ssh-copy-id -i ~/.ssh/id_rsa <REMOTE_USER>@<REMOTE_IP>
 ### Step 3: Set Gateway Token
 
 ```bash
-launchctl setenv PIGBOT_GATEWAY_TOKEN "<your-token>"
+launchctl setenv CLAWDBOT_GATEWAY_TOKEN "<your-token>"
 ```
 
 ### Step 4: Start SSH Tunnel
@@ -65,11 +65,11 @@ launchctl setenv PIGBOT_GATEWAY_TOKEN "<your-token>"
 ssh -N remote-gateway &
 ```
 
-### Step 5: Restart Pigbot.app
+### Step 5: Restart Moltbot.app
 
 ```bash
-# Quit Pigbot.app (⌘Q), then reopen:
-open /path/to/Pigbot.app
+# Quit Moltbot.app (⌘Q), then reopen:
+open /path/to/Moltbot.app
 ```
 
 The app will now connect to the remote gateway through the SSH tunnel.
@@ -82,7 +82,7 @@ To have the SSH tunnel start automatically when you log in, create a Launch Agen
 
 ### Create the PLIST file
 
-Save this as `~/Library/LaunchAgents/com.pigbot.ssh-tunnel.plist`:
+Save this as `~/Library/LaunchAgents/bot.molt.ssh-tunnel.plist`:
 
 ```xml
 <?xml version="1.0" encoding="UTF-8"?>
@@ -90,7 +90,7 @@ Save this as `~/Library/LaunchAgents/com.pigbot.ssh-tunnel.plist`:
 <plist version="1.0">
 <dict>
     <key>Label</key>
-    <string>com.pigbot.ssh-tunnel</string>
+    <string>bot.molt.ssh-tunnel</string>
     <key>ProgramArguments</key>
     <array>
         <string>/usr/bin/ssh</string>
@@ -108,7 +108,7 @@ Save this as `~/Library/LaunchAgents/com.pigbot.ssh-tunnel.plist`:
 ### Load the Launch Agent
 
 ```bash
-launchctl bootstrap gui/$UID ~/Library/LaunchAgents/com.pigbot.ssh-tunnel.plist
+launchctl bootstrap gui/$UID ~/Library/LaunchAgents/bot.molt.ssh-tunnel.plist
 ```
 
 The tunnel will now:
@@ -116,6 +116,8 @@ The tunnel will now:
 - Restart if it crashes
 - Keep running in the background
 
+Legacy note: remove any leftover `com.clawdbot.ssh-tunnel` LaunchAgent if present.
+
 ---
 
 ## Troubleshooting
@@ -130,13 +132,13 @@ lsof -i :18789
 **Restart the tunnel:**
 
 ```bash
-launchctl kickstart -k gui/$UID/com.pigbot.ssh-tunnel
+launchctl kickstart -k gui/$UID/bot.molt.ssh-tunnel
 ```
 
 **Stop the tunnel:**
 
 ```bash
-launchctl bootout gui/$UID/com.pigbot.ssh-tunnel
+launchctl bootout gui/$UID/bot.molt.ssh-tunnel
 ```
 
 ---
@@ -150,4 +152,4 @@ launchctl bootout gui/$UID/com.pigbot.ssh-tunnel
 | `KeepAlive` | Automatically restarts tunnel if it crashes |
 | `RunAtLoad` | Starts tunnel when the agent loads |
 
-Pigbot.app connects to `ws://127.0.0.1:18789` on your client machine. The SSH tunnel forwards that connection to port 18789 on the remote machine where the Gateway is running.
+Moltbot.app connects to `ws://127.0.0.1:18789` on your client machine. The SSH tunnel forwards that connection to port 18789 on the remote machine where the Gateway is running.

package/docs/gateway/remote.md

@@ -34,7 +34,7 @@ This is ideal when your laptop sleeps often but you want the agent always-on.
 
 The laptop does **not** run the agent. It connects remotely:
 
-- Use the macOS app’s **Remote over SSH** mode (Settings → General → “Pigbot runs”).
+- Use the macOS app’s **Remote over SSH** mode (Settings → General → “Moltbot runs”).
 - The app opens and manages the tunnel, so WebChat + health checks “just work.”
 
 Runbook: [macOS remote access](/platforms/mac/remote).
@@ -71,10 +71,10 @@ ssh -N -L 18789:127.0.0.1:18789 user@host
 ```
 
 With the tunnel up:
-- `pigbot health` and `pigbot status --deep` now reach the remote gateway via `ws://127.0.0.1:18789`.
-- `pigbot gateway {status,health,send,agent,call}` can also target the forwarded URL via `--url` when needed.
+- `moltbot health` and `moltbot status --deep` now reach the remote gateway via `ws://127.0.0.1:18789`.
+- `moltbot gateway {status,health,send,agent,call}` can also target the forwarded URL via `--url` when needed.
 
-Note: replace `18789` with your configured `gateway.port` (or `--port`/`PIGBOT_GATEWAY_PORT`).
+Note: replace `18789` with your configured `gateway.port` (or `--port`/`CLAWDBOT_GATEWAY_PORT`).
 
 ## CLI remote defaults
 
@@ -117,6 +117,6 @@ Short version: **keep the Gateway loopback-only** unless you’re sure you need
 - `gateway.remote.tlsFingerprint` pins the remote TLS cert when using `wss://`.
 - **Tailscale Serve** can authenticate via identity headers when `gateway.auth.allowTailscale: true`.
   Set it to `false` if you want tokens/passwords instead.
-- Treat `browser.controlUrl` like an admin API: tailnet-only + token auth.
+- Treat browser control like operator access: tailnet-only + deliberate node pairing.
 
 Deep dive: [Security](/gateway/security).

package/docs/gateway/sandbox-vs-tool-policy-vs-elevated.md

@@ -7,7 +7,7 @@ status: active
 
 # Sandbox vs Tool Policy vs Elevated
 
-Pigbot has three related (but different) controls:
+Moltbot has three related (but different) controls:
 
 1. **Sandbox** (`agents.defaults.sandbox.*` / `agents.list[].sandbox.*`) decides **where tools run** (Docker vs host).
 2. **Tool policy** (`tools.*`, `tools.sandbox.tools.*`, `agents.list[].tools.*`) decides **which tools are available/allowed**.
@@ -15,13 +15,13 @@ Pigbot has three related (but different) controls:
 
 ## Quick debug
 
-Use the inspector to see what Pigbot is *actually* doing:
+Use the inspector to see what Moltbot is *actually* doing:
 
 ```bash
-pigbot sandbox explain
-pigbot sandbox explain --session agent:main:main
-pigbot sandbox explain --agent work
-pigbot sandbox explain --json
+moltbot sandbox explain
+moltbot sandbox explain --session agent:main:main
+moltbot sandbox explain --agent work
+moltbot sandbox explain --json
 ```
 
 It prints:
@@ -59,6 +59,8 @@ Two layers matter:
 Rules of thumb:
 - `deny` always wins.
 - If `allow` is non-empty, everything else is treated as blocked.
+- Tool policy is the hard stop: `/exec` cannot override a denied `exec` tool.
+- `/exec` only changes session defaults for authorized senders; it does not grant tool access.
 Provider tool keys accept either `provider` (e.g. `google-antigravity`) or `provider/model` (e.g. `openai/gpt-5.2`).
 
 ### Tool groups (shorthands)
@@ -86,7 +88,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)
 
 ## Elevated: exec-only “run on host”
 
@@ -95,6 +97,7 @@ Elevated does **not** grant extra tools; it only affects `exec`.
 - Use `/elevated full` to skip exec approvals for the session.
 - If you’re already running direct, elevated is effectively a no-op (still gated).
 - Elevated is **not** skill-scoped and does **not** override tool allow/deny.
+- `/exec` is separate from elevated. It only adjusts per-session exec defaults for authorized senders.
 
 Gates:
 - Enablement: `tools.elevated.enabled` (and optionally `agents.list[].tools.elevated.enabled`)

package/docs/gateway/sandboxing.md

@@ -1,5 +1,5 @@
 ---
-summary: "How Pigbot sandboxing works: modes, scopes, workspace access, and images"
+summary: "How Moltbot sandboxing works: modes, scopes, workspace access, and images"
 title: Sandboxing
 read_when: "You want a dedicated explanation of sandboxing or need to tune agents.defaults.sandbox."
 status: active
@@ -7,7 +7,7 @@ status: active
 
 # Sandboxing
 
-Pigbot can run **tools inside Docker containers** to reduce blast radius.
+Moltbot can run **tools inside Docker containers** to reduce blast radius.
 This is **optional** and controlled by configuration (`agents.defaults.sandbox` or
 `agents.list[].sandbox`). If sandboxing is off, tools run on the host.
 The Gateway stays on the host; tool execution runs in an isolated sandbox
@@ -46,13 +46,13 @@ Group/channel sessions use their own keys, so they count as non-main and will be
 
 ## Workspace access
 `agents.defaults.sandbox.workspaceAccess` controls **what the sandbox can see**:
-- `"none"` (default): tools see a sandbox workspace under `~/.pigbot/sandboxes`.
+- `"none"` (default): tools see a sandbox workspace under `~/.clawdbot/sandboxes`.
 - `"ro"`: mounts the agent workspace read-only at `/agent` (disables `write`/`edit`/`apply_patch`).
 - `"rw"`: mounts the agent workspace read/write at `/workspace`.
 
 Inbound media is copied into the active sandbox workspace (`media/inbound/*`).
 Skills note: the `read` tool is sandbox-rooted. With `workspaceAccess: "none"`,
-Pigbot mirrors eligible skills into the sandbox workspace (`.../skills`) so
+Moltbot mirrors eligible skills into the sandbox workspace (`.../skills`) so
 they can be read. With `"rw"`, workspace skills are readable from
 `/workspace/skills`.
 
@@ -98,7 +98,7 @@ Security notes:
 - See [Sandbox vs Tool Policy vs Elevated](/gateway/sandbox-vs-tool-policy-vs-elevated) for how binds interact with tool policy and elevated exec.
 
 ## Images + setup
-Default image: `pigbot-sandbox:bookworm-slim`
+Default image: `moltbot-sandbox:bookworm-slim`
 
 Build it once:
 ```bash
@@ -142,9 +142,11 @@ Tool allow/deny policies still apply before sandbox rules. If a tool is denied
 globally or per-agent, sandboxing doesn’t bring it back.
 
 `tools.elevated` is an explicit escape hatch that runs `exec` on the host.
+`/exec` directives only apply for authorized senders and persist per session; to hard-disable
+`exec`, use tool policy deny (see [Sandbox vs Tool Policy vs Elevated](/gateway/sandbox-vs-tool-policy-vs-elevated)).
 
 Debugging:
-- Use `pigbot sandbox explain` to inspect effective sandbox mode, tool policy, and fix-it config keys.
+- Use `moltbot sandbox explain` to inspect effective sandbox mode, tool policy, and fix-it config keys.
 - See [Sandbox vs Tool Policy vs Elevated](/gateway/sandbox-vs-tool-policy-vs-elevated) for the “why is this blocked?” mental model.
 Keep it locked down.