Dockerインストールガイド

対応バージョン：v1.8.23+ 最終更新：2026-04-22

本ガイドでは Docker Compose のデプロイ、Codex のデバイスコードログイン、API キー、認証情報の volume、channel webhook、更新を説明します。

ローカルで試すだけなら、まず docs/deployment-guide.md §1 のネイティブインストール手順を参照してください。ネイティブインストールの方が起動が速く、デバッグも簡単です。 Dockerはサーバーデプロイ、実行環境の分離、統一環境が必要なチームに向いています。

1. 概要

DuDuClawのDockerイメージは container/Dockerfile.server で構築され、3段階ビルドを採用しています。

Stage	内容
1. frontend-builder	`node:22-slim` + React/TSフロントエンドのビルド
2. rust-builder	`rust:slim` + `duduclaw` リリースバイナリのコンパイル
3. production	`python:3.12-slim` + 三大AI CLI + Docker CLI + 実行環境

最終イメージには以下が組み込まれています。

duduclaw メインプログラム（Rust製、dashboard込み）
@anthropic-ai/claude-code、@openai/codex（npm i -g でインストール）
docker.io CLI（マウントしたソケットの先にある Docker daemon のクライアント。タスクサンドボックスを有効にした場合に使用）
（任意）Python 3.12：LLMLingua-2 のプロンプト圧縮（llmlingua が必要）にのみ必要。Skillのセキュリティスキャンとchannel返信はすでにRustネイティブ実装で、Pythonには依存しません

2. 前提条件

項目	バージョン	備考
Docker Engine	≥ 24.0	Linuxはネイティブ版を直接インストール推奨。macOS / WindowsはDocker DesktopまたはColimaを使用
Docker Compose	v2.20+	最近のDockerには標準搭載。コマンドは `docker compose` で、旧来の `docker-compose` ではない
Git	任意	ソースコードのclone用
ディスク容量	≥ 4 GB	ビルド中は一時的に約3 GB使用。完成イメージは約1.2 GB
Port	`18789`	デフォルトのgateway port、変更可能

channel webhook（LINE、WhatsApp、Feishu など webhook を使うチャネル）で外部からのメッセージを受信するには、 公開HTTPS URL が別途必要です。最も手軽な選択肢は Tailscale Funnel または Cloudflare Tunnelです。

3. クイックスタート

# 1. ソースコードをclone
git clone https://github.com/zhixuli0406/DuDuClaw.git
cd DuDuClaw

# 2. .envを作成（必要に応じて記入）
cp .env.example .env
$EDITOR .env

# 3. 起動
docker compose up -d

# 4. 起動ログを確認
docker compose logs -f duduclaw

# 5. 動作確認
curl http://localhost:18789/health
# {"status":"ok","version":"1.8.23", ...}

# 6. Dashboardを開く
open http://localhost:18789

初回起動時、server-entrypoint.sh は ~/.duduclaw/config.toml が存在しないことを検出し、自動的に duduclaw onboard --yes を実行して基本設定ファイルを生成します（API keyとchannel tokenは暗号化して保存されます）。

4. 環境変数（`.env`）

docker-compose.yml は定義済みの変数のみを読み込み、未定義の変数は空文字列として渡されます （すべて ${VAR:-} 構文を使用しているため）。以下のリストは用途別に分類しています。

4.1 Runtime認証（いずれか1つ以上を設定）

変数	用途	備考
`CLAUDE_CODE_OAUTH_TOKEN`	Claude Codeの長期有効token	`claude setup-token` で生成。ブラウザのないコンテナ環境に適している。サブスクリプションの認証情報なので、先に第6節のリスク説明を読むこと
`ANTHROPIC_API_KEY`	Claude APIキー	Fallback、従量課金
`OPENAI_API_KEY`	Codex / OpenAI-compat APIキー	Fallback。ChatGPT Plus/Pro OAuthはvolume経由
`GEMINI_API_KEY`	Gemini APIキー	Fallback。Google OAuthはvolume経由

最低いずれか1組が利用可能である必要があります。DuDuClawは agent.toml [runtime] と [model] api_mode に基づいてどれを使うか決定します。詳細は §6 CLI の認証設定を参照してください。

4.2 Channel Tokens

変数	Channel
`LINE_CHANNEL_TOKEN` / `LINE_CHANNEL_SECRET`	LINE Messaging API
`TELEGRAM_BOT_TOKEN`	Telegram Bot
`DISCORD_BOT_TOKEN`	Discord Bot
`SLACK_BOT_TOKEN` / `SLACK_APP_TOKEN`	Slack Socket Mode
`WHATSAPP_ACCESS_TOKEN` など	WhatsApp Cloud API（`.env.example` を参照）
`FEISHU_APP_ID` / `FEISHU_APP_SECRET`	Feishu

実際に使用するchannelの分だけ記入すれば十分です。未記入の変数に対応するchannelは起動しません。

docker-compose.yml は現状 LINE_* / TELEGRAM_* / DISCORD_* の3グループのみをデフォルトで注入します。他のchannelを環境変数経由で渡すには、compose ファイルの environment: ブロックに自分で追加するか、起動後に Dashboard → Channels → Add からホット追加する方法があります（推奨。gatewayの再起動が不要で、tokenも即座に暗号化されてconfigに書き込まれます）。

4.3 Bind / Port関連

変数	デフォルト	説明
`DUDUCLAW_BIND`	`0.0.0.0`	Gatewayのlistenアドレス。コンテナ内では必ず `0.0.0.0` でなければ外部からアクセスできません
`DUDUCLAW_ALLOWED_ORIGINS`	（空）	Dashboard WebSocket/CORSの追加許可 `Origin`、カンマ区切り。tailnetやリバースプロキシ経由でdashboardを開き、WSが403になる場合に設定します（§13 トラブルシューティングを参照）。config.tomlの `[gateway] allowed_origins` とマージされます

Portはenv varではなくcompose ファイル内で設定します。詳細は§5 Port設定の詳細を参照してください。

4.4 その他

変数	用途
`TS_AUTHKEY`	Tailscale Funnelの起動時に自動でtailnetに参加させる（`--profile tailscale` と併用）

5. Port設定の詳細

5.1 デフォルト

docker-compose.yml：

services:
  duduclaw:
    ports:
      - "18789:18789"   # HOST:CONTAINER
    environment:
      - DUDUCLAW_BIND=0.0.0.0

コンテナ内部：gatewayは常に 0.0.0.0:18789 にbindされます。これは意図的な設計で、コンテナ自体が隔離されたネットワーク空間であるため、localhostにbindすると外部からアクセスできなくなります。
ホスト：18789:18789 によりホストの18789番portがコンテナの18789番portへ転送されます。

5.2 ホストportの変更

最もよくあるケースは18789が既に使用中、または複数インスタンスが必要な場合です。左側の数字だけを変更します。

    ports:
      - "28789:18789"   # 外部からは28789でアクセス

その後、dashboardとwebhook URLも新しいportに変更する必要があります。

curl http://localhost:28789/health

右側の 18789（コンテナ内部port）は変更しないでください。変更する場合は ~/.duduclaw/config.toml の [gateway] port も同期して変更する必要があり、 entrypointは --yes で自動生成しているため、メンテナンスコストが上がります。

5.3 ローカルのみにbind（LANへの露出を避ける）

デフォルトの ports: "18789:18789" は 0.0.0.0 にbindされるため、同一ネットワーク内の他のマシンからも接続できます。ローカル専用にしたい場合（リバースプロキシと組み合わせる場合など）：

    ports:
      - "127.0.0.1:18789:18789"

5.4 同一マシンでの複数インスタンス

同じマシンで2つのDuDuClawを動かす場合：

# ディレクトリA — 本番
cd /srv/duduclaw-prod
# ports: "18789:18789"
docker compose up -d

# ディレクトリB — ステージング
cd /srv/duduclaw-staging
# ports: "28789:18789"
# container_nameも変更し、衝突を避ける
docker compose up -d

container_name（デフォルト duduclaw-server）も忘れずに変更し、名前の衝突を避けてください。

6. CLI の認証設定

イメージには Claude、Codex、Antigravity、Grok が含まれます。ログイン方法は CLI ごとに異なります。Codex はデバイスコードを使うため、ブラウザからコンテナ内のコールバックリスナーに接続する必要はありません。課金と予備のために API キーも用意してください。

標準の Compose ファイルは以下の認証情報・設定ディレクトリをマウントします。

パス	Volume	CLI
`/home/duduclaw/.claude`	`duduclaw-claude`	Claude Code
`/home/duduclaw/.codex`	`duduclaw-codex`	Codex
`/home/duduclaw/.gemini`	`duduclaw-gemini`	Antigravity 設定
`/home/duduclaw/.grok`	`duduclaw-grok`	Grok
`/home/duduclaw/.kimi-code`	`duduclaw-kimi`	Kimi Code
`/home/duduclaw/.copilot`	`duduclaw-copilot`	GitHub Copilot CLI
`/home/duduclaw/.kiro`	`duduclaw-kiro`	Kiro CLI
`/home/duduclaw/.cursor`	`duduclaw-cursor`	Cursor CLI
`/home/duduclaw/.local/share/opencode`	`duduclaw-opencode`	OpenCode

つまり、一度ログインすればコンテナを再構築してもログインし直す必要はありません。

サブスクリプションでのログインにはアカウントのリスクがあります。 Anthropic の法務・コンプライアンスページには、サードパーティの開発者が自社アプリで Claude.ai ログインを提供すること、Free・Pro・Max プランの認証情報でユーザーの代わりにリクエストを中継すること、Claude.ai の認証情報やセッショントークンを収集・保存・仲介することは認められないと書かれています。Anthropic は事前の通知なく執行できるとしており、アカウント停止の報告もあります。1 つのサブスクリプションでチャネルの顧客に返信すること、複数のサブスクリプションをローテーションして利用上限を避けること、トークンを DuDuClaw に保存することは、いずれもこの規約と衝突します。Google の Antigravity 規約には、サードパーティのソフトウェアから Antigravity の OAuth を使ってサービスにアクセスすることは規約違反で、アカウントの停止または終了の理由になり得ると書かれています。OpenAI には公式の Sign in with ChatGPT プログラムがあり、サードパーティのアプリで ChatGPT プランを使えるのはオープンソースのパートナーと選ばれた商用パートナーで、商用製品には OpenAI の承認が必要です。認証トークンはユーザーが管理するローカル環境に置き、リモートやマネージド環境には置かないこととされています。以下の setup token、コンテナ内の対話ログイン、ChatGPT ログインはいずれもサブスクリプションのログインで、引き続き使えますが、API キーの利用を推奨します。ダッシュボードのログインフローでは、先にこの説明への同意を求めます。features/13-multi-runtime.md を参照してください。

6.1 Claude Code CLI

方法A：Setup Token（ブラウザ不要）

Claude Codeは自動化シナリオ向けに、ブラウザのコールバックを必要としない長期有効tokenを提供しており、コンテナ / CI / headless serverに適しています。

# ブラウザのある自分のマシンで実行する（コンテナ内ではない）
npm install -g @anthropic-ai/claude-code
claude setup-token
# 画面の指示に従いブラウザでOAuthを完了する
# 最後に CLAUDE_CODE_OAUTH_TOKEN=sk-ant-oat01-... が表示される

生成されたtokenを .env に書き込みます。

CLAUDE_CODE_OAUTH_TOKEN=sk-ant-oat01-xxxxxxxx...

そして：

docker compose up -d

DuDuClawは起動時に環境変数を読み込み、claude CLIがこのtokenを認識して自動的にログインします。コンテナ内で何か操作する必要はありません。Tokenの有効期限は30日で、期限の7日前からDuDuClawがdashboardに警告を表示します。

方法B：コンテナ内でのインタラクティブログイン

Pro / Team / Maxのサブスクリプションがあり、そのquotaを使いたい場合：

# コンテナに入る
docker compose exec duduclaw bash

# コンテナ内で実行
claude auth login
# URLが表示されるので、ローカルのブラウザで開いて認可を完了する
# 状態は /home/duduclaw/.claude/ に書き込まれる（duduclaw-claude volume）

# 確認
claude auth status
exit

volumeに保存されているため、コンテナを再起動しても状態は保持されます。

方法C：APIキーFallback

.env：

ANTHROPIC_API_KEY=sk-ant-...

この経路は従量課金で、サブスクリプションを使い切ったりアカウントがrate-limitされたりした場合の保険として適しています。 DuDuClawのAccountRotatorが複数アカウント間で自動的にローテーションします。詳細は features/07-account-rotation.mdを参照してください。

6.2 Codex（OpenAI）CLI

方法A：ChatGPT Plus/Pro OAuth

docker compose exec duduclaw bash
codex login --device-auth
# Codex が表示する認証ページをブラウザで開き、デバイスコードを入力する。
# CLI の完了表示を待つ。コールバック URL をダッシュボードに貼り付ける必要はない。
# 状態は /home/duduclaw/.codex/ に書き込まれる（duduclaw-codex volume）
exit

この方法はChatGPTのサブスクリプションquotaを使用し、追加のAPI費用は発生しません。トークンはコンテナの volume に保存されます。OpenAI の Sign in with ChatGPT 規約では、認証トークンを永続的に保存する場合はユーザーが管理するローカル環境に限り、リモートやマネージド環境には置かないこととされているため、サーバーでは方法Bを優先してください（features/13-multi-runtime.md を参照）。

方法B：APIキーFallback

.env：

OPENAI_API_KEY=sk-proj-...

従量課金（OpenAI APIの料金体系）です。

6.3 Antigravity（Google）の API キーモード

Docker イメージに Gemini CLI は含まれなくなりました。Antigravity（agy）と Gemini API プロバイダーは引き続きサポートします。agy のサブスクリプションサインインには OS キーリングが必要です。コンテナでは config.toml [antigravity] auth = "api_key" を設定し、gemini プロバイダーアカウントまたは .env の GEMINI_API_KEY を使ってください。 Antigravity の設定は ~/.gemini/antigravity-cli/ にあるため、 duduclaw-gemini volume は残します。

6.4 Agent単位でのRuntime指定

各agentは自身の agent.toml で使用するruntimeを指定できます。

[runtime]
provider = "claude"       # メインruntime：claude / codex / antigravity / openai-compat …
fallback = "antigravity"  # Claudeが利用不可の際に自動切り替え

完全な例とfailover戦略については features/13-multi-runtime.mdを参照してください。

provider を指定しない場合、エージェントは Claude で動作します。

6.5 インストール済み CLI の確認

docker compose exec duduclaw bash

# インストール済み CLI のバージョンを表示
claude --version
codex --version

# Claudeのログイン状態
claude auth status

7. データ永続化（Volumes）

docker-compose.yml は 10 個の named volume を宣言しています。

Volume	内容	バックアップの推奨度
`duduclaw-data`	メインデータ：config、agents、memory SQLite、logs、bus_queue.jsonl	最重要。毎日バックアップ推奨
`duduclaw-claude`	Claude CLI OAuth状態	中程度。失っても `claude auth login` をやり直せばよい
`duduclaw-codex`	Codex OAuth状態	中程度
`duduclaw-gemini`	Antigravity の `~/.gemini` 設定	中程度
`duduclaw-grok`	Grok CLI の認証情報	中程度
`duduclaw-kimi`	Kimi Code の認証情報	中程度
`duduclaw-copilot`	Copilot CLI の認証情報	中程度
`duduclaw-kiro`	Kiro CLI の認証情報	中程度
`duduclaw-cursor`	Cursor CLI の認証情報	中程度
`duduclaw-opencode`	OpenCode の認証情報	中程度

さらにホスト側からマウントするパスがあります。

パス	用途	必要性
`/var/run/docker.sock`	コンテナがホストの Docker daemon を呼び出すために使用	エージェント単位のタスクサンドボックスでのみ使用（デフォルトはオフ）。gateway 自体がコンテナ内で動く場合のタスクサンドボックスは task-sandbox.md の対象外で、検証もされていません

7.1 バックアップ

# メインデータをtar.gzにバックアップ
docker run --rm \
  -v duduclaw_duduclaw-data:/source:ro \
  -v $(pwd):/backup \
  alpine tar czf /backup/duduclaw-data-$(date +%F).tar.gz -C /source .

7.2 復元 / 移行

バックアップをターゲットマシンに配置し、同名のvolumeに復元します。

docker volume create duduclaw_duduclaw-data
docker run --rm \
  -v duduclaw_duduclaw-data:/target \
  -v $(pwd):/backup \
  alpine tar xzf /backup/duduclaw-data-2026-04-22.tar.gz -C /target

7.3 ホストディレクトリで置き換える（上級者向け）

データを直接ブラウズしたい場合は、named volumeをbind mountに置き換えられます。

    volumes:
      - ./data/duduclaw:/home/duduclaw/.duduclaw
      - ./data/claude:/home/duduclaw/.claude
      - ./data/codex:/home/duduclaw/.codex
      - ./data/gemini:/home/duduclaw/.gemini
      - ./data/grok:/home/duduclaw/.grok
      - ./data/kimi:/home/duduclaw/.kimi-code
      - ./data/copilot:/home/duduclaw/.copilot
      - ./data/kiro:/home/duduclaw/.kiro
      - ./data/cursor:/home/duduclaw/.cursor
      - ./data/opencode:/home/duduclaw/.local/share/opencode
      - /var/run/docker.sock:/var/run/docker.sock

ホスト側ディレクトリのownerはUID 1000でなければならない点に注意してください（コンテナ内の duduclaw ユーザー）。

mkdir -p data/{duduclaw,claude,codex,gemini,grok,kimi,copilot,kiro,cursor,opencode}
sudo chown -R 1000:1000 data/

8. ヘルスチェックと可観測性

8.1 3つのhealth endpoint

パス	用途	HTTP 200の条件
`/health`	完全な状態（JSON）	常に200と構造化された内容を返す
`/health/ready`	Readiness probe	agentsがすべてロード済み
`/health/live`	Liveness probe	processがまだ生きている

Composeはデフォルトで /health をhealthcheckに使用します（30秒ごと、3回連続失敗でunhealthyと判定）。

8.2 状態の確認

# Containerの状態
docker compose ps

# リアルタイムlog
docker compose logs -f duduclaw

# 直近100行
docker compose logs --tail=100 duduclaw

# Healthcheckの履歴
docker inspect duduclaw-server --format '{{json .State.Health}}' | jq

8.3 Prometheus Metrics

Gatewayは GET /metrics エンドポイントを提供しています。指標一覧は docs/deployment-guide.md §8を参照してください。

9. Watchtowerによる自動更新

docker-compose.yml にはWatchtowerサービスが組み込まれており、1時間ごとにイメージの更新を確認します。

注意：現在のcomposeファイルの WATCHTOWER_SCOPE=duduclaw 設定は 対応するlabelを持つコンテナのみを更新対象としますが、duduclaw サービス自体にはそのlabelが設定されていません。自動更新を有効にするには、services.duduclaw に以下を追加してください。
    labels:
      - "com.centurylinklabs.watchtower.scope=duduclaw"
または WATCHTOWER_SCOPE を削除してください（すべてのコンテナが更新対象になり、範囲が広がります）。

自動更新を望まない場合は、watchtowerサービスのブロックをそのまま削除してください。

10. Channel Webhookには公開HTTPSが必要

LINE / WhatsApp / Feishu など webhook を使うチャネルはいずれもインターネットからアクセス可能なHTTPS URL がなければメッセージを受信できません。DuDuClawが家庭用ネットワークやグローバルIPのないサーバーで動作している場合、よく使われる方法は以下の通りです。

方法	適したシーン	コスト	ガイド
Tailscale Funnel	家庭 / 開発 / 一時的な利用	無料	§11
Cloudflare Tunnel	長期的な本番運用	無料（独自ドメインが必要）	deployment-guide §4
ngrok	クイックデモ	無料版はURLが変わる	deployment-guide §3
リバースプロキシ（Caddy / Nginx）	独自のグローバルIP＋ドメイン	自前でメンテナンスが必要	deployment-guide §5

11. Tailscale Funnel（公開HTTPSをWebhookに提供）

Composeには既にTailscaleサービスが同梱されていますが、デフォルトでは tailscale profile配下にあり自動起動しません。

11.1 有効化

# 1. Tailscale admin consoleでauth keyを生成する
#    https://login.tailscale.com/admin/settings/keys
#    "Reusable" + "Ephemeral" にチェックすることを推奨

# 2. .envに書き込む
echo "TS_AUTHKEY=tskey-auth-xxxxxxx" >> .env

# 3. tailscale profileを起動
docker compose --profile tailscale up -d

# 4. Tailscale admin consoleでこのマシンのFunnelを有効化
#    Machines → duduclaw → Enable Funnel

# 5. https URLを取得
docker compose exec tailscale tailscale funnel status
# https://duduclaw.your-tailnet.ts.net/  ← これがwebhookのprefixになる

LINE webhook URLには https://duduclaw.your-tailnet.ts.net/webhook/line を設定します。

Tailscaleコンテナは現在 image: tailscale/tailscale:latest を使用しています。本番環境では特定のdigestにpinすることを推奨します（composeファイルに既にTODOとして記載済みです）。

12. よく使うコマンド早見表

# 起動 / 停止 / 再起動
docker compose up -d
docker compose down           # container停止＋削除（volumeは削除されない）
docker compose restart duduclaw

# イメージの再ビルド（コードやDockerfileの変更後）
docker compose build --no-cache duduclaw
docker compose up -d

# コンテナshellに入る
docker compose exec duduclaw bash

# 単発コマンドの実行
docker compose exec duduclaw duduclaw agent list
docker compose exec duduclaw duduclaw doctor

# Log
docker compose logs -f duduclaw
docker compose logs --since 1h duduclaw

# クリーンアップ
docker compose down -v        # ⚠️ volumeも一緒に削除される。データは全て失われる
docker system prune -af       # ⚠️ 未使用のimage / containerをすべて削除する

13. トラブルシューティング

Containerは起動しているが `curl localhost:18789/health` がConnection refusedを返す

原因：Gatewayがコンテナ内部のlocalhostにbindされており、ホストから到達できません。 確認方法：

docker compose exec duduclaw env | grep DUDUCLAW_BIND
# DUDUCLAW_BIND=0.0.0.0 になっているはず

もし空文字列であれば、composeファイルの environment: ブロックに追加してください。

`docker compose up` が `Compiling duduclaw-gateway` で止まる

Rustのコンパイルは CPU/RAM を多く消費し、一般的なノートPCでの初回ビルドは10〜20分ほどかかります。以降の変更はincremental cacheが効くため、通常1〜2分程度です。

メモリが不足している（4 GB未満）とOOM killedになる可能性があります。以下を検討してください。

pre-buildイメージが提供されていればそれを使用する
またはホスト側で事前に cargo build --release を実行してバイナリを作り、Dockerfileを書き換えて直接COPYする（上級者向け）

Claude CLIが “not logged in” と表示される

確認の順序：

# 1. Env varが渡っているか
docker compose exec duduclaw env | grep -E "CLAUDE_CODE_OAUTH_TOKEN|ANTHROPIC_API_KEY"

# 2. Volumeが正しくマウントされているか
docker compose exec duduclaw ls -la ~/.claude/

# 3. CLI自体には何が見えているか
docker compose exec duduclaw claude auth status

よくある間違いは、.env を編集した後に docker compose up -d で container を再起動するのを忘れることです。 env varは起動時にのみ注入されるため、ホット変更は反映されません。

ステップ3はトークンが実際に機能していることを証明しません。 claude auth status は CLAUDE_CODE_OAUTH_TOKEN 環境変数が存在しさえすれば loggedIn: true を報告します——そのトークンが依然として認証できるかは一切チェックしません。失効または組織で無効化されたトークンも、良好なトークンと同じようにこのチェックを通過します。認証情報が実際に機能しているか確認するには、ダッシュボードのAccountsページでそのアカウントの認証情報ステータスバッジを確認するか（未確認／認証情報が破損／トークン無効／組織で無効化——ヘルシーなアカウントは何も表示しません）、 container内で実際にプローブを実行してください：
ターミナルウィンドウ
docker compose exec duduclaw claude -p "reply ok" --model haiku --max-turns 1 --output-format json
JSON出力の is_error / api_error_status フィールドを確認します。

Dashboardには接続できるがagentが「まず `claude auth status` を実行してください」と返信する

これはv1.8.x以前のバージョンの残存メッセージです。v1.8.22以降は FailureReason で分類されたzh-TWメッセージに変更されています。まだ表示される場合は：

docker compose exec duduclaw duduclaw --version
# 1.8.22以上であることを確認。そうでなければ最新のmainをpullして再buildする

Dashboardがくるくる回り続ける、WebSocket 403

症状：tailnet（*.ts.net）またはリバースプロキシのドメイン経由でdashboardを開くとHTTPページ自体は正常に読み込まれるが、リアルタイムデータがくるくる回り続ける。ブラウザDevToolsのNetworkパネルでは /ws のアップグレードが403を返している。

原因：WebSocketの Origin allowlistはデフォルトでloopbackのみを含んでおり、外部ドメインが含まれていません。allowlistに追加すれば解決します。

# composeのenvironment:、または.env
DUDUCLAW_ALLOWED_ORIGINS=duduclaw.your-tailnet.ts.net,duduclaw.yourdomain.com

または ~/.duduclaw/config.toml に記述します。

[gateway]
allowed_origins = ["duduclaw.your-tailnet.ts.net"]

再起動後、起動ログに有効になった追加originsが出力されます。詳細は deployment-guide §5 WebSocket Origin 許可リストを参照してください。

Channel webhookがagentをトリガーしない

LINE / WhatsApp / FeishuはHTTPSが必要です。§10の設定を確認してください
Dashboard → Channelsで該当channelの接続状態インジケーターを確認してください
logを確認する：docker compose logs -f duduclaw | grep -i webhook

タスクサンドボックスが起動しない

これは agent.toml [container] sandbox_enabled = true のエージェントにのみ当てはまります。gateway 自体がコンテナ内で動く場合のタスクサンドボックスは対象外で、検証もされていません。サンドボックスイメージは、ソケットが指す Docker daemon 上に存在している必要があり、自動ダウンロードはされません（task-sandbox.md を参照）。以下のコンテナ側の手順は、ソケットが使えるかどうかだけを確認します。

# コンテナ内からsocketが使えるかテストする
docker compose exec duduclaw docker ps
# ホスト上のcontainer一覧が見えるはず

Permission deniedになる場合、多くはSELinux / AppArmorがブロックしています。Linuxでは以下を試してください。

    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:rw
    group_add:
      - "${DOCKER_GID:-999}"   # ホストのdocker group GIDに合わせる

コンテナ再構築後にOAuth状態が消える

volumeが実際に存在するか確認してください。

docker volume ls | grep duduclaw
# duduclaw_duduclaw-data
# duduclaw_duduclaw-claude
# duduclaw_duduclaw-codex
# duduclaw_duduclaw-gemini

もしどれかが欠けていれば、composeファイルが変更されたか、過去に docker compose down -v が実行されたことを意味します。 claude auth login / codex login --device-auth を再度実行してください。

14. 関連ドキュメント

デプロイ方式の概要：docs/deployment-guide.md
Multi-Runtimeアーキテクチャ：docs/features/13-multi-runtime.md
Account Rotation：docs/features/07-account-rotation.md
開発ガイド：docs/development-guide.md