Merge branch 'main' into nanogpt

This commit is contained in:
0xGingi authored and GitHub committed 2026-01-26 14:29:42 -05:00
commit b709f32cb3
127 files changed
+4229 -2350

No files matched your search

+4 -4
View File
@@ -27,10 +27,10 @@ Notes:
## Auth
Every request must include the hook token:
- `Authorization: Bearer <token>`
- or `x-clawdbot-token: <token>`
- or `?token=<token>`
Every request must include the hook token. Prefer headers:
- `Authorization: Bearer <token>` (recommended)
- `x-clawdbot-token: <token>`
- `?token=<token>` (deprecated; logs a warning and will be removed in a future major release)
## Endpoints
+1
View File
@@ -21,6 +21,7 @@ Text is supported everywhere; media and reactions vary by channel.
- [BlueBubbles](/channels/bluebubbles) — **Recommended for iMessage**; uses the BlueBubbles macOS server REST API with full feature support (edit, unsend, effects, reactions, group management — edit currently broken on macOS 26 Tahoe).
- [iMessage](/channels/imessage) — macOS only; native integration via imsg (legacy, consider BlueBubbles for new setups).
- [Microsoft Teams](/channels/msteams) — Bot Framework; enterprise support (plugin, installed separately).
- [LINE](/channels/line) — LINE Messaging API bot (plugin, installed separately).
- [Nextcloud Talk](/channels/nextcloud-talk) — Self-hosted chat via Nextcloud Talk (plugin, installed separately).
- [Matrix](/channels/matrix) — Matrix protocol (plugin, installed separately).
- [Nostr](/channels/nostr) — Decentralized DMs via NIP-04 (plugin, installed separately).
+183
View File
@@ -0,0 +1,183 @@
---
summary: "LINE Messaging API plugin setup, config, and usage"
read_when:
- You want to connect Clawdbot to LINE
- You need LINE webhook + credential setup
- You want LINE-specific message options
---
# LINE (plugin)
LINE connects to Clawdbot via the LINE Messaging API. The plugin runs as a webhook
receiver on the gateway and uses your channel access token + channel secret for
authentication.
Status: supported via plugin. Direct messages, group chats, media, locations, Flex
messages, template messages, and quick replies are supported. Reactions and threads
are not supported.
## Plugin required
Install the LINE plugin:
```bash
clawdbot plugins install @clawdbot/line
```
Local checkout (when running from a git repo):
```bash
clawdbot plugins install ./extensions/line
```
## Setup
1) Create a LINE Developers account and open the Console:
https://developers.line.biz/console/
2) Create (or pick) a Provider and add a **Messaging API** channel.
3) Copy the **Channel access token** and **Channel secret** from the channel settings.
4) Enable **Use webhook** in the Messaging API settings.
5) Set the webhook URL to your gateway endpoint (HTTPS required):
```
https://gateway-host/line/webhook
```
The gateway responds to LINE’s webhook verification (GET) and inbound events (POST).
If you need a custom path, set `channels.line.webhookPath` or
`channels.line.accounts.<id>.webhookPath` and update the URL accordingly.
## Configure
Minimal config:
```json5
{
channels: {
line: {
enabled: true,
channelAccessToken: "LINE_CHANNEL_ACCESS_TOKEN",
channelSecret: "LINE_CHANNEL_SECRET",
dmPolicy: "pairing"
}
}
}
```
Env vars (default account only):
- `LINE_CHANNEL_ACCESS_TOKEN`
- `LINE_CHANNEL_SECRET`
Token/secret files:
```json5
{
channels: {
line: {
tokenFile: "/path/to/line-token.txt",
secretFile: "/path/to/line-secret.txt"
}
}
}
```
Multiple accounts:
```json5
{
channels: {
line: {
accounts: {
marketing: {
channelAccessToken: "...",
channelSecret: "...",
webhookPath: "/line/marketing"
}
}
}
}
}
```
## Access control
Direct messages default to pairing. Unknown senders get a pairing code and their
messages are ignored until approved.
```bash
clawdbot pairing list line
clawdbot pairing approve line <CODE>
```
Allowlists and policies:
- `channels.line.dmPolicy`: `pairing | allowlist | open | disabled`
- `channels.line.allowFrom`: allowlisted LINE user IDs for DMs
- `channels.line.groupPolicy`: `allowlist | open | disabled`
- `channels.line.groupAllowFrom`: allowlisted LINE user IDs for groups
- Per-group overrides: `channels.line.groups.<groupId>.allowFrom`
LINE IDs are case-sensitive. Valid IDs look like:
- User: `U` + 32 hex chars
- Group: `C` + 32 hex chars
- Room: `R` + 32 hex chars
## Message behavior
- Text is chunked at 5000 characters.
- Markdown formatting is stripped; code blocks and tables are converted into Flex
cards when possible.
- Streaming responses are buffered; LINE receives full chunks with a loading
animation while the agent works.
- Media downloads are capped by `channels.line.mediaMaxMb` (default 10).
## Channel data (rich messages)
Use `channelData.line` to send quick replies, locations, Flex cards, or template
messages.
```json5
{
text: "Here you go",
channelData: {
line: {
quickReplies: ["Status", "Help"],
location: {
title: "Office",
address: "123 Main St",
latitude: 35.681236,
longitude: 139.767125
},
flexMessage: {
altText: "Status card",
contents: { /* Flex payload */ }
},
templateMessage: {
type: "confirm",
text: "Proceed?",
confirmLabel: "Yes",
confirmData: "yes",
cancelLabel: "No",
cancelData: "no"
}
}
}
}
```
The LINE plugin also ships a `/card` command for Flex message presets:
```
/card info "Welcome" "Thanks for joining!"
```
## Troubleshooting
- **Webhook verification fails:** ensure the webhook URL is HTTPS and the
`channelSecret` matches the LINE console.
- **No inbound events:** confirm the webhook path matches `channels.line.webhookPath`
and that the gateway is reachable from LINE.
- **Media download errors:** raise `channels.line.mediaMaxMb` if media exceeds the
default limit.
+5 -10
View File
@@ -297,7 +297,7 @@ Options:
- `--non-interactive`
- `--mode <local|remote>`
- `--flow <quickstart|advanced|manual>` (manual is an alias for advanced)
- `--auth-choice <setup-token|claude-cli|token|openai-codex|openai-api-key|openrouter-api-key|ai-gateway-api-key|moonshot-api-key|kimi-code-api-key|nanogpt-api-key|codex-cli|gemini-api-key|zai-api-key|apiKey|minimax-api|opencode-zen|skip>`
- `--auth-choice <setup-token|token|chutes|openai-codex|openai-api-key|openrouter-api-key|ai-gateway-api-key|moonshot-api-key|kimi-code-api-key|nanogpt-api-key|synthetic-api-key|venice-api-key|gemini-api-key|zai-api-key|apiKey|minimax-api|minimax-api-lightning|opencode-zen|skip>`
- `--token-provider <id>` (non-interactive; used with `--auth-choice token`)
- `--token <token>` (non-interactive; used with `--auth-choice token`)
- `--token-profile-id <id>` (non-interactive; default: `<provider>:manual`)
@@ -315,7 +315,7 @@ Options:
- `--opencode-zen-api-key <key>`
- `--gateway-port <port>`
- `--gateway-bind <loopback|lan|tailnet|auto|custom>`
- `--gateway-auth <off|token|password>`
- `--gateway-auth <token|password>`
- `--gateway-token <token>`
- `--gateway-password <password>`
- `--remote-url <url>`
@@ -359,7 +359,7 @@ Options:
Manage chat channel accounts (WhatsApp/Telegram/Discord/Google Chat/Slack/Mattermost (plugin)/Signal/iMessage/MS Teams).
Subcommands:
- `channels list`: show configured channels and auth profiles (Claude Code + Codex CLI OAuth sync included).
- `channels list`: show configured channels and auth profiles.
- `channels status`: check gateway reachability and channel health (`--probe` runs extra checks; use `clawdbot health` or `clawdbot status --deep` for gateway health probes).
- Tip: `channels status` prints warnings with suggested fixes when it can detect common misconfigurations (then points you to `clawdbot doctor`).
- `channels logs`: show recent channel logs from the gateway log file.
@@ -391,12 +391,6 @@ Common options:
- `--lines <n>` (default `200`)
- `--json`
OAuth sync sources:
- Claude Code → `anthropic:claude-cli`
- macOS: Keychain item "Claude Code-credentials" (choose "Always Allow" to avoid launchd prompts)
- Linux/Windows: `~/.claude/.credentials.json`
- `~/.codex/auth.json` → `openai-codex:codex-cli`
More detail: [/concepts/oauth](/concepts/oauth)
Examples:
@@ -677,10 +671,11 @@ Tip: when calling `config.set`/`config.apply`/`config.patch` directly, pass `bas
See [/concepts/models](/concepts/models) for fallback behavior and scanning strategy.
Preferred Anthropic auth (CLI token, not API key):
Preferred Anthropic auth (setup-token):
```bash
claude setup-token
clawdbot models auth setup-token --provider anthropic
clawdbot models status
```
+2 -2
View File
@@ -64,5 +64,5 @@ clawdbot models auth paste-token
`clawdbot plugins list` to see which providers are installed.
Notes:
- `setup-token` runs `claude setup-token` on the current machine (requires the Claude Code CLI).
- `paste-token` accepts a token string generated elsewhere.
- `setup-token` prompts for a setup-token value (generate it with `claude setup-token` on any machine).
- `paste-token` accepts a token string generated elsewhere or from automation.
+2 -2
View File
@@ -49,9 +49,9 @@ Clawdbot ships with the pi‑ai catalog. These providers require **no**
### OpenAI Code (Codex)
- Provider: `openai-codex`
- Auth: OAuth or Codex CLI (`~/.codex/auth.json`)
- Auth: OAuth (ChatGPT)
- Example model: `openai-codex/gpt-5.2`
- CLI: `clawdbot onboard --auth-choice openai-codex` or `codex-cli`
- CLI: `clawdbot onboard --auth-choice openai-codex` or `clawdbot models auth login --provider openai-codex`
```json5
{
+21 -48
View File
@@ -1,18 +1,17 @@
---
summary: "OAuth in Clawdbot: token exchange, storage, CLI sync, and multi-account patterns"
summary: "OAuth in Clawdbot: token exchange, storage, and multi-account patterns"
read_when:
- You want to understand Clawdbot OAuth end-to-end
- You hit token invalidation / logout issues
- You want to reuse Claude Code / Codex CLI OAuth tokens
- You want setup-token or OAuth auth flows
- You want multiple accounts or profile routing
---
# OAuth
Clawdbot supports “subscription auth” via OAuth for providers that offer it (notably **Anthropic (Claude Pro/Max)** and **OpenAI Codex (ChatGPT OAuth)**). This page explains:
Clawdbot supports “subscription auth” via OAuth for providers that offer it (notably **OpenAI Codex (ChatGPT OAuth)**). For Anthropic subscriptions, use the **setup-token** flow. This page explains:
- how the OAuth **token exchange** works (PKCE)
- where tokens are **stored** (and why)
- how we **reuse external CLI tokens** (Claude Code / Codex CLI)
- how to handle **multiple accounts** (profiles + per-session overrides)
Clawdbot also supports **provider plugins** that ship their own OAuth or API‑key
@@ -31,7 +30,6 @@ Practical symptom:
To reduce that, Clawdbot treats `auth-profiles.json` as a **token sink**:
- the runtime reads credentials from **one place**
- we can **sync in** credentials from external CLIs instead of doing a second login
- we can keep multiple profiles and route them deterministically
## Storage (where tokens live)
@@ -46,47 +44,39 @@ Legacy import-only file (still supported, but not the main store):
All of the above also respect `$CLAWDBOT_STATE_DIR` (state dir override). Full reference: [/gateway/configuration](/gateway/configuration#auth-storage-oauth--api-keys)
## Reusing Claude Code / Codex CLI OAuth tokens (recommended)
## Anthropic setup-token (subscription auth)
If you already signed in with the external CLIs *on the gateway host*, Clawdbot can reuse those tokens without starting a separate OAuth flow:
Run `claude setup-token` on any machine, then paste it into Clawdbot:
- Claude Code: `anthropic:claude-cli`
- macOS: Keychain item "Claude Code-credentials" (choose "Always Allow" to avoid launchd prompts)
- Linux/Windows: `~/.claude/.credentials.json`
- Codex CLI: reads `~/.codex/auth.json` → profile `openai-codex:codex-cli`
```bash
clawdbot models auth setup-token --provider anthropic
```
Sync happens when Clawdbot loads the auth store (so it stays up-to-date when the CLIs refresh tokens).
On macOS, the first read may trigger a Keychain prompt; run `clawdbot models status`
in a terminal once if the Gateway runs headless and can’t access the entry.
If you generated the token elsewhere, paste it manually:
How to verify:
```bash
clawdbot models auth paste-token --provider anthropic
```
Verify:
```bash
clawdbot models status
clawdbot channels list
```
Or JSON:
```bash
clawdbot channels list --json
```
## OAuth exchange (how login works)
Clawdbot’s interactive login flows are implemented in `@mariozechner/pi-ai` and wired into the wizards/commands.
### Anthropic (Claude Pro/Max)
### Anthropic (Claude Pro/Max) setup-token
Flow shape (PKCE):
Flow shape:
1) generate PKCE verifier/challenge
2) open `https://claude.ai/oauth/authorize?...`
3) user pastes `code#state`
4) exchange at `https://console.anthropic.com/v1/oauth/token`
5) store `{ access, refresh, expires }` under an auth profile
1) run `claude setup-token`
2) paste the token into Clawdbot
3) store as a token auth profile (no refresh)
The wizard path is `clawdbot onboard` → auth choice `oauth` (Anthropic).
The wizard path is `clawdbot onboard` → auth choice `setup-token` (Anthropic).
### OpenAI Codex (ChatGPT OAuth)
@@ -99,7 +89,7 @@ Flow shape (PKCE):
5) exchange at `https://auth.openai.com/oauth/token`
6) extract `accountId` from the access token and store `{ access, refresh, expires, accountId }`
Wizard path is `clawdbot onboard` → auth choice `openai-codex` (or `codex-cli` to reuse an existing Codex CLI login).
Wizard path is `clawdbot onboard` → auth choice `openai-codex`.
## Refresh + expiry
@@ -111,23 +101,6 @@ At runtime:
The refresh flow is automatic; you generally don't need to manage tokens manually.
### Bidirectional sync with Claude Code
When Clawdbot refreshes an Anthropic OAuth token (profile `anthropic:claude-cli`), it **writes the new credentials back** to Claude Code's storage:
- **Linux/Windows**: updates `~/.claude/.credentials.json`
- **macOS**: updates Keychain item "Claude Code-credentials"
This ensures both tools stay in sync and neither gets "logged out" after the other refreshes.
**Why this matters for long-running agents:**
Anthropic OAuth tokens expire after a few hours. Without bidirectional sync:
1. Clawdbot refreshes the token → gets new access token
2. Claude Code still has the old token → gets logged out
With bidirectional sync, both tools always have the latest valid token, enabling autonomous operation for days or weeks without manual intervention.
## Multiple accounts (profiles) + routing
Two patterns:
+17
View File
@@ -117,6 +117,14 @@
"source": "/mattermost/",
"destination": "/channels/mattermost"
},
{
"source": "/line",
"destination": "/channels/line"
},
{
"source": "/line/",
"destination": "/channels/line"
},
{
"source": "/glm",
"destination": "/providers/glm"
@@ -197,6 +205,14 @@
"source": "/providers/msteams/",
"destination": "/channels/msteams"
},
{
"source": "/providers/line",
"destination": "/channels/line"
},
{
"source": "/providers/line/",
"destination": "/channels/line"
},
{
"source": "/providers/signal",
"destination": "/channels/signal"
@@ -974,6 +990,7 @@
"channels/signal",
"channels/imessage",
"channels/msteams",
"channels/line",
"channels/matrix",
"channels/zalo",
"channels/zalouser",
+15 -39
View File
@@ -1,5 +1,5 @@
---
summary: "Model authentication: OAuth, API keys, and Claude Code token reuse"
summary: "Model authentication: OAuth, API keys, and setup-token"
read_when:
- Debugging model auth or OAuth expiry
- Documenting authentication or credential storage
@@ -7,8 +7,8 @@ read_when:
# Authentication
Clawdbot supports OAuth and API keys for model providers. For Anthropic
accounts, we recommend using an **API key**. Clawdbot can also reuse Claude Code
credentials, including the long‑lived token created by `claude setup-token`.
accounts, we recommend using an **API key**. For Claude subscription access,
use the long‑lived token created by `claude setup-token`.
See [/concepts/oauth](/concepts/oauth) for the full OAuth flow and storage
layout.
@@ -47,29 +47,26 @@ API keys for daemon use: `clawdbot onboard`.
See [Help](/help) for details on env inheritance (`env.shellEnv`,
`~/.clawdbot/.env`, systemd/launchd).
## Anthropic: Claude Code CLI setup-token (supported)
## Anthropic: setup-token (subscription auth)
For Anthropic, the recommended path is an **API key**. If you’re already using
Claude Code CLI, the setup-token flow is also supported.
Run it on the **gateway host**:
For Anthropic, the recommended path is an **API key**. If you’re using a Claude
subscription, the setup-token flow is also supported. Run it on the **gateway host**:
```bash
claude setup-token
```
Then verify and sync into Clawdbot:
Then paste it into Clawdbot:
```bash
clawdbot models status
clawdbot doctor
clawdbot models auth setup-token --provider anthropic
```
This should create (or refresh) an auth profile like `anthropic:claude-cli` in
the agent auth store.
If the token was created on another machine, paste it manually:
Clawdbot config sets `auth.profiles["anthropic:claude-cli"].mode` to `"oauth"` so
the profile accepts both OAuth and setup-token credentials. Older configs that
used `"token"` are auto-migrated on load.
```bash
clawdbot models auth paste-token --provider anthropic
```
If you see an Anthropic error like:
@@ -79,12 +76,6 @@ This credential is only authorized for use with Claude Code and cannot be used f
…use an Anthropic API key instead.
Alternative: run the wrapper (also updates Clawdbot config):
```bash
clawdbot models auth setup-token --provider anthropic
```
Manual token entry (any provider; writes `auth-profiles.json` + updates config):
```bash
@@ -101,10 +92,6 @@ clawdbot models status --check
Optional ops scripts (systemd/Termux) are documented here:
[/automation/auth-monitoring](/automation/auth-monitoring)
`clawdbot models status` loads Claude Code credentials into Clawdbot’s
`auth-profiles.json` and shows expiry (warns within 24h by default).
`clawdbot doctor` also performs the sync when it runs.
> `claude setup-token` requires an interactive TTY.
## Checking model auth status
@@ -118,7 +105,7 @@ clawdbot doctor
### Per-session (chat command)
Use `/model <alias-or-id>@<profileId>` to pin a specific provider credential for the current session (example profile ids: `anthropic:claude-cli`, `anthropic:default`).
Use `/model <alias-or-id>@<profileId>` to pin a specific provider credential for the current session (example profile ids: `anthropic:default`, `anthropic:work`).
Use `/model` (or `/model list`) for a compact picker; use `/model status` for the full view (candidates + next auth profile, plus provider endpoint details when configured).
@@ -128,23 +115,12 @@ Set an explicit auth profile order override for an agent (stored in that agent
```bash
clawdbot models auth order get --provider anthropic
clawdbot models auth order set --provider anthropic anthropic:claude-cli
clawdbot models auth order set --provider anthropic anthropic:default
clawdbot models auth order clear --provider anthropic
```
Use `--agent <id>` to target a specific agent; omit it to use the configured default agent.
## How sync works
1. **Claude Code** stores credentials in `~/.claude/.credentials.json` (or
Keychain on macOS).
2. **Clawdbot** syncs those into
`~/.clawdbot/agents/<agentId>/agent/auth-profiles.json` when the auth store is
loaded.
3. Refreshable OAuth profiles can be refreshed automatically on use. Static
token profiles (including Claude Code CLI setup-token) are not refreshable by
Clawdbot.
## Troubleshooting
### “No credentials found”
@@ -159,7 +135,7 @@ clawdbot models status
### Token expiring/expired
Run `clawdbot models status` to confirm which profile is expiring. If the profile
is `anthropic:claude-cli`, rerun `claude setup-token`.
is missing, rerun `claude setup-token` and paste the token again.
## Requirements
+4 -12
View File
@@ -374,12 +374,6 @@ Overrides:
On first use, Clawdbot imports `oauth.json` entries into `auth-profiles.json`.
Clawdbot also auto-syncs OAuth tokens from external CLIs into `auth-profiles.json` (when present on the gateway host):
- Claude Code → `anthropic:claude-cli`
- macOS: Keychain item "Claude Code-credentials" (choose "Always Allow" to avoid launchd prompts)
- Linux/Windows: `~/.claude/.credentials.json`
- `~/.codex/auth.json` (Codex CLI) → `openai-codex:codex-cli`
### `auth`
Optional metadata for auth profiles. This does **not** store secrets; it maps
@@ -400,10 +394,6 @@ rotation order used for failover.
}
```
Note: `anthropic:claude-cli` should use `mode: "oauth"` even when the stored
credential is a setup-token. Clawdbot auto-migrates older configs that used
`mode: "token"`.
### `agents.list[].identity`
Optional per-agent identity used for defaults and UX. This is written by the macOS onboarding assistant.
@@ -2847,9 +2837,11 @@ Control UI base path:
- `gateway.controlUi.basePath` sets the URL prefix where the Control UI is served.
- Examples: `"/ui"`, `"/clawdbot"`, `"/apps/clawdbot"`.
- Default: root (`/`) (unchanged).
- `gateway.controlUi.allowInsecureAuth` allows token-only auth for the Control UI and skips
device identity + pairing (even on HTTPS). Default: `false`. Prefer HTTPS
- `gateway.controlUi.allowInsecureAuth` allows token-only auth for the Control UI when
device identity is omitted (typically over HTTP). Default: `false`. Prefer HTTPS
(Tailscale Serve) or `127.0.0.1`.
- `gateway.controlUi.dangerouslyDisableDeviceAuth` disables device identity checks for the
Control UI (token/password only). Default: `false`. Break-glass only.
Related docs:
- [Control UI](/web/control-ui)
+2 -1
View File
@@ -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
+21 -4
View File
@@ -58,9 +58,13 @@ When the audit prints findings, treat this as a priority order:
The Control UI needs a **secure context** (HTTPS or localhost) to generate device
identity. If you enable `gateway.controlUi.allowInsecureAuth`, the UI falls back
to **token-only auth** and skips device pairing (even on HTTPS). This is a security
to **token-only auth** and skips device pairing when device identity is omitted. This is a security
downgrade—prefer HTTPS (Tailscale Serve) or open the UI on `127.0.0.1`.
For break-glass scenarios only, `gateway.controlUi.dangerouslyDisableDeviceAuth`
disables device identity checks entirely. This is a severe security downgrade;
keep it off unless you are actively debugging and can revert quickly.
`clawdbot security audit` warns when this setting is enabled.
## Reverse Proxy Configuration
@@ -193,10 +197,17 @@ Prompt injection is when an attacker crafts a message that manipulates the model
Even with strong system prompts, **prompt injection is not solved**. What helps in practice:
- Keep inbound DMs locked down (pairing/allowlists).
- Prefer mention gating in groups; avoid “always-on” bots in public rooms.
- Treat links and pasted instructions as hostile by default.
- 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.
- 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)).
Red flags to treat as untrusted:
- “Read this file/URL and do exactly what it says.”
- “Ignore your system prompt or safety rules.”
- “Reveal your hidden instructions or tool outputs.”
- “Paste the full contents of ~/.clawdbot or your logs.”
### Prompt injection does not require public DMs
Even if **only you** can message the bot, prompt injection can still happen via
@@ -210,6 +221,7 @@ tool calls. Reduce the blast radius by:
then pass the summary to your main agent.
- Keeping `web_search` / `web_fetch` / `browser` off for tool-enabled agents unless needed.
- Enabling sandboxing and strict tool allowlists for any agent that touches untrusted input.
- Keeping secrets out of prompts; pass them via env/config on the gateway host instead.
### Model strength (security note)
@@ -226,8 +238,12 @@ Recommendations:
`/reasoning` and `/verbose` can expose internal reasoning or tool output that
was not meant for a public channel. In group settings, treat them as **debug
only** and keep them off unless you explicitly need them. If you enable them,
do so only in trusted DMs or tightly controlled rooms.
only** and keep them off unless you explicitly need them.
Guidance:
- Keep `/reasoning` and `/verbose` disabled in public rooms.
- If you enable them, do so only in trusted DMs or tightly controlled rooms.
- Remember: verbose output can include tool args, URLs, and data the model saw.
## Incident Response (if you suspect compromise)
@@ -544,6 +560,7 @@ access those accounts and data. Treat browser profiles as **sensitive state**:
- For remote gateways, assume “browser control” is equivalent to “operator access” to whatever that profile can reach.
- Treat `browser.controlUrl` endpoints as an admin API: tailnet-only + token auth. Prefer Tailscale Serve over LAN binds.
- Keep `browser.controlToken` separate from `gateway.auth.token` (you can reuse it, but that increases blast radius).
- Prefer env vars for the token (`CLAWDBOT_BROWSER_CONTROL_TOKEN`) instead of storing it in config on disk.
- Chrome extension relay mode is **not** “safer”; it can take over your existing Chrome tabs. Assume it can act as you in whatever that tab/profile can reach.
## Per-agent access profiles (multi-agent)
+3 -8
View File
@@ -53,13 +53,12 @@ clawdbot models status
This means the stored Anthropic OAuth token expired and the refresh failed.
If you’re on a Claude subscription (no API key), the most reliable fix is to
switch to a **Claude Code setup-token** or re-sync Claude Code CLI OAuth on the
**gateway host**.
switch to a **Claude Code setup-token** and paste it on the **gateway host**.
**Recommended (setup-token):**
```bash
# Run on the gateway host (runs Claude Code CLI)
# Run on the gateway host (paste the setup-token)
clawdbot models auth setup-token --provider anthropic
clawdbot models status
```
@@ -71,10 +70,6 @@ clawdbot models auth paste-token --provider anthropic
clawdbot models status
```
**If you want to keep OAuth reuse:**
log in with Claude Code CLI on the gateway host, then run `clawdbot models status`
to sync the refreshed token into Clawdbot’s auth store.
More detail: [Anthropic](/providers/anthropic) and [OAuth](/concepts/oauth).
### Control UI fails on HTTP ("device identity required" / "connect failed")
@@ -214,7 +209,7 @@ the Gateway likely refused to bind.
- Fix: run `clawdbot doctor` to update it (or `clawdbot gateway install --force` for a full rewrite).
**If `Last gateway error:` mentions “refusing to bind … without auth”**
- You set `gateway.bind` to a non-loopback mode (`lan`/`tailnet`/`custom`, or `auto` when loopback is unavailable) but left auth off.
- You set `gateway.bind` to a non-loopback mode (`lan`/`tailnet`/`custom`, or `auto` when loopback is unavailable) but didn’t configure auth.
- Fix: set `gateway.auth.mode` + `gateway.auth.token` (or export `CLAWDBOT_GATEWAY_TOKEN`) and restart the service.
**If `clawdbot gateway status` says `bind=tailnet` but no tailnet interface was found**
+20 -29
View File
@@ -630,7 +630,7 @@ Docs: [Anthropic](/providers/anthropic), [OpenAI](/providers/openai),
### Can I use Claude Max subscription without an API key
Yes. You can authenticate with **Claude Code CLI OAuth** or a **setup-token**
Yes. You can authenticate with a **setup-token**
instead of an API key. This is the subscription path.
Claude Pro/Max subscriptions **do not include an API key**, so this is the
@@ -640,11 +640,7 @@ If you want the most explicit, supported path, use an Anthropic API key.
### How does Anthropic setuptoken auth work
`claude setup-token` generates a **token string** via the Claude Code CLI (it is not available in the web console). You can run it on **any machine**. If Claude Code CLI credentials are present on the gateway host, Clawdbot can reuse them; otherwise choose **Anthropic token (paste setup-token)** and paste the string. The token is stored as an auth profile for the **anthropic** provider and used like an API key or OAuth profile. More detail: [OAuth](/concepts/oauth).
Clawdbot keeps `auth.profiles["anthropic:claude-cli"].mode` set to `"oauth"` so
the profile accepts both OAuth and setup-token credentials; older `"token"` mode
entries auto-migrate.
`claude setup-token` generates a **token string** via the Claude Code CLI (it is not available in the web console). You can run it on **any machine**. Choose **Anthropic token (paste setup-token)** in the wizard or paste it with `clawdbot models auth paste-token --provider anthropic`. The token is stored as an auth profile for the **anthropic** provider and used like an API key (no auto-refresh). More detail: [OAuth](/concepts/oauth).
### Where do I find an Anthropic setuptoken
@@ -656,9 +652,9 @@ claude setup-token
Copy the token it prints, then choose **Anthropic token (paste setup-token)** in the wizard. If you want to run it on the gateway host, use `clawdbot models auth setup-token --provider anthropic`. If you ran `claude setup-token` elsewhere, paste it on the gateway host with `clawdbot models auth paste-token --provider anthropic`. See [Anthropic](/providers/anthropic).
### Do you support Claude subscription auth Claude Code OAuth
### Do you support Claude subscription auth (Claude Pro/Max)
Yes. Clawdbot can **reuse Claude Code CLI credentials** (OAuth) and also supports **setup-token**. If you have a Claude subscription, we recommend **setup-token** for long‑running setups (requires Claude Pro/Max + the `claude` CLI). You can generate it anywhere and paste it on the gateway host. OAuth reuse is supported, but avoid logging in separately via Clawdbot and Claude Code to prevent token conflicts. See [Anthropic](/providers/anthropic) and [OAuth](/concepts/oauth).
Yes — via **setup-token**. Clawdbot no longer reuses Claude Code CLI OAuth tokens; use a setup-token or an Anthropic API key. Generate the token anywhere and paste it on the gateway host. See [Anthropic](/providers/anthropic) and [OAuth](/concepts/oauth).
Note: Claude subscription access is governed by Anthropic’s terms. For production or multi‑user workloads, API keys are usually the safer choice.
@@ -678,13 +674,12 @@ Yes - via pi‑ai’s **Amazon Bedrock (Converse)** provider with **manual confi
### How does Codex auth work
Clawdbot supports **OpenAI Code (Codex)** via OAuth or by reusing your Codex CLI login (`~/.codex/auth.json`). The wizard can import the CLI login or run the OAuth flow and will set the default model to `openai-codex/gpt-5.2` when appropriate. See [Model providers](/concepts/model-providers) and [Wizard](/start/wizard).
Clawdbot supports **OpenAI Code (Codex)** via OAuth (ChatGPT sign-in). The wizard can run the OAuth flow and will set the default model to `openai-codex/gpt-5.2` when appropriate. See [Model providers](/concepts/model-providers) and [Wizard](/start/wizard).
### Do you support OpenAI subscription auth Codex OAuth
Yes. Clawdbot fully supports **OpenAI Code (Codex) subscription OAuth** and can also reuse an
existing Codex CLI login (`~/.codex/auth.json`) on the gateway host. The onboarding wizard
can import the CLI login or run the OAuth flow for you.
Yes. Clawdbot fully supports **OpenAI Code (Codex) subscription OAuth**. The onboarding wizard
can run the OAuth flow for you.
See [OAuth](/concepts/oauth), [Model providers](/concepts/model-providers), and [Wizard](/start/wizard).
@@ -1940,8 +1935,8 @@ You can list available models with `/model`, `/model list`, or `/model status`.
You can also force a specific auth profile for the provider (per session):
```
/model opus@anthropic:claude-cli
/model opus@anthropic:default
/model opus@anthropic:work
```
Tip: `/model status` shows which agent is active, which `auth-profiles.json` file is being used, and which auth profile will be tried next.
@@ -2145,21 +2140,17 @@ It means the system attempted to use the auth profile ID `anthropic:default`, bu
- **Sanity‑check model/auth status**
- Use `clawdbot models status` to see configured models and whether providers are authenticated.
**Fix checklist for No credentials found for profile anthropic claude cli**
**Fix checklist for No credentials found for profile anthropic**
This means the run is pinned to the **Claude Code CLI** profile, but the Gateway
can’t find that profile in its auth store.
This means the run is pinned to an Anthropic auth profile, but the Gateway
can’t find it in its auth store.
- **Sync the Claude Code CLI token on the gateway host**
- Run `clawdbot models status` (it loads + syncs Claude Code CLI credentials).
- If it still says missing: run `claude setup-token` (or `clawdbot models auth setup-token --provider anthropic`) and retry.
- **If the token was created on another machine**
- Paste it into the gateway host with `clawdbot models auth paste-token --provider anthropic`.
- **Check the profile mode**
- `auth.profiles["anthropic:claude-cli"].mode` must be `"oauth"` (token mode rejects OAuth credentials).
- **Use a setup-token**
- Run `claude setup-token`, then paste it with `clawdbot models auth setup-token --provider anthropic`.
- If the token was created on another machine, use `clawdbot models auth paste-token --provider anthropic`.
- **If you want to use an API key instead**
- Put `ANTHROPIC_API_KEY` in `~/.clawdbot/.env` on the **gateway host**.
- Clear any pinned order that forces `anthropic:claude-cli`:
- Clear any pinned order that forces a missing profile:
```bash
clawdbot models auth order clear --provider anthropic
```
@@ -2181,7 +2172,7 @@ Fix: Clawdbot now strips unsigned thinking blocks for Google Antigravity Claude.
## Auth profiles: what they are and how to manage them
Related: [/concepts/oauth](/concepts/oauth) (OAuth flows, token storage, multi-account patterns, CLI sync)
Related: [/concepts/oauth](/concepts/oauth) (OAuth flows, token storage, multi-account patterns)
### What is an auth profile
@@ -2212,10 +2203,10 @@ You can also set a **per-agent** order override (stored in that agent’s `auth-
clawdbot models auth order get --provider anthropic
# Lock rotation to a single profile (only try this one)
clawdbot models auth order set --provider anthropic anthropic:claude-cli
clawdbot models auth order set --provider anthropic anthropic:default
# Or set an explicit order (fallback within provider)
clawdbot models auth order set --provider anthropic anthropic:claude-cli anthropic:default
clawdbot models auth order set --provider anthropic anthropic:work anthropic:default
# Clear override (fall back to config auth.order / round-robin)
clawdbot models auth order clear --provider anthropic
@@ -2224,7 +2215,7 @@ clawdbot models auth order clear --provider anthropic
To target a specific agent:
```bash
clawdbot models auth order set --provider anthropic --agent main anthropic:claude-cli
clawdbot models auth order set --provider anthropic --agent main anthropic:default
```
### OAuth vs API key whats the difference
@@ -2234,7 +2225,7 @@ Clawdbot supports both:
- **OAuth** often leverages subscription access (where applicable).
- **API keys** use pay‑per‑token billing.
The wizard explicitly supports Anthropic OAuth and OpenAI Codex OAuth and can store API keys for you.
The wizard explicitly supports Anthropic setup-token and OpenAI Codex OAuth and can store API keys for you.
## Gateway: ports, “already running”, and remote mode
+13 -21
View File
@@ -1,5 +1,5 @@
---
summary: "Clawdbot on DigitalOcean (cheapest paid VPS option)"
summary: "Clawdbot on DigitalOcean (simple paid VPS option)"
read_when:
- Setting up Clawdbot on DigitalOcean
- Looking for cheap VPS hosting for Clawdbot
@@ -11,22 +11,22 @@ read_when:
Run a persistent Clawdbot Gateway on DigitalOcean for **$6/month** (or $4/mo with reserved pricing).
If you want something even cheaper, see [Oracle Cloud (Free Tier)](#oracle-cloud-free-alternative) at the bottom — it's **actually free forever**.
If you want a $0/month option and don’t mind ARM + provider-specific setup, see the [Oracle Cloud guide](/platforms/oracle).
## Cost Comparison (2026)
| Provider | Plan | Specs | Price/mo | Notes |
|----------|------|-------|----------|-------|
| **Oracle Cloud** | Always Free ARM | 4 OCPU, 24GB RAM | **$0** | Best value, requires ARM-compatible setup |
| **Hetzner** | CX22 | 2 vCPU, 4GB RAM | €3.79 (~$4) | Cheapest paid, EU datacenters |
| **DigitalOcean** | Basic | 1 vCPU, 1GB RAM | $6 | Easy UI, good docs |
| **Vultr** | Cloud Compute | 1 vCPU, 1GB RAM | $6 | Many locations |
| **Linode** | Nanode | 1 vCPU, 1GB RAM | $5 | Now part of Akamai |
| Oracle Cloud | Always Free ARM | up to 4 OCPU, 24GB RAM | $0 | ARM, limited capacity / signup quirks |
| Hetzner | CX22 | 2 vCPU, 4GB RAM | €3.79 (~$4) | Cheapest paid option |
| DigitalOcean | Basic | 1 vCPU, 1GB RAM | $6 | Easy UI, good docs |
| Vultr | Cloud Compute | 1 vCPU, 1GB RAM | $6 | Many locations |
| Linode | Nanode | 1 vCPU, 1GB RAM | $5 | Now part of Akamai |
**Recommendation:**
- **Free:** Oracle Cloud ARM (if you can handle the signup process)
- **Paid:** Hetzner CX22 (best specs per dollar) — see [Hetzner guide](/platforms/hetzner)
- **Easy:** DigitalOcean (this guide) — beginner-friendly UI
**Picking a provider:**
- DigitalOcean: simplest UX + predictable setup (this guide)
- Hetzner: good price/perf (see [Hetzner guide](/platforms/hetzner))
- Oracle Cloud: can be $0/month, but is more finicky and ARM-only (see [Oracle guide](/platforms/oracle))
---
@@ -192,7 +192,7 @@ tar -czvf clawdbot-backup.tar.gz ~/.clawdbot ~/clawd
## Oracle Cloud Free Alternative
Oracle Cloud offers **Always Free** ARM instances that are significantly more powerful:
Oracle Cloud offers **Always Free** ARM instances that are significantly more powerful than any paid option here — for $0/month.
| What you get | Specs |
|--------------|-------|
@@ -201,19 +201,11 @@ Oracle Cloud offers **Always Free** ARM instances that are significantly more po
| **200GB storage** | Block volume |
| **Forever free** | No credit card charges |
### Quick setup:
1. Sign up at [oracle.com/cloud/free](https://www.oracle.com/cloud/free/)
2. Create a VM.Standard.A1.Flex instance (ARM)
3. Choose Oracle Linux or Ubuntu
4. Allocate up to 4 OCPU / 24GB RAM within free tier
5. Follow the same Clawdbot install steps above
**Caveats:**
- Signup can be finicky (retry if it fails)
- ARM architecture — most things work, but some binaries need ARM builds
- Oracle may reclaim idle instances (keep them active)
For the full Oracle guide, see the [community docs](https://gist.github.com/rssnyder/51e3cfedd730e7dd5f4a816143b25dbd).
For the full setup guide, see [Oracle Cloud](/platforms/oracle). For signup tips and troubleshooting the enrollment process, see this [community guide](https://gist.github.com/rssnyder/51e3cfedd730e7dd5f4a816143b25dbd).
---
+112 -1
View File
@@ -39,7 +39,9 @@ fly volumes create clawdbot_data --size 1 --region iad
## 2) Configure fly.toml
Edit `fly.toml` to match your app name and requirements:
Edit `fly.toml` to match your app name and requirements.
**Security note:** The default config exposes a public URL. For a hardened deployment with no public IP, see [Private Deployment](#private-deployment-hardened) or use `fly.private.toml`.
```toml
app = "my-clawdbot" # Your app name
@@ -104,6 +106,7 @@ fly secrets set DISCORD_BOT_TOKEN=MTQ...
**Notes:**
- Non-loopback binds (`--bind lan`) require `CLAWDBOT_GATEWAY_TOKEN` for security.
- Treat these tokens like passwords.
- **Prefer env vars over config file** for all API keys and tokens. This keeps secrets out of `clawdbot.json` where they could be accidentally exposed or logged.
## 4) Deploy
@@ -337,6 +340,114 @@ fly machine update <machine-id> --vm-memory 2048 --command "node dist/index.js g
**Note:** After `fly deploy`, the machine command may reset to what's in `fly.toml`. If you made manual changes, re-apply them after deploy.
## Private Deployment (Hardened)
By default, Fly allocates public IPs, making your gateway accessible at `https://your-app.fly.dev`. This is convenient but means your deployment is discoverable by internet scanners (Shodan, Censys, etc.).
For a hardened deployment with **no public exposure**, use the private template.
### When to use private deployment
- You only make **outbound** calls/messages (no inbound webhooks)
- You use **ngrok or Tailscale** tunnels for any webhook callbacks
- You access the gateway via **SSH, proxy, or WireGuard** instead of browser
- You want the deployment **hidden from internet scanners**
### Setup
Use `fly.private.toml` instead of the standard config:
```bash
# Deploy with private config
fly deploy -c fly.private.toml
```
Or convert an existing deployment:
```bash
# List current IPs
fly ips list -a my-clawdbot
# Release public IPs
fly ips release <public-ipv4> -a my-clawdbot
fly ips release <public-ipv6> -a my-clawdbot
# Switch to private config so future deploys don't re-allocate public IPs
# (remove [http_service] or deploy with the private template)
fly deploy -c fly.private.toml
# Allocate private-only IPv6
fly ips allocate-v6 --private -a my-clawdbot
```
After this, `fly ips list` should show only a `private` type IP:
```
VERSION IP TYPE REGION
v6 fdaa:x:x:x:x::x private global
```
### Accessing a private deployment
Since there's no public URL, use one of these methods:
**Option 1: Local proxy (simplest)**
```bash
# Forward local port 3000 to the app
fly proxy 3000:3000 -a my-clawdbot
# Then open http://localhost:3000 in browser
```
**Option 2: WireGuard VPN**
```bash
# Create WireGuard config (one-time)
fly wireguard create
# Import to WireGuard client, then access via internal IPv6
# Example: http://[fdaa:x:x:x:x::x]:3000
```
**Option 3: SSH only**
```bash
fly ssh console -a my-clawdbot
```
### Webhooks with private deployment
If you need webhook callbacks (Twilio, Telnyx, etc.) without public exposure:
1. **ngrok tunnel** - Run ngrok inside the container or as a sidecar
2. **Tailscale Funnel** - Expose specific paths via Tailscale
3. **Outbound-only** - Some providers (Twilio) work fine for outbound calls without webhooks
Example voice-call config with ngrok:
```json
{
"plugins": {
"entries": {
"voice-call": {
"enabled": true,
"config": {
"provider": "twilio",
"tunnel": { "provider": "ngrok" }
}
}
}
}
}
```
The ngrok tunnel runs inside the container and provides a public webhook URL without exposing the Fly app itself.
### Security benefits
| Aspect | Public | Private |
|--------|--------|---------|
| Internet scanners | Discoverable | Hidden |
| Direct attacks | Possible | Blocked |
| Control UI access | Browser | Proxy/VPN |
| Webhook delivery | Direct | Via tunnel |
## Notes
- Fly.io uses **x86 architecture** (not ARM)
+291
View File
@@ -0,0 +1,291 @@
---
summary: "Clawdbot on Oracle Cloud (Always Free ARM)"
read_when:
- Setting up Clawdbot on Oracle Cloud
- Looking for low-cost VPS hosting for Clawdbot
- Want 24/7 Clawdbot on a small server
---
# Clawdbot on Oracle Cloud (OCI)
## Goal
Run a persistent Clawdbot Gateway on Oracle Cloud's **Always Free** ARM tier.
Oracle’s free tier can be a great fit for Clawdbot (especially if you already have an OCI account), but it comes with tradeoffs:
- ARM architecture (most things work, but some binaries may be x86-only)
- Capacity and signup can be finicky
## Cost Comparison (2026)
| Provider | Plan | Specs | Price/mo | Notes |
|----------|------|-------|----------|-------|
| Oracle Cloud | Always Free ARM | up to 4 OCPU, 24GB RAM | $0 | ARM, limited capacity |
| Hetzner | CX22 | 2 vCPU, 4GB RAM | ~ $4 | Cheapest paid option |
| DigitalOcean | Basic | 1 vCPU, 1GB RAM | $6 | Easy UI, good docs |
| Vultr | Cloud Compute | 1 vCPU, 1GB RAM | $6 | Many locations |
| Linode | Nanode | 1 vCPU, 1GB RAM | $5 | Now part of Akamai |
---
## Prerequisites
- Oracle Cloud account ([signup](https://www.oracle.com/cloud/free/)) — see [community signup guide](https://gist.github.com/rssnyder/51e3cfedd730e7dd5f4a816143b25dbd) if you hit issues
- Tailscale account (free at [tailscale.com](https://tailscale.com))
- ~30 minutes
## 1) Create an OCI Instance
1. Log into [Oracle Cloud Console](https://cloud.oracle.com/)
2. Navigate to **Compute → Instances → Create Instance**
3. Configure:
- **Name:** `clawdbot`
- **Image:** Ubuntu 24.04 (aarch64)
- **Shape:** `VM.Standard.A1.Flex` (Ampere ARM)
- **OCPUs:** 2 (or up to 4)
- **Memory:** 12 GB (or up to 24 GB)
- **Boot volume:** 50 GB (up to 200 GB free)
- **SSH key:** Add your public key
4. Click **Create**
5. Note the public IP address
**Tip:** If instance creation fails with "Out of capacity", try a different availability domain or retry later. Free tier capacity is limited.
## 2) Connect and Update
```bash
# Connect via public IP
ssh ubuntu@YOUR_PUBLIC_IP
# Update system
sudo apt update && sudo apt upgrade -y
sudo apt install -y build-essential
```
**Note:** `build-essential` is required for ARM compilation of some dependencies.
## 3) Configure User and Hostname
```bash
# Set hostname
sudo hostnamectl set-hostname clawdbot
# Set password for ubuntu user
sudo passwd ubuntu
# Enable lingering (keeps user services running after logout)
sudo loginctl enable-linger ubuntu
```
## 4) Install Tailscale
```bash
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --ssh --hostname=clawdbot
```
This enables Tailscale SSH, so you can connect via `ssh clawdbot` from any device on your tailnet — no public IP needed.
Verify:
```bash
tailscale status
```
**From now on, connect via Tailscale:** `ssh ubuntu@clawdbot` (or use the Tailscale IP).
## 5) Install Clawdbot
```bash
curl -fsSL https://clawd.bot/install.sh | bash
source ~/.bashrc
```
When prompted "How do you want to hatch your bot?", select **"Do this later"**.
> Note: If you hit ARM-native build issues, start with system packages (e.g. `sudo apt install -y build-essential`) before reaching for Homebrew.
## 6) Configure Gateway (loopback + token auth) and enable Tailscale Serve
Use token auth as the default. It’s predictable and avoids needing any “insecure auth” Control UI flags.
```bash
# Keep the Gateway private on the VM
clawdbot config set gateway.bind loopback
# Require auth for the Gateway + Control UI
clawdbot config set gateway.auth.mode token
clawdbot doctor --generate-gateway-token
# Expose over Tailscale Serve (HTTPS + tailnet access)
clawdbot config set gateway.tailscale.mode serve
clawdbot config set gateway.trustedProxies '["127.0.0.1"]'
systemctl --user restart clawdbot-gateway
```
## 7) Verify
```bash
# Check version
clawdbot --version
# Check daemon status
systemctl --user status clawdbot-gateway
# Check Tailscale Serve
tailscale serve status
# Test local response
curl http://localhost:18789
```
## 8) Lock Down VCN Security
Now that everything is working, lock down the VCN to block all traffic except Tailscale. OCI's Virtual Cloud Network acts as a firewall at the network edge — traffic is blocked before it reaches your instance.
1. Go to **Networking → Virtual Cloud Networks** in the OCI Console
2. Click your VCN → **Security Lists** → Default Security List
3. **Remove** all ingress rules except:
- `0.0.0.0/0 UDP 41641` (Tailscale)
4. Keep default egress rules (allow all outbound)
This blocks SSH on port 22, HTTP, HTTPS, and everything else at the network edge. From now on, you can only connect via Tailscale.
---
## Access the Control UI
From any device on your Tailscale network:
```
https://clawdbot.<tailnet-name>.ts.net/
```
Replace `<tailnet-name>` with your tailnet name (visible in `tailscale status`).
No SSH tunnel needed. Tailscale provides:
- HTTPS encryption (automatic certs)
- Authentication via Tailscale identity
- Access from any device on your tailnet (laptop, phone, etc.)
---
## Security: VCN + Tailscale (recommended baseline)
With the VCN locked down (only UDP 41641 open) and the Gateway bound to loopback, you get strong defense-in-depth: public traffic is blocked at the network edge, and admin access happens over your tailnet.
This setup often removes the *need* for extra host-based firewall rules purely to stop Internet-wide SSH brute force — but you should still keep the OS updated, run `clawdbot security audit`, and verify you aren’t accidentally listening on public interfaces.
### What's Already Protected
| Traditional Step | Needed? | Why |
|------------------|---------|-----|
| UFW firewall | No | VCN blocks before traffic reaches instance |
| fail2ban | No | No brute force if port 22 blocked at VCN |
| sshd hardening | No | Tailscale SSH doesn't use sshd |
| Disable root login | No | Tailscale uses Tailscale identity, not system users |
| SSH key-only auth | No | Tailscale authenticates via your tailnet |
| IPv6 hardening | Usually not | Depends on your VCN/subnet settings; verify what’s actually assigned/exposed |
### Still Recommended
- **Credential permissions:** `chmod 700 ~/.clawdbot`
- **Security audit:** `clawdbot security audit`
- **System updates:** `sudo apt update && sudo apt upgrade` regularly
- **Monitor Tailscale:** Review devices in [Tailscale admin console](https://login.tailscale.com/admin)
### Verify Security Posture
```bash
# Confirm no public ports listening
sudo ss -tlnp | grep -v '127.0.0.1\|::1'
# Verify Tailscale SSH is active
tailscale status | grep -q 'offers: ssh' && echo "Tailscale SSH active"
# Optional: disable sshd entirely
sudo systemctl disable --now ssh
```
---
## Fallback: SSH Tunnel
If Tailscale Serve isn't working, use an SSH tunnel:
```bash
# From your local machine (via Tailscale)
ssh -L 18789:127.0.0.1:18789 ubuntu@clawdbot
```
Then open `http://localhost:18789`.
---
## Troubleshooting
### Instance creation fails ("Out of capacity")
Free tier ARM instances are popular. Try:
- Different availability domain
- Retry during off-peak hours (early morning)
- Use the "Always Free" filter when selecting shape
### Tailscale won't connect
```bash
# Check status
sudo tailscale status
# Re-authenticate
sudo tailscale up --ssh --hostname=clawdbot --reset
```
### Gateway won't start
```bash
clawdbot gateway status
clawdbot doctor --non-interactive
journalctl --user -u clawdbot-gateway -n 50
```
### Can't reach Control UI
```bash
# Verify Tailscale Serve is running
tailscale serve status
# Check gateway is listening
curl http://localhost:18789
# Restart if needed
systemctl --user restart clawdbot-gateway
```
### ARM binary issues
Some tools may not have ARM builds. Check:
```bash
uname -m # Should show aarch64
```
Most npm packages work fine. For binaries, look for `linux-arm64` or `aarch64` releases.
---
## Persistence
All state lives in:
- `~/.clawdbot/` — config, credentials, session data
- `~/clawd/` — workspace (SOUL.md, memory, artifacts)
Back up periodically:
```bash
tar -czvf clawdbot-backup.tar.gz ~/.clawdbot ~/clawd
```
---
## See Also
- [Gateway remote access](/gateway/remote) — other remote access patterns
- [Tailscale integration](/gateway/tailscale) — full Tailscale docs
- [Gateway configuration](/gateway/configuration) — all config options
- [DigitalOcean guide](/platforms/digitalocean) — if you want paid + easier signup
- [Hetzner guide](/platforms/hetzner) — Docker-based alternative
+2
View File
@@ -103,6 +103,8 @@ Notes:
- Plivo requires a **publicly reachable** webhook URL.
- `mock` is a local dev provider (no network calls).
- `skipSignatureVerification` is for local testing only.
- If you use ngrok free tier, set `publicUrl` to the exact ngrok URL; signature verification is always enforced.
- Ngrok free tier URLs can change or add interstitial behavior; if `publicUrl` drifts, Twilio signatures will fail. For production, prefer a stable domain or Tailscale funnel.
## TTS for calls
+10 -14
View File
@@ -1,14 +1,13 @@
---
summary: "Use Anthropic Claude via API keys or Claude Code CLI auth in Clawdbot"
summary: "Use Anthropic Claude via API keys or setup-token in Clawdbot"
read_when:
- You want to use Anthropic models in Clawdbot
- You want setup-token or Claude Code CLI auth instead of API keys
- You want setup-token instead of API keys
---
# Anthropic (Claude)
Anthropic builds the **Claude** model family and provides access via an API.
In Clawdbot you can authenticate with an API key or reuse **Claude Code CLI** credentials
(setup-token or OAuth).
In Clawdbot you can authenticate with an API key or a **setup-token**.
## Option A: Anthropic API key
@@ -37,7 +36,7 @@ clawdbot onboard --anthropic-api-key "$ANTHROPIC_API_KEY"
## Prompt caching (Anthropic API)
Clawdbot does **not** override Anthropic’s default cache TTL unless you set it.
This is **API-only**; Claude Code CLI OAuth ignores TTL settings.
This is **API-only**; subscription auth does not honor TTL settings.
To set the TTL per model, use `cacheControlTtl` in the model `params`:
@@ -58,9 +57,9 @@ To set the TTL per model, use `cacheControlTtl` in the model `params`:
Clawdbot includes the `extended-cache-ttl-2025-04-11` beta flag for Anthropic API
requests; keep it if you override provider headers (see [/gateway/configuration](/gateway/configuration)).
## Option B: Claude Code CLI (setup-token or OAuth)
## Option B: Claude setup-token
**Best for:** using your Claude subscription or existing Claude Code CLI login.
**Best for:** using your Claude subscription.
### Where to get a setup-token
@@ -85,8 +84,8 @@ clawdbot models auth paste-token --provider anthropic
### CLI setup
```bash
# Reuse Claude Code CLI OAuth credentials if already logged in
clawdbot onboard --auth-choice claude-cli
# Paste a setup-token during onboarding
clawdbot onboard --auth-choice setup-token
```
### Config snippet
@@ -100,10 +99,7 @@ clawdbot onboard --auth-choice claude-cli
## Notes
- Generate the setup-token with `claude setup-token` and paste it, or run `clawdbot models auth setup-token` on the gateway host.
- If you see “OAuth token refresh failed …” on a Claude subscription, re-auth with a setup-token or resync Claude Code CLI OAuth on the gateway host. See [/gateway/troubleshooting#oauth-token-refresh-failed-anthropic-claude-subscription](/gateway/troubleshooting#oauth-token-refresh-failed-anthropic-claude-subscription).
- Clawdbot writes `auth.profiles["anthropic:claude-cli"].mode` as `"oauth"` so the profile
accepts both OAuth and setup-token credentials. Older configs using `"token"` are
auto-migrated on load.
- If you see “OAuth token refresh failed …” on a Claude subscription, re-auth with a setup-token. See [/gateway/troubleshooting#oauth-token-refresh-failed-anthropic-claude-subscription](/gateway/troubleshooting#oauth-token-refresh-failed-anthropic-claude-subscription).
- Auth details + reuse rules are in [/concepts/oauth](/concepts/oauth).
## Troubleshooting
@@ -119,7 +115,7 @@ clawdbot onboard --auth-choice claude-cli
- Re-run onboarding for that agent, or paste a setup-token / API key on the
gateway host, then verify with `clawdbot models status`.
**No credentials found for profile `anthropic:default` or `anthropic:claude-cli`**
**No credentials found for profile `anthropic:default`**
- Run `clawdbot models status` to see which auth profile is active.
- Re-run onboarding, or paste a setup-token / API key for that profile.
+1 -1
View File
@@ -141,5 +141,5 @@ launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.claude-max-api.plist
## See Also
- [Anthropic provider](/providers/anthropic) - Native Clawdbot integration with Claude Code CLI OAuth
- [Anthropic provider](/providers/anthropic) - Native Clawdbot integration with Claude setup-token or API keys
- [OpenAI provider](/providers/openai) - For OpenAI/Codex subscriptions
+5 -9
View File
@@ -7,9 +7,7 @@ read_when:
# OpenAI
OpenAI provides developer APIs for GPT models. Codex supports **ChatGPT sign-in** for subscription
access or **API key** sign-in for usage-based access. Codex cloud requires ChatGPT sign-in, while
the Codex CLI supports either sign-in method. The Codex CLI caches login details in
`~/.codex/auth.json` (or your OS credential store), which Clawdbot can reuse.
access or **API key** sign-in for usage-based access. Codex cloud requires ChatGPT sign-in.
## Option A: OpenAI API key (OpenAI Platform)
@@ -38,16 +36,14 @@ clawdbot onboard --openai-api-key "$OPENAI_API_KEY"
**Best for:** using ChatGPT/Codex subscription access instead of an API key.
Codex cloud requires ChatGPT sign-in, while the Codex CLI supports ChatGPT or API key sign-in.
Clawdbot can reuse your **Codex CLI** login (`~/.codex/auth.json`) or run the OAuth flow.
### CLI setup
```bash
# Reuse existing Codex CLI login
clawdbot onboard --auth-choice codex-cli
# Or run Codex OAuth in the wizard
# Run Codex OAuth in the wizard
clawdbot onboard --auth-choice openai-codex
# Or run OAuth directly
clawdbot models auth login --provider openai-codex
```
### Config snippet
+1 -1
View File
@@ -132,7 +132,7 @@ Examples:
/model list
/model 3
/model openai/gpt-5.2
/model opus@anthropic:claude-cli
/model opus@anthropic:default
/model status
```
+2 -1
View File
@@ -1,5 +1,5 @@
---
summary: "VPS hosting hub for Clawdbot (Fly/Hetzner/GCP/exe.dev)"
summary: "VPS hosting hub for Clawdbot (Oracle/Fly/Hetzner/GCP/exe.dev)"
read_when:
- You want to run the Gateway in the cloud
- You need a quick map of VPS/hosting guides
@@ -11,6 +11,7 @@ deployments work at a high level.
## Pick a provider
- **Oracle Cloud (Always Free)**: [Oracle](/platforms/oracle) — $0/month (Always Free, ARM; capacity/signup can be finicky)
- **Fly.io**: [Fly.io](/platforms/fly)
- **Hetzner (Docker)**: [Hetzner](/platforms/hetzner)
- **GCP (Compute Engine)**: [GCP](/platforms/gcp)