Merge branch 'main' into nanogpt
This commit is contained in:
86 files changed
+7519
-248
No files matched your search
@@ -201,7 +201,7 @@ For ad-hoc workflows, call Lobster directly.
|
||||
|
||||
- Lobster runs as a **local subprocess** (`lobster` CLI) in tool mode and returns a **JSON envelope**.
|
||||
- If the tool returns `needs_approval`, you resume with a `resumeToken` and `approve` flag.
|
||||
- The tool is an **optional plugin**; you must allowlist `lobster` in `tools.allow`.
|
||||
- The tool is an **optional plugin**; enable it additively via `tools.alsoAllow: ["lobster"]` (recommended).
|
||||
- If you pass `lobsterPath`, it must be an **absolute path**.
|
||||
|
||||
See [Lobster](/tools/lobster) for full usage and examples.
|
||||
|
||||
@@ -10,13 +10,14 @@ Status: ready for DM and guild text channels via the official Discord bot gatewa
|
||||
|
||||
## Quick setup (beginner)
|
||||
1) Create a Discord bot and copy the bot token.
|
||||
2) Set the token for Clawdbot:
|
||||
2) In the Discord app settings, enable **Message Content Intent** (and **Server Members Intent** if you plan to use allowlists or name lookups).
|
||||
3) Set the token for Clawdbot:
|
||||
- Env: `DISCORD_BOT_TOKEN=...`
|
||||
- Or config: `channels.discord.token: "..."`.
|
||||
- If both are set, config takes precedence (env fallback is default-account only).
|
||||
3) Invite the bot to your server with message permissions.
|
||||
4) Start the gateway.
|
||||
5) DM access is pairing by default; approve the pairing code on first contact.
|
||||
4) Invite the bot to your server with message permissions (create a private server if you just want DMs).
|
||||
5) Start the gateway.
|
||||
6) DM access is pairing by default; approve the pairing code on first contact.
|
||||
|
||||
Minimal config:
|
||||
```json5
|
||||
|
||||
@@ -26,6 +26,7 @@ Text is supported everywhere; media and reactions vary by channel.
|
||||
- [Matrix](/channels/matrix) — Matrix protocol (plugin, installed separately).
|
||||
- [Nostr](/channels/nostr) — Decentralized DMs via NIP-04 (plugin, installed separately).
|
||||
- [Tlon](/channels/tlon) — Urbit-based messenger (plugin, installed separately).
|
||||
- [Twitch](/channels/twitch) — Twitch chat via IRC connection (plugin, installed separately).
|
||||
- [Zalo](/channels/zalo) — Zalo Bot API; Vietnam's popular messenger (plugin, installed separately).
|
||||
- [Zalo Personal](/channels/zalouser) — Zalo personal account via QR login (plugin, installed separately).
|
||||
- [WebChat](/web/webchat) — Gateway WebChat UI over WebSocket.
|
||||
|
||||
@@ -0,0 +1,366 @@
|
||||
---
|
||||
summary: "Twitch chat bot configuration and setup"
|
||||
read_when:
|
||||
- Setting up Twitch chat integration for Clawdbot
|
||||
---
|
||||
# Twitch (plugin)
|
||||
|
||||
Twitch chat support via IRC connection. Clawdbot connects as a Twitch user (bot account) to receive and send messages in channels.
|
||||
|
||||
## Plugin required
|
||||
|
||||
Twitch ships as a plugin and is not bundled with the core install.
|
||||
|
||||
Install via CLI (npm registry):
|
||||
|
||||
```bash
|
||||
clawdbot plugins install @clawdbot/twitch
|
||||
```
|
||||
|
||||
Local checkout (when running from a git repo):
|
||||
|
||||
```bash
|
||||
clawdbot plugins install ./extensions/twitch
|
||||
```
|
||||
|
||||
Details: [Plugins](/plugin)
|
||||
|
||||
## Quick setup (beginner)
|
||||
|
||||
1) Create a dedicated Twitch account for the bot (or use an existing account).
|
||||
2) Generate credentials: [Twitch Token Generator](https://twitchtokengenerator.com/)
|
||||
- Select **Bot Token**
|
||||
- Verify scopes `chat:read` and `chat:write` are selected
|
||||
- Copy the **Client ID** and **Access Token**
|
||||
3) Find your Twitch user ID: https://www.streamweasels.com/tools/convert-twitch-username-to-user-id/
|
||||
4) Configure the token:
|
||||
- Env: `CLAWDBOT_TWITCH_ACCESS_TOKEN=...` (default account only)
|
||||
- Or config: `channels.twitch.accessToken`
|
||||
- If both are set, config takes precedence (env fallback is default-account only).
|
||||
5) Start the gateway.
|
||||
|
||||
**⚠️ Important:** Add access control (`allowFrom` or `allowedRoles`) to prevent unauthorized users from triggering the bot. `requireMention` defaults to `true`.
|
||||
|
||||
Minimal config:
|
||||
|
||||
```json5
|
||||
{
|
||||
channels: {
|
||||
twitch: {
|
||||
enabled: true,
|
||||
username: "clawdbot", // Bot's Twitch account
|
||||
accessToken: "oauth:abc123...", // OAuth Access Token (or use CLAWDBOT_TWITCH_ACCESS_TOKEN env var)
|
||||
clientId: "xyz789...", // Client ID from Token Generator
|
||||
channel: "vevisk", // Which Twitch channel's chat to join (required)
|
||||
allowFrom: ["123456789"] // (recommended) Your Twitch user ID only - get it from https://www.streamweasels.com/tools/convert-twitch-username-to-user-id/
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## What it is
|
||||
|
||||
- A Twitch channel owned by the Gateway.
|
||||
- Deterministic routing: replies always go back to Twitch.
|
||||
- Each account maps to an isolated session key `agent:<agentId>:twitch:<accountName>`.
|
||||
- `username` is the bot's account (who authenticates), `channel` is which chat room to join.
|
||||
|
||||
## Setup (detailed)
|
||||
|
||||
### Generate credentials
|
||||
|
||||
Use [Twitch Token Generator](https://twitchtokengenerator.com/):
|
||||
- Select **Bot Token**
|
||||
- Verify scopes `chat:read` and `chat:write` are selected
|
||||
- Copy the **Client ID** and **Access Token**
|
||||
|
||||
No manual app registration needed. Tokens expire after several hours.
|
||||
|
||||
### Configure the bot
|
||||
|
||||
**Env var (default account only):**
|
||||
```bash
|
||||
CLAWDBOT_TWITCH_ACCESS_TOKEN=oauth:abc123...
|
||||
```
|
||||
|
||||
**Or config:**
|
||||
```json5
|
||||
{
|
||||
channels: {
|
||||
twitch: {
|
||||
enabled: true,
|
||||
username: "clawdbot",
|
||||
accessToken: "oauth:abc123...",
|
||||
clientId: "xyz789...",
|
||||
channel: "vevisk"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
If both env and config are set, config takes precedence.
|
||||
|
||||
### Access control (recommended)
|
||||
|
||||
```json5
|
||||
{
|
||||
channels: {
|
||||
twitch: {
|
||||
allowFrom: ["123456789"], // (recommended) Your Twitch user ID only
|
||||
allowedRoles: ["moderator"] // Or restrict to roles
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Available roles:** `"moderator"`, `"owner"`, `"vip"`, `"subscriber"`, `"all"`.
|
||||
|
||||
**Why user IDs?** Usernames can change, allowing impersonation. User IDs are permanent.
|
||||
|
||||
Find your Twitch user ID: https://www.streamweasels.com/tools/convert-twitch-username-%20to-user-id/ (Convert your Twitch username to ID)
|
||||
|
||||
## Token refresh (optional)
|
||||
|
||||
Tokens from [Twitch Token Generator](https://twitchtokengenerator.com/) cannot be automatically refreshed - regenerate when expired.
|
||||
|
||||
For automatic token refresh, create your own Twitch application at [Twitch Developer Console](https://dev.twitch.tv/console) and add to config:
|
||||
|
||||
```json5
|
||||
{
|
||||
channels: {
|
||||
twitch: {
|
||||
clientSecret: "your_client_secret",
|
||||
refreshToken: "your_refresh_token"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The bot automatically refreshes tokens before expiration and logs refresh events.
|
||||
|
||||
## Multi-account support
|
||||
|
||||
Use `channels.twitch.accounts` with per-account tokens. See [`gateway/configuration`](/gateway/configuration) for the shared pattern.
|
||||
|
||||
Example (one bot account in two channels):
|
||||
|
||||
```json5
|
||||
{
|
||||
channels: {
|
||||
twitch: {
|
||||
accounts: {
|
||||
channel1: {
|
||||
username: "clawdbot",
|
||||
accessToken: "oauth:abc123...",
|
||||
clientId: "xyz789...",
|
||||
channel: "vevisk"
|
||||
},
|
||||
channel2: {
|
||||
username: "clawdbot",
|
||||
accessToken: "oauth:def456...",
|
||||
clientId: "uvw012...",
|
||||
channel: "secondchannel"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Note:** Each account needs its own token (one token per channel).
|
||||
|
||||
## Access control
|
||||
|
||||
### Role-based restrictions
|
||||
|
||||
```json5
|
||||
{
|
||||
channels: {
|
||||
twitch: {
|
||||
accounts: {
|
||||
default: {
|
||||
allowedRoles: ["moderator", "vip"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Allowlist by User ID (most secure)
|
||||
|
||||
```json5
|
||||
{
|
||||
channels: {
|
||||
twitch: {
|
||||
accounts: {
|
||||
default: {
|
||||
allowFrom: ["123456789", "987654321"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Combined allowlist + roles
|
||||
|
||||
Users in `allowFrom` bypass role checks:
|
||||
|
||||
```json5
|
||||
{
|
||||
channels: {
|
||||
twitch: {
|
||||
accounts: {
|
||||
default: {
|
||||
allowFrom: ["123456789"],
|
||||
allowedRoles: ["moderator"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Disable @mention requirement
|
||||
|
||||
By default, `requireMention` is `true`. To disable and respond to all messages:
|
||||
|
||||
```json5
|
||||
{
|
||||
channels: {
|
||||
twitch: {
|
||||
accounts: {
|
||||
default: {
|
||||
requireMention: false
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
First, run diagnostic commands:
|
||||
|
||||
```bash
|
||||
clawdbot doctor
|
||||
clawdbot channels status --probe
|
||||
```
|
||||
|
||||
### Bot doesn't respond to messages
|
||||
|
||||
**Check access control:** Temporarily set `allowedRoles: ["all"]` to test.
|
||||
|
||||
**Check the bot is in the channel:** The bot must join the channel specified in `channel`.
|
||||
|
||||
### Token issues
|
||||
|
||||
**"Failed to connect" or authentication errors:**
|
||||
- Verify `accessToken` is the OAuth access token value (typically starts with `oauth:` prefix)
|
||||
- Check token has `chat:read` and `chat:write` scopes
|
||||
- If using token refresh, verify `clientSecret` and `refreshToken` are set
|
||||
|
||||
### Token refresh not working
|
||||
|
||||
**Check logs for refresh events:**
|
||||
```
|
||||
Using env token source for mybot
|
||||
Access token refreshed for user 123456 (expires in 14400s)
|
||||
```
|
||||
|
||||
If you see "token refresh disabled (no refresh token)":
|
||||
- Ensure `clientSecret` is provided
|
||||
- Ensure `refreshToken` is provided
|
||||
|
||||
## Config
|
||||
|
||||
**Account config:**
|
||||
- `username` - Bot username
|
||||
- `accessToken` - OAuth access token with `chat:read` and `chat:write`
|
||||
- `clientId` - Twitch Client ID (from Token Generator or your app)
|
||||
- `channel` - Channel to join (required)
|
||||
- `enabled` - Enable this account (default: `true`)
|
||||
- `clientSecret` - Optional: For automatic token refresh
|
||||
- `refreshToken` - Optional: For automatic token refresh
|
||||
- `expiresIn` - Token expiry in seconds
|
||||
- `obtainmentTimestamp` - Token obtained timestamp
|
||||
- `allowFrom` - User ID allowlist
|
||||
- `allowedRoles` - Role-based access control (`"moderator" | "owner" | "vip" | "subscriber" | "all"`)
|
||||
- `requireMention` - Require @mention (default: `true`)
|
||||
|
||||
**Provider options:**
|
||||
- `channels.twitch.enabled` - Enable/disable channel startup
|
||||
- `channels.twitch.username` - Bot username (simplified single-account config)
|
||||
- `channels.twitch.accessToken` - OAuth access token (simplified single-account config)
|
||||
- `channels.twitch.clientId` - Twitch Client ID (simplified single-account config)
|
||||
- `channels.twitch.channel` - Channel to join (simplified single-account config)
|
||||
- `channels.twitch.accounts.<accountName>` - Multi-account config (all account fields above)
|
||||
|
||||
Full example:
|
||||
|
||||
```json5
|
||||
{
|
||||
channels: {
|
||||
twitch: {
|
||||
enabled: true,
|
||||
username: "clawdbot",
|
||||
accessToken: "oauth:abc123...",
|
||||
clientId: "xyz789...",
|
||||
channel: "vevisk",
|
||||
clientSecret: "secret123...",
|
||||
refreshToken: "refresh456...",
|
||||
allowFrom: ["123456789"],
|
||||
allowedRoles: ["moderator", "vip"],
|
||||
accounts: {
|
||||
default: {
|
||||
username: "mybot",
|
||||
accessToken: "oauth:abc123...",
|
||||
clientId: "xyz789...",
|
||||
channel: "your_channel",
|
||||
enabled: true,
|
||||
clientSecret: "secret123...",
|
||||
refreshToken: "refresh456...",
|
||||
expiresIn: 14400,
|
||||
obtainmentTimestamp: 1706092800000,
|
||||
allowFrom: ["123456789", "987654321"],
|
||||
allowedRoles: ["moderator"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Tool actions
|
||||
|
||||
The agent can call `twitch` with action:
|
||||
- `send` - Send a message to a channel
|
||||
|
||||
Example:
|
||||
|
||||
```json5
|
||||
{
|
||||
"action": "twitch",
|
||||
"params": {
|
||||
"message": "Hello Twitch!",
|
||||
"to": "#mychannel"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Safety & ops
|
||||
|
||||
- **Treat tokens like passwords** - Never commit tokens to git
|
||||
- **Use automatic token refresh** for long-running bots
|
||||
- **Use user ID allowlists** instead of usernames for access control
|
||||
- **Monitor logs** for token refresh events and connection status
|
||||
- **Scope tokens minimally** - Only request `chat:read` and `chat:write`
|
||||
- **If stuck**: Restart the gateway after confirming no other process owns the session
|
||||
|
||||
## Limits
|
||||
|
||||
- **500 characters** per message (auto-chunked at word boundaries)
|
||||
- Markdown is stripped before chunking
|
||||
- No rate limiting (uses Twitch's built-in rate limits)
|
||||
@@ -23,3 +23,4 @@ clawdbot onboard --mode remote --remote-url ws://gateway-host:18789
|
||||
Flow notes:
|
||||
- `quickstart`: minimal prompts, auto-generates a gateway token.
|
||||
- `manual`: full prompts for port/bind/auth (alias of `advanced`).
|
||||
- Fastest first chat: `clawdbot dashboard` (Control UI, no channel setup).
|
||||
@@ -43,6 +43,18 @@ Start with the smallest access that still works, then widen it as you gain confi
|
||||
|
||||
If you run `--deep`, Clawdbot also attempts a best-effort live Gateway probe.
|
||||
|
||||
## Credential storage map
|
||||
|
||||
Use this when auditing access or deciding what to back up:
|
||||
|
||||
- **WhatsApp**: `~/.clawdbot/credentials/whatsapp/<accountId>/creds.json`
|
||||
- **Telegram bot token**: config/env or `channels.telegram.tokenFile`
|
||||
- **Discord bot token**: config/env (token file not yet supported)
|
||||
- **Slack tokens**: config/env (`channels.slack.*`)
|
||||
- **Pairing allowlists**: `~/.clawdbot/credentials/<channel>-allowFrom.json`
|
||||
- **Model auth profiles**: `~/.clawdbot/agents/<agentId>/agent/auth-profiles.json`
|
||||
- **Legacy OAuth import**: `~/.clawdbot/credentials/oauth.json`
|
||||
|
||||
## Security Audit Checklist
|
||||
|
||||
When the audit prints findings, treat this as a priority order:
|
||||
@@ -199,6 +211,7 @@ Even with strong system prompts, **prompt injection is not solved**. What helps
|
||||
- Prefer mention gating in groups; avoid “always-on” bots in public rooms.
|
||||
- Treat links, attachments, and pasted instructions as hostile by default.
|
||||
- Run sensitive tool execution in a sandbox; keep secrets out of the agent’s reachable filesystem.
|
||||
- Note: sandboxing is opt-in. If sandbox mode is off, exec runs on the gateway host even though tools.exec.host defaults to sandbox, and host exec does not require approvals unless you set host=gateway and configure exec approvals.
|
||||
- Limit high-risk tools (`exec`, `browser`, `web_fetch`, `web_search`) to trusted agents or explicit allowlists.
|
||||
- **Model choice matters:** older/legacy models can be less robust against prompt injection and tool misuse. Prefer modern, instruction-hardened models for any bot with tools. We recommend Anthropic Opus 4.5 because it’s quite good at recognizing prompt injections (see [“A step forward on safety”](https://www.anthropic.com/news/claude-opus-4-5)).
|
||||
|
||||
|
||||
+1
-1
@@ -401,7 +401,7 @@ remote mode, remember the gateway host owns the session store and workspace.
|
||||
up **memory + bootstrap files**, but **not** session history or auth. Those live
|
||||
under `~/.clawdbot/` (for example `~/.clawdbot/agents/<agentId>/sessions/`).
|
||||
|
||||
Related: [Where things live on disk](/help/faq#where-does-clawdbot-store-its-data),
|
||||
Related: [Migrating](/install/migrating), [Where things live on disk](/help/faq#where-does-clawdbot-store-its-data),
|
||||
[Agent workspace](/concepts/agent-workspace), [Doctor](/gateway/doctor),
|
||||
[Remote mode](/gateway/remote).
|
||||
|
||||
|
||||
@@ -177,4 +177,5 @@ Then open a new terminal (or `rehash` in zsh / `hash -r` in bash).
|
||||
## Update / uninstall
|
||||
|
||||
- Updates: [Updating](/install/updating)
|
||||
- Migrate to a new machine: [Migrating](/install/migrating)
|
||||
- Uninstall: [Uninstall](/install/uninstall)
|
||||
@@ -0,0 +1,190 @@
|
||||
---
|
||||
summary: "Move (migrate) a Clawdbot install from one machine to another"
|
||||
read_when:
|
||||
- You are moving Clawdbot to a new laptop/server
|
||||
- You want to preserve sessions, auth, and channel logins (WhatsApp, etc.)
|
||||
---
|
||||
# Migrating Clawdbot to a new machine
|
||||
|
||||
This guide migrates a Clawdbot Gateway from one machine to another **without redoing onboarding**.
|
||||
|
||||
The migration is simple conceptually:
|
||||
|
||||
- Copy the **state directory** (`$CLAWDBOT_STATE_DIR`, default: `~/.clawdbot/`) — this includes config, auth, sessions, and channel state.
|
||||
- Copy your **workspace** (`~/clawd/` by default) — this includes your agent files (memory, prompts, etc.).
|
||||
|
||||
But there are common footguns around **profiles**, **permissions**, and **partial copies**.
|
||||
|
||||
## Before you start (what you are migrating)
|
||||
|
||||
### 1) Identify your state directory
|
||||
|
||||
Most installs use the default:
|
||||
|
||||
- **State dir:** `~/.clawdbot/`
|
||||
|
||||
But it may be different if you use:
|
||||
|
||||
- `--profile <name>` (often becomes `~/.clawdbot-<profile>/`)
|
||||
- `CLAWDBOT_STATE_DIR=/some/path`
|
||||
|
||||
If you’re not sure, run on the **old** machine:
|
||||
|
||||
```bash
|
||||
clawdbot status
|
||||
```
|
||||
|
||||
Look for mentions of `CLAWDBOT_STATE_DIR` / profile in the output. If you run multiple gateways, repeat for each profile.
|
||||
|
||||
### 2) Identify your workspace
|
||||
|
||||
Common defaults:
|
||||
|
||||
- `~/clawd/` (recommended workspace)
|
||||
- a custom folder you created
|
||||
|
||||
Your workspace is where files like `MEMORY.md`, `USER.md`, and `memory/*.md` live.
|
||||
|
||||
### 3) Understand what you will preserve
|
||||
|
||||
If you copy **both** the state dir and workspace, you keep:
|
||||
|
||||
- Gateway configuration (`clawdbot.json`)
|
||||
- Auth profiles / API keys / OAuth tokens
|
||||
- Session history + agent state
|
||||
- Channel state (e.g. WhatsApp login/session)
|
||||
- Your workspace files (memory, skills notes, etc.)
|
||||
|
||||
If you copy **only** the workspace (e.g., via Git), you do **not** preserve:
|
||||
|
||||
- sessions
|
||||
- credentials
|
||||
- channel logins
|
||||
|
||||
Those live under `$CLAWDBOT_STATE_DIR`.
|
||||
|
||||
## Migration steps (recommended)
|
||||
|
||||
### Step 0 — Make a backup (old machine)
|
||||
|
||||
On the **old** machine, stop the gateway first so files aren’t changing mid-copy:
|
||||
|
||||
```bash
|
||||
clawdbot gateway stop
|
||||
```
|
||||
|
||||
(Optional but recommended) archive the state dir and workspace:
|
||||
|
||||
```bash
|
||||
# Adjust paths if you use a profile or custom locations
|
||||
cd ~
|
||||
tar -czf clawdbot-state.tgz .clawdbot
|
||||
|
||||
tar -czf clawd-workspace.tgz clawd
|
||||
```
|
||||
|
||||
If you have multiple profiles/state dirs (e.g. `~/.clawdbot-main`, `~/.clawdbot-work`), archive each.
|
||||
|
||||
### Step 1 — Install Clawdbot on the new machine
|
||||
|
||||
On the **new** machine, install the CLI (and Node if needed):
|
||||
|
||||
- See: [Install](/install)
|
||||
|
||||
At this stage, it’s OK if onboarding creates a fresh `~/.clawdbot/` — you will overwrite it in the next step.
|
||||
|
||||
### Step 2 — Copy the state dir + workspace to the new machine
|
||||
|
||||
Copy **both**:
|
||||
|
||||
- `$CLAWDBOT_STATE_DIR` (default `~/.clawdbot/`)
|
||||
- your workspace (default `~/clawd/`)
|
||||
|
||||
Common approaches:
|
||||
|
||||
- `scp` the tarballs and extract
|
||||
- `rsync -a` over SSH
|
||||
- external drive
|
||||
|
||||
After copying, ensure:
|
||||
|
||||
- Hidden directories were included (e.g. `.clawdbot/`)
|
||||
- File ownership is correct for the user running the gateway
|
||||
|
||||
### Step 3 — Run Doctor (migrations + service repair)
|
||||
|
||||
On the **new** machine:
|
||||
|
||||
```bash
|
||||
clawdbot doctor
|
||||
```
|
||||
|
||||
Doctor is the “safe boring” command. It repairs services, applies config migrations, and warns about mismatches.
|
||||
|
||||
Then:
|
||||
|
||||
```bash
|
||||
clawdbot gateway restart
|
||||
clawdbot status
|
||||
```
|
||||
|
||||
## Common footguns (and how to avoid them)
|
||||
|
||||
### Footgun: profile / state-dir mismatch
|
||||
|
||||
If you ran the old gateway with a profile (or `CLAWDBOT_STATE_DIR`), and the new gateway uses a different one, you’ll see symptoms like:
|
||||
|
||||
- config changes not taking effect
|
||||
- channels missing / logged out
|
||||
- empty session history
|
||||
|
||||
Fix: run the gateway/service using the **same** profile/state dir you migrated, then rerun:
|
||||
|
||||
```bash
|
||||
clawdbot doctor
|
||||
```
|
||||
|
||||
### Footgun: copying only `clawdbot.json`
|
||||
|
||||
`clawdbot.json` is not enough. Many providers store state under:
|
||||
|
||||
- `$CLAWDBOT_STATE_DIR/credentials/`
|
||||
- `$CLAWDBOT_STATE_DIR/agents/<agentId>/...`
|
||||
|
||||
Always migrate the entire `$CLAWDBOT_STATE_DIR` folder.
|
||||
|
||||
### Footgun: permissions / ownership
|
||||
|
||||
If you copied as root or changed users, the gateway may fail to read credentials/sessions.
|
||||
|
||||
Fix: ensure the state dir + workspace are owned by the user running the gateway.
|
||||
|
||||
### Footgun: migrating between remote/local modes
|
||||
|
||||
- If your UI (WebUI/TUI) points at a **remote** gateway, the remote host owns the session store + workspace.
|
||||
- Migrating your laptop won’t move the remote gateway’s state.
|
||||
|
||||
If you’re in remote mode, migrate the **gateway host**.
|
||||
|
||||
### Footgun: secrets in backups
|
||||
|
||||
`$CLAWDBOT_STATE_DIR` contains secrets (API keys, OAuth tokens, WhatsApp creds). Treat backups like production secrets:
|
||||
|
||||
- store encrypted
|
||||
- avoid sharing over insecure channels
|
||||
- rotate keys if you suspect exposure
|
||||
|
||||
## Verification checklist
|
||||
|
||||
On the new machine, confirm:
|
||||
|
||||
- `clawdbot status` shows the gateway running
|
||||
- Your channels are still connected (e.g. WhatsApp doesn’t require re-pair)
|
||||
- The dashboard opens and shows existing sessions
|
||||
- Your workspace files (memory, configs) are present
|
||||
|
||||
## Related
|
||||
|
||||
- [Doctor](/gateway/doctor)
|
||||
- [Gateway troubleshooting](/gateway/troubleshooting)
|
||||
- [Where does Clawdbot store its data?](/help/faq#where-does-clawdbot-store-its-data)
|
||||
@@ -9,6 +9,10 @@ read_when:
|
||||
|
||||
Goal: go from **zero** → **first working chat** (with sane defaults) as quickly as possible.
|
||||
|
||||
Fastest chat: open the Control UI (no channel setup needed). Run `clawdbot dashboard`
|
||||
and chat in the browser, or open `http://127.0.0.1:18789/` on the gateway host.
|
||||
Docs: [Dashboard](/web/dashboard) and [Control UI](/web/control-ui).
|
||||
|
||||
Recommended path: use the **CLI onboarding wizard** (`clawdbot onboard`). It sets up:
|
||||
- model/auth (OAuth recommended)
|
||||
- gateway settings
|
||||
@@ -121,6 +125,7 @@ channels. If you use WhatsApp or Telegram, run the Gateway with **Node**.
|
||||
```bash
|
||||
clawdbot status
|
||||
clawdbot health
|
||||
clawdbot security audit --deep
|
||||
```
|
||||
|
||||
## 4) Pair + connect your first chat surface
|
||||
|
||||
@@ -104,6 +104,19 @@ clawdbot health
|
||||
- Sessions: `~/.clawdbot/agents/<agentId>/sessions/`
|
||||
- Logs: `/tmp/clawdbot/`
|
||||
|
||||
## Credential storage map
|
||||
|
||||
Use this when debugging auth or deciding what to back up:
|
||||
|
||||
- **WhatsApp**: `~/.clawdbot/credentials/whatsapp/<accountId>/creds.json`
|
||||
- **Telegram bot token**: config/env or `channels.telegram.tokenFile`
|
||||
- **Discord bot token**: config/env (token file not yet supported)
|
||||
- **Slack tokens**: config/env (`channels.slack.*`)
|
||||
- **Pairing allowlists**: `~/.clawdbot/credentials/<channel>-allowFrom.json`
|
||||
- **Model auth profiles**: `~/.clawdbot/agents/<agentId>/agent/auth-profiles.json`
|
||||
- **Legacy OAuth import**: `~/.clawdbot/credentials/oauth.json`
|
||||
More detail: [Security](/gateway/security#credential-storage-map).
|
||||
|
||||
## Updating (without wrecking your setup)
|
||||
|
||||
- Keep `~/clawd` and `~/.clawdbot/` as “your stuff”; don’t put personal prompts/config into the `clawdbot` repo.
|
||||
|
||||
@@ -18,6 +18,9 @@ Primary entrypoint:
|
||||
clawdbot onboard
|
||||
```
|
||||
|
||||
Fastest first chat: open the Control UI (no channel setup needed). Run
|
||||
`clawdbot dashboard` and chat in the browser. Docs: [Dashboard](/web/dashboard).
|
||||
|
||||
Follow‑up reconfiguration:
|
||||
|
||||
```bash
|
||||
|
||||
@@ -34,6 +34,9 @@ Notes:
|
||||
- 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
|
||||
|
||||
|
||||
+15
-3
@@ -158,7 +158,19 @@ If you want to use a custom binary location, pass an **absolute** `lobsterPath`
|
||||
|
||||
## 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,7 +187,7 @@ 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`), Clawdbot keeps core tools enabled. To restrict core
|
||||
|
||||
@@ -64,6 +64,14 @@ By default, `clawdhub` installs into `./skills` under your current working
|
||||
directory (or falls back to the configured Clawdbot workspace). Clawdbot picks
|
||||
that up as `<workspace>/skills` on the next session.
|
||||
|
||||
## Security notes
|
||||
|
||||
- Treat third-party skills as **trusted code**. Read them before enabling.
|
||||
- Prefer sandboxed runs for untrusted inputs and risky tools. See [Sandboxing](/gateway/sandboxing).
|
||||
- `skills.entries.*.env` and `skills.entries.*.apiKey` inject secrets into the **host** process
|
||||
for that agent turn (not the sandbox). Keep secrets out of prompts and logs.
|
||||
- For a broader threat model and checklists, see [Security](/gateway/security).
|
||||
|
||||
## Format (AgentSkills + Pi-compatible)
|
||||
|
||||
`SKILL.md` must include at least:
|
||||
|
||||
@@ -19,6 +19,10 @@ Key references:
|
||||
Authentication is enforced at the WebSocket handshake via `connect.params.auth`
|
||||
(token or password). See `gateway.auth` in [Gateway configuration](/gateway/configuration).
|
||||
|
||||
Security note: the Control UI is an **admin surface** (chat, config, exec approvals).
|
||||
Do not expose it publicly. The UI stores the token in `localStorage` after first load.
|
||||
Prefer localhost, Tailscale Serve, or an SSH tunnel.
|
||||
|
||||
## Fast path (recommended)
|
||||
|
||||
- After onboarding, the CLI now auto-opens the dashboard with your token and prints the same tokenized link.
|
||||
|
||||
Reference in new issue
Block a user