メインコンテンツへスキップ
Quick answers と、実際の環境（ローカル開発、VPS、マルチエージェント、OAuth/API キー、モデルフェイルオーバー）向けのより深いトラブルシューティング。ランタイム診断については、トラブルシューティングを参照してください。完全な設定リファレンスについては、設定を参照してください。

​
何かが壊れている場合の最初の 60 秒

1

クイックステータス

openclaw status
高速なローカル概要: OS + 更新、gateway/サービスの到達性、エージェント/セッション、プロバイダー設定 + ランタイムの問題（gateway に到達できる場合）。
2

貼り付け可能なレポート（共有しても安全）

openclaw status --all
ログ末尾付きの読み取り専用診断（トークンは伏せ字）。
3

デーモン + ポート状態

openclaw gateway status
スーパーバイザーのランタイムと RPC 到達性、プローブ対象 URL、サービスが使用した可能性が高い設定を表示します。
4

詳細プローブ

openclaw status --deep
対応している場合はチャネルプローブを含む、ライブ Gateway ヘルスプローブ（到達可能な Gateway が必要）。ヘルスを参照してください。
5

最新ログを追尾

openclaw logs --follow
RPC が停止している場合は、次にフォールバックします:
tail -f "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"
ファイルログはサービスログとは別です。ログとトラブルシューティングを参照してください。
6

doctor を実行（修復）

openclaw doctor
設定と状態を修復/移行し、その後ヘルスチェックを実行します。Doctorを参照してください。
7

Gateway スナップショット（WS のみ）

openclaw health --json
openclaw health --verbose   # エラー時に対象 URL + 設定パスを表示
実行中の gateway に完全なスナップショットを要求します。ヘルスを参照してください。

​
クイックスタートと初回セットアップ

初回実行 Q&A（インストール、オンボーディング、認証ルート、サブスクリプション、初期障害）は、初回 FAQにあります。

​
OpenClaw とは何ですか？

OpenClaw は、自分のデバイス上で動かす個人用 AI アシスタントです。すでに使っているメッセージング面（Discord、Google Chat、iMessage、Mattermost、Signal、Slack、Telegram、WebChat、WhatsApp、QQ Bot などの同梱チャネル Plugin）で返信でき、対応プラットフォームでは音声とライブ Canvas も使えます。Gateway は常時稼働の制御プレーンであり、アシスタントがプロダクトです。
OpenClaw は「単なる Claude ラッパー」ではありません。これは ローカルファーストの制御プレーン であり、自分のハードウェア 上で高機能なアシスタントを動かし、すでに使っているチャットアプリからアクセスできます。ステートフルなセッション、メモリ、ツールを備え、ワークフローをホスト型 SaaS に渡す必要はありません。
  • 自分のデバイス、自分のデータ: Gateway を任意の場所（Mac、Linux、VPS）で実行し、ワークスペースとセッション履歴をローカルに保持します。
  • Web サンドボックスではなく実際のチャネル: Discord/iMessage/Signal/Slack/Telegram/WhatsApp/などに加え、対応プラットフォームではモバイル音声と Canvas。
  • モデル非依存: Anthropic、MiniMax、OpenAI、OpenRouter などを、エージェントごとのルーティングとフェイルオーバーで使用できます。
  • ローカルのみの選択肢: ローカルモデルを実行すれば、すべてのデータを自分のデバイス上に留められます。
  • マルチエージェントルーティング: チャネル、アカウント、タスクごとにエージェントを分け、それぞれに独自のワークスペースとデフォルトを持たせられます。
  • オープンソースで改造可能: ベンダーロックインなしで、調査、拡張、セルフホストできます。
ドキュメント: Gateway, チャネル, マルチエージェント, メモリ。
最初のプロジェクトに適しているもの: Web サイトの構築（WordPress、Shopify、または静的サイト）、モバイルアプリのプロトタイプ作成（概要、画面、API 計画）、ファイルとフォルダーの整理、Gmail の接続と要約やフォローアップの自動化。大きなタスクも処理できますが、並列作業にはサブエージェントを使い、フェーズに分けると最も効果的です。
  • 個人向けブリーフィング: 受信箱、カレンダー、関心のあるニュースの要約。
  • リサーチと下書き: メールやドキュメント向けの簡単なリサーチ、要約、初稿。
  • リマインダーとフォローアップ: cron または heartbeat 駆動の通知やチェックリスト。
  • ブラウザー自動化: フォーム入力、データ収集、Web タスクの反復。
  • デバイス横断の連携: スマートフォンからタスクを送り、Gateway にサーバー上で実行させ、結果をチャットで受け取ります。
はい、リサーチ、絞り込み、下書きに役立ちます。サイトのスキャン、候補リストの作成、見込み客の要約、アウトリーチ文や広告コピーの下書き作成などです。アウトリーチや広告配信では、人間をループに入れてください。スパムを避け、地域の法律やプラットフォームポリシーに従い、送信前に必ずレビューしてください。OpenClaw に下書きさせ、あなたが承認します。ドキュメント: セキュリティ。
OpenClaw は 個人用アシスタント 兼調整レイヤーであり、IDE の代替ではありません。リポジトリ内で最速の直接コーディングループを行うには Claude Code または Codex を使用してください。OpenClaw は、永続メモリ、デバイス横断アクセス、ツールオーケストレーションに使用します。
  • セッションをまたいだ永続メモリとワークスペース。
  • 複数プラットフォームからのアクセス（Telegram、WhatsApp、TUI、WebChat）。
  • ツールオーケストレーション（ブラウザー、ファイル、スケジューリング、フック）。
  • 常時稼働の Gateway（VPS 上で実行し、どこからでも操作）。
  • ローカルのブラウザー/画面/カメラ/exec 用 Node。
ショーケース: https://openclaw.ai/showcase。

​
Skills と自動化

リポジトリのコピーを編集する代わりに、管理されたオーバーライドを使用します。変更を ~/.openclaw/skills/<name>/SKILL.md に置きます（または ~/.openclaw/openclaw.json の skills.load.extraDirs でフォルダーを追加します）。優先順位: <workspace>/skills -> <workspace>/.agents/skills -> ~/.agents/skills -> ~/.openclaw/skills -> bundled -> skills.load.extraDirs なので、管理されたオーバーライドは git に触れずに bundled skills より優先されます。グローバルにインストールしつつ一部のエージェントにだけ表示を制限するには、共有コピーを ~/.openclaw/skills に置き、agents.defaults.skills / agents.list[].skills で表示を制御します。上流に取り込む価値がある編集だけを、リポジトリコピーに対する PR として出してください。
はい: ~/.openclaw/openclaw.json の skills.load.extraDirs でディレクトリを追加します（上記の順序では最も低い優先順位）。clawhub はデフォルトで ./skills にインストールし、OpenClaw は次のセッションでこれを <workspace>/skills として扱います。可視性を特定のエージェントに限定するには、agents.defaults.skills または agents.list[].skills と組み合わせます。
サポートされているパターン:
  • Cron ジョブ: 分離されたジョブでは、ジョブごとに model オーバーライドを設定できます。
  • エージェント: タスクを、異なるデフォルトモデル、思考レベル、ストリームパラメータを持つ別々のエージェントにルーティングします。
  • オンデマンド切り替え: /model で現在のセッションモデルをいつでも切り替えられます。
例 - 同じモデル、エージェントごとに異なる設定:
{
  agents: {
    list: [
      {
        id: "coder",
        model: "xiaomi/mimo-v2.5-pro",
        thinkingDefault: "high",
        params: { temperature: 0.1 },
      },
      {
        id: "chat",
        model: "xiaomi/mimo-v2.5-pro",
        thinkingDefault: "off",
        params: { temperature: 0.8 },
      },
    ],
  },
}
共有のモデル別デフォルトは agents.defaults.models["provider/model"].params に置き、エージェント固有のオーバーライドはフラットな agents.list[].params に置きます。同じモデルをネストされた agents.list[].models["provider/model"].params の下に重複させないでください。このパスは、エージェントごとのモデルカタログとランタイムオーバーライド用です。参照: Cron ジョブ, マルチエージェントルーティング, 設定, スラッシュコマンド。
長時間または並列のタスクには サブエージェント を使用します。サブエージェントは独自のセッションで実行され、要約を返し、メインのチャットの応答性を保ちます。ボットに「このタスク用にサブエージェントを生成して」と依頼するか、/subagents を使用します。Gateway が現在ビジーかどうかを確認するには /status を使用します。長いタスクとサブエージェントはいずれもトークンを消費します。コストが重要な場合は、agents.defaults.subagents.model でサブエージェントにより安価なモデルを設定します。ドキュメント: サブエージェント, バックグラウンドタスク。
Discord スレッドをサブエージェントまたはセッションターゲットに紐づけると、その後のメッセージはその紐づけられたセッションに留まります。
  • thread: true を指定して sessions_spawn で生成します（永続的な後続対応には任意で mode: "session"）。
  • または /focus <target> で手動で紐づけます。
  • /agents は紐づけ状態を検査します。
  • /session idle <duration|off> と /session max-age <duration|off> は自動フォーカス解除を制御します。
  • /unfocus はスレッドの紐づけを解除します。
設定: session.threadBindings.enabled（グローバルスイッチ）、session.threadBindings.idleHours（デフォルト 24、0 で無効）、session.threadBindings.maxAgeHours（デフォルト 0 = ハード上限なし）、およびチャンネルごとのオーバーライド channels.discord.threadBindings.{enabled,idleHours,maxAgeHours}。channels.discord.threadBindings.spawnSessions は生成時の自動紐づけを制御します（デフォルト true）。ドキュメント: サブエージェント, Discord, 設定リファレンス, スラッシュコマンド。
解決されたリクエスターのルートを確認します。
  • 完了モードのサブエージェント配信は、紐づけられたスレッドまたは会話ルートが存在する場合、それを優先します。
  • 完了の起点がチャンネルしか保持していない場合、OpenClaw はリクエスターセッションの保存済みルート（lastChannel / lastTo / lastAccountId）にフォールバックするため、ダイレクト配信は引き続き成功できます。
  • 紐づけられたルートがなく、使用可能な保存済みルートもない場合: ダイレクト配信は失敗する可能性があり、結果は即時投稿ではなくキューに入れられたセッション配信にフォールバックします。
  • 無効または古いターゲットも、キューフォールバックまたは最終配信失敗を強制することがあります。
  • 子の最後の表示済みアシスタント返信が正確に NO_REPLY / no_reply または ANNOUNCE_SKIP の場合、OpenClaw は古い進捗を投稿する代わりに、意図的に通知を抑制します。
デバッグ: <lookup> がタスク ID、実行 ID、またはセッションキーである場合の openclaw tasks show <lookup>。ドキュメント: サブエージェント, バックグラウンドタスク, セッションツール。
Cron は Gateway プロセス内で実行されます。Gateway が継続的に実行されていない場合は発火しません。
  • cron が有効（cron.enabled）で、OPENCLAW_SKIP_CRON が設定されていないことを確認します。
  • Gateway が 24 時間 365 日実行されていることを確認します（スリープや再起動がない）。
  • ジョブのタイムゾーン（--tz とホストタイムゾーン）を確認します。
デバッグ:
openclaw cron run <jobId>
openclaw cron runs --id <jobId> --limit 50
ドキュメント: Cron ジョブ, 自動化。
配信モードを確認してください。
  • --no-deliver / delivery.mode: "none": ランナーのフォールバック送信は想定されません。
  • 通知先（channel / to）がない、または無効: ランナーは外向き配信をスキップしました。
  • チャンネル認証エラー（unauthorized、Forbidden）: ランナーは配信を試みましたが、認証情報によりブロックされました。
  • サイレントな分離結果（NO_REPLY / no_reply のみ）は意図的に配信不可として扱われるため、キューに入ったフォールバック配信も抑制されます。
分離 Cron ジョブでは、チャットルートが利用可能な場合、エージェントは引き続き message ツールで直接送信できます。--announce は、エージェントがまだ自分で送信していない最終テキストに対するランナーのフォールバック配信だけを制御します。デバッグ:
openclaw cron runs --id <jobId> --limit 50
openclaw tasks show <lookup>
ドキュメント: Cron ジョブ、バックグラウンドタスク。
これはライブモデル切り替えパスであり、重複スケジューリングではありません。分離 Cron はランタイムモデルの引き継ぎを永続化し、アクティブな実行が LiveSessionModelSwitchError を投げた場合に、切り替え後のプロバイダー/モデル（および切り替え後の認証プロファイルオーバーライド）を保持してからリトライします。モデル選択の優先順位: Gmail フックのモデルオーバーライド（hooks.gmail.model）が最初、次にジョブ単位の model、次に保存済みの Cron セッションモデルオーバーライド、その後に通常のエージェント/デフォルトモデル選択です。リトライループは初回試行に加えて 2 回の切り替えリトライまでに制限されています。その後 Cron は永久にループせず中止します。デバッグ:
openclaw cron runs --id <jobId> --limit 50
ドキュメント: Cron ジョブ、Cron CLI。
ネイティブの openclaw skills コマンドを使うか、ワークスペースに Skills を配置してください。macOS の Skills UI は Linux では利用できません。Skills は https://clawhub.ai で参照できます。
openclaw skills search "calendar"
openclaw skills search --limit 20
openclaw skills install @owner/<skill-slug>
openclaw skills install @owner/<skill-slug> --version <version>
openclaw skills install @owner/<skill-slug> --force
openclaw skills install @owner/<skill-slug> --global
openclaw skills update --all
openclaw skills update --all --global
openclaw skills list --eligible
openclaw skills check
ネイティブの openclaw skills install は、デフォルトでアクティブなワークスペースの skills/ ディレクトリに書き込みます。すべてのローカルエージェント向けの共有管理 Skills ディレクトリにインストールするには、--global を追加します。別個の clawhub CLI は、自分の Skills を公開または同期する場合にのみインストールしてください。共有 Skills を参照できるエージェントを絞るには、agents.defaults.skills または agents.list[].skills を使います。
はい、Gateway スケジューラー経由で可能です。
  • Cron ジョブ: スケジュール済みまたは繰り返しタスク用（再起動後も保持されます）。
  • Heartbeat: メインセッションの定期チェック用。
  • 分離ジョブ: 要約を投稿したりチャットへ配信したりする自律エージェント用。
ドキュメント: Cron ジョブ、自動化、Heartbeat。
直接はできません。macOS Skills は metadata.openclaw.os と必須バイナリによって制限され、Gateway ホストで適格な場合にのみロードされます。Linux では、ゲーティングをオーバーライドしない限り、darwin 専用 Skills（apple-notes、apple-reminders、things-mac）はロードされません。サポートされるパターンは 3 つあります。オプション A - Mac で Gateway を実行する（最も簡単）。macOS バイナリが存在する場所で Gateway を実行し、Linux からリモートモードまたは Tailscale 経由で接続します。Gateway ホストが macOS なので、Skills は通常どおりロードされます。オプション B - macOS Node を使う（SSH なし）。Linux で Gateway を実行し、macOS Node（メニューバーアプリ）をペアリングし、Mac で Node Run Commands を「Always Ask」または「Always Allow」に設定します。必須バイナリが Node 上に存在する場合、OpenClaw は macOS 専用 Skills を適格として扱います。エージェントは nodes ツール経由でそれらを実行します。「Always Ask」で、プロンプト内の「Always Allow」を承認すると、そのコマンドが許可リストに追加されます。オプション C - SSH 経由で macOS バイナリをプロキシする（上級者向け）。Gateway は Linux のままにし、必須 CLI バイナリが Mac 上で実行される SSH ラッパーに解決されるようにしてから、その Skill を Linux 許可にオーバーライドし、適格な状態を維持します。
  1. バイナリ用の SSH ラッパーを作成します（例: Apple Notes 用の memo）。 
    #!/usr/bin/env bash
set -euo pipefail
exec ssh -T user@mac-host /opt/homebrew/bin/memo "$@"
  2. Linux ホスト上の PATH にラッパーを置きます（例: ~/bin/memo）。
  3. Skill メタデータ（ワークスペースまたは ~/.openclaw/skills）をオーバーライドして Linux を許可します。 
    ---
name: apple-notes
description: Manage Apple Notes via the memo CLI on macOS.
metadata: { "openclaw": { "os": ["darwin", "linux"], "requires": { "bins": ["memo"] } } }
---
  4. Skills スナップショットが更新されるように、新しいセッションを開始します。
現時点では組み込まれていません。選択肢は次のとおりです。
  • カスタム Skill / Plugin: 信頼性の高い API アクセスに最適です（どちらも API があります）。
  • ブラウザー自動化: コードなしで動作しますが、遅く、壊れやすくなります。
代理店型のクライアント別コンテキストでは、クライアントごとに Notion ページを 1 つ（コンテキスト + 設定 + 進行中の作業）用意し、セッション開始時にそのページを取得するようエージェントに依頼します。ネイティブ連携が必要な場合は、機能リクエストを作成するか、それらの API に対する Skill を構築してください。
openclaw skills install @owner/<skill-slug>
openclaw skills update --all
ネイティブインストールはアクティブなワークスペースの skills/ ディレクトリに配置されます。すべてのローカルエージェント向けには --global を使うか、可視性を制限するために agents.defaults.skills / agents.list[].skills を設定してください。一部の Skills は Homebrew でインストールされたバイナリを期待します。Linux では Linuxbrew を意味します。Skills、Skills 設定、ClawHub を参照してください。
Chrome DevTools MCP 経由で接続する組み込みの user ブラウザープロファイルを使います。
openclaw browser --browser-profile user tabs
openclaw browser --browser-profile user snapshot
カスタム名の場合は、明示的な MCP プロファイルを作成します。
openclaw browser create-profile --name chrome-live --driver existing-session
openclaw browser --browser-profile chrome-live tabs
これはローカルホストのブラウザーまたは接続済みブラウザー Node を使用できます。Gateway が別の場所で実行されている場合は、ブラウザーマシンで Node ホストを実行するか、代わりにリモート CDP を使います。existing-session / user プロファイルと管理対象の openclaw プロファイルとの現在の制限は次のとおりです。
  • click、type、hover、scrollIntoView、drag、select には CSS セレクターではなくスナップショット参照が必要です。
  • アップロードフックには ref または inputRef が必要で、1 回に 1 ファイルのみ、CSS element は使えません。
  • responsebody、PDF エクスポート、ダウンロードインターセプト、バッチアクションには、引き続き管理対象ブラウザーパスが必要です。
完全な比較については ブラウザー を参照してください。

​
サンドボックス化とメモリ

はい: サンドボックス化。Docker 固有のセットアップ（Docker 内のフル Gateway またはサンドボックスイメージ）については、Docker を参照してください。
デフォルトイメージはセキュリティ優先で node ユーザーとして実行されるため、システムパッケージ、Homebrew、同梱ブラウザーは含まれません。より完全なセットアップにするには:
  • キャッシュが残るように、OPENCLAW_HOME_VOLUME で /home/node を永続化します。
  • OPENCLAW_IMAGE_APT_PACKAGES でシステム依存関係をイメージに組み込みます。
  • 同梱 CLI 経由で Playwright ブラウザーをインストールします: node /app/node_modules/playwright-core/cli.js install chromium。
  • PLAYWRIGHT_BROWSERS_PATH を設定し、そのパスを永続化します。
ドキュメント: Docker、ブラウザー。
はい、プライベートトラフィックが DM で、公開トラフィックが グループ の場合は可能です。agents.defaults.sandbox.mode: "non-main" を設定すると、グループ/チャンネルセッション（非メインキー）は設定済みのサンドボックスバックエンドで実行され、メインの DM セッションはホスト上に残ります。サンドボックス化が有効になると、Docker がデフォルトのバックエンドです。サンドボックス化されたセッションで利用できるツールは tools.sandbox.tools で制限します。セットアップ手順: グループ: 個人 DM + 公開グループ。キーリファレンス: Gateway 設定。
agents.defaults.sandbox.docker.binds を ["host:container:mode"]（例: "/home/user/src:/src:ro"）に設定します。グローバルバインドとエージェント単位のバインドはマージされます。scope: "shared" の場合、エージェント単位のバインドは無視されます。機密性の高いものには :ro を使ってください。バインドはサンドボックスのファイルシステム境界を迂回します。OpenClaw は、正規化されたパスと、最も深い既存祖先を通じて解決された正規パスの両方に対してバインド元を検証します。そのため、最終パスセグメントがまだ存在しない場合でも、シンボリックリンク親による脱出はフェイルクローズします。サンドボックス化 と サンドボックス vs ツールポリシー vs 昇格 を参照してください。
OpenClaw のメモリは、エージェントワークスペース内の Markdown ファイルです。日次ノートは memory/YYYY-MM-DD.md、整理された長期ノートは MEMORY.md（メイン/プライベートセッションのみ）にあります。OpenClaw はまた、Compaction が会話を要約する前にサイレントな Compaction 前メモリフラッシュを実行し、モデルに先に永続ノートを書くよう促します。これはワークスペースが書き込み可能な場合にのみ実行されます（読み取り専用サンドボックスではスキップされます）。無効にするには agents.defaults.compaction.memoryFlush.enabled: false を使います。メモリ を参照してください。
ボットにその事実をメモリに書き込むよう依頼してください。長期ノートは MEMORY.md、短期コンテキストは memory/YYYY-MM-DD.md に入ります。モデルにメモリを保存するよう促すと、通常は解決します。それでも忘れ続ける場合は、Gateway が毎回同じワークスペースを使っていることを確認してください。ドキュメント: メモリ、エージェントワークスペース。
メモリファイルはディスク上にあり、削除されるまで保持されます。制限はモデルではなくストレージです。セッションコンテキストは引き続きモデルのコンテキストウィンドウに制限されるため、長い会話は Compaction されたり切り詰められたりすることがあります。そのため、関連する部分だけをコンテキストに戻すメモリ検索が存在します。ドキュメント: メモリ、コンテキスト。
OpenAI embeddings を使う場合のみ必要です。これはデフォルトプロバイダーです。Codex OAuth はチャット/補完を対象とし、embeddings アクセスは付与しません。そのため、Codex（OAuth または Codex CLI ログイン）でサインインしても、セマンティックメモリ検索は有効になりません。OpenAI embeddings には引き続き実際の API キー（OPENAI_API_KEY または models.providers.openai.apiKey）が必要です。ローカルに保つには、agents.defaults.memorySearch.provider: "local" (GGUF/llama.cpp) を設定します。その他の対応プロバイダー: Bedrock、DeepInfra、Gemini (GEMINI_API_KEY または memorySearch.remote.apiKey)、GitHub Copilot、LM Studio、Mistral、Ollama、OpenAI 互換、Voyage。セットアップの詳細は Memory と Memory search を参照してください。

​
ディスク上の配置

いいえ: OpenClaw 自体の状態はローカルですが、外部サービスには送信した内容が引き続き見えます。
  • デフォルトではローカル: セッション、メモリファイル、設定、ワークスペースは Gateway ホスト上にあります (~/.openclaw とワークスペースディレクトリ)。
  • 必要に応じてリモート: モデルプロバイダー (Anthropic/OpenAI など) に送信されるメッセージはそれらの API に送られ、チャットプラットフォーム (Slack/Telegram/WhatsApp など) はメッセージデータをそれぞれのサーバーに保存します。
  • フットプリントは制御できます: ローカルモデルはプロンプトを自分のマシン上に保持しますが、チャネルのトラフィックは引き続きチャネルのサーバーを通過します。
関連: エージェントワークスペース、Memory。
すべては $OPENCLAW_STATE_DIR 配下にあります (デフォルト: ~/.openclaw):
パス目的
$OPENCLAW_STATE_DIR/openclaw.jsonメイン設定 (JSON5)
$OPENCLAW_STATE_DIR/credentials/oauth.jsonレガシー OAuth インポート (初回使用時に認証プロファイルへコピー)
$OPENCLAW_STATE_DIR/agents/<agentId>/agent/auth-profiles.json認証プロファイル (OAuth、API キー、任意の keyRef/tokenRef)
$OPENCLAW_STATE_DIR/secrets.jsonfile SecretRef プロバイダー用の任意のファイルベースのシークレットペイロード
$OPENCLAW_STATE_DIR/agents/<agentId>/agent/auth.jsonレガシー互換ファイル (静的な api_key エントリは除去済み)
$OPENCLAW_STATE_DIR/credentials/プロバイダー状態 (例: whatsapp/<accountId>/creds.json)
$OPENCLAW_STATE_DIR/agents/エージェントごとの状態 (agentDir + sessions)
$OPENCLAW_STATE_DIR/agents/<agentId>/sessions/会話履歴と状態 (エージェントごと)
$OPENCLAW_STATE_DIR/agents/<agentId>/sessions/sessions.jsonセッションメタデータ (エージェントごと)
レガシーの単一エージェントパス ~/.openclaw/agent/* は openclaw doctor によって移行されます。ワークスペース (AGENTS.md、メモリファイル、Skills など) は別で、agents.defaults.workspace 経由で設定されます (デフォルト: ~/.openclaw/workspace)。
これらは ~/.openclaw ではなく、エージェントワークスペースにあります。
  • ワークスペース (エージェントごと): AGENTS.md、SOUL.md、IDENTITY.md、USER.md、MEMORY.md、memory/YYYY-MM-DD.md、任意の HEARTBEAT.md。小文字のルート memory.md はレガシー修復入力専用です。両方が存在する場合、openclaw doctor --fix はそれを MEMORY.md にマージできます。
  • 状態ディレクトリ (~/.openclaw): 設定、チャネル/プロバイダー状態、認証プロファイル、セッション、ログ、共有 Skills (~/.openclaw/skills)。
デフォルトのワークスペースは ~/.openclaw/workspace で、設定できます:
{
  agents: { defaults: { workspace: "~/.openclaw/workspace" } },
}
再起動後にボットが「忘れる」場合は、Gateway が毎回同じワークスペースを使って起動していることを確認してください (リモートモードでは、自分のローカルノート PC ではなく、gateway ホストのワークスペースを使います)。ヒント: 永続的な動作や好みについては、チャット履歴に頼るのではなく、ボットに AGENTS.md または MEMORY.md に書き込むよう依頼してください。エージェントワークスペース と Memory を参照してください。
はい。SOUL.md はエージェントコンテキストに注入されるワークスペースブートストラップファイルの 1 つです。デフォルトのファイルごとの注入上限は 20000 文字です。ファイル全体の合計ブートストラップ予算は 60000 文字です。共有デフォルトを変更します:
{
  agents: {
    defaults: {
      bootstrapMaxChars: 50000,
      bootstrapTotalMaxChars: 300000,
    },
  },
}
または、agents.list[].bootstrapMaxChars / bootstrapTotalMaxChars 配下で 1 つのエージェントを上書きします。/context を使って、生のサイズと注入後のサイズ、および切り詰めが発生したかを確認します。SOUL.md は話し方、スタンス、人格に絞ってください。運用ルールは AGENTS.md に、永続的な事実はメモリに入れます。コンテキスト と エージェント設定 を参照してください。
エージェントワークスペースをprivate git リポジトリに置き、どこか private な場所 (例: GitHub private) にバックアップします。これにより、メモリと AGENTS/SOUL/USER ファイルが保存され、後でアシスタントの「心」を復元できます。~/.openclaw 配下のもの (認証情報、セッション、トークン、暗号化されたシークレットペイロード) はコミットしないでください。完全に復元するには、ワークスペースと状態ディレクトリを別々にバックアップしてください。ドキュメント: エージェントワークスペース。
アンインストール を参照してください。
はい。ワークスペースはデフォルト cwdでありメモリアンカーであって、厳格なサンドボックスではありません。相対パスはワークスペース内で解決されます。サンドボックスが有効でない限り、絶対パスはホスト上の他の場所にアクセスできます。分離するには、agents.defaults.sandbox またはエージェントごとのサンドボックス設定を使います。リポジトリをデフォルトの作業ディレクトリにするには、そのエージェントの workspace をリポジトリルートに向けます。OpenClaw リポジトリ自体は単なるソースコードなので、エージェントにその中で作業させたい意図がある場合を除き、ワークスペースは分けてください。
{
  agents: {
    defaults: {
      workspace: "~/Projects/my-repo",
    },
  },
}
セッション状態はgateway ホストが所有します。リモートモードでは、重要なセッションストアは自分のローカルノート PC ではなくリモートマシン上にあります。セッション管理 を参照してください。

​
設定の基本

OpenClaw は $OPENCLAW_CONFIG_PATH から任意の JSON5 設定を読み取ります (デフォルト: ~/.openclaw/openclaw.json)。ファイルが存在しない場合、~/.openclaw/workspace のデフォルトワークスペースを含む、おおむね安全なデフォルトを使います。
非ループバックの bind には、有効な gateway 認証パスが必要です: 共有シークレット認証 (トークンまたはパスワード)、または正しく設定された ID 認識リバースプロキシの背後にある gateway.auth.mode: "trusted-proxy"。
{
  gateway: {
    bind: "lan",
    auth: {
      mode: "token",
      token: "replace-me",
    },
  },
}
  • gateway.remote.token / .password は、それだけではローカル gateway 認証を有効にしません。ローカル呼び出しパスは、gateway.auth.* が未設定の場合に限り、フォールバックとして gateway.remote.* を使用できます。
  • パスワード認証では、gateway.auth.mode: "password" と gateway.auth.password (または OPENCLAW_GATEWAY_PASSWORD) を設定します。
  • gateway.auth.token / .password が SecretRef 経由で明示的に設定されていて解決できない場合、解決は fail closed します (リモートフォールバックによる隠蔽はありません)。
  • 共有シークレットの Control UI セットアップは、connect.params.auth.token または connect.params.auth.password (アプリ/UI 設定に保存) で認証します。Tailscale Serve や trusted-proxy などの ID を伴うモードは、代わりにリクエストヘッダーを使います。共有シークレットを URL に入れることは避けてください。
  • gateway.auth.mode: "trusted-proxy" では、同一ホストの loopback リバースプロキシに明示的な gateway.auth.trustedProxy.allowLoopback = true と gateway.trustedProxies 内の loopback エントリが必要です。
OpenClaw は loopback を含め、デフォルトで gateway 認証を強制します。明示的な認証パスが設定されていない場合、起動時に token モードへ解決され、その起動専用のランタイムトークンが生成されます。そのため、ローカル WS クライアントも認証する必要があります。これにより、他のローカルプロセスが Gateway を呼び出すことを防ぎます。クライアントが再起動後も安定したシークレットを必要とする場合は、gateway.auth.token、gateway.auth.password、OPENCLAW_GATEWAY_TOKEN、または OPENCLAW_GATEWAY_PASSWORD を明示的に設定してください。パスワードモードや、ID 認識リバースプロキシ向けの trusted-proxy も選択できます。オープンな loopback にするには、gateway.auth.mode: "none" を明示的に設定します。openclaw doctor --generate-gateway-token はいつでもトークンを生成します。
Gateway は設定を監視し、ホットリロードをサポートしています: gateway.reload.mode: "hybrid" (デフォルト) は安全な変更をホット適用し、重要な変更では再起動します。hot、restart、off もサポートされています。ほとんどの tools.*、agents.* ポリシー、session.*、messages.* の変更は、リロード操作なしですぐに適用されます。gateway.* の bind/port 変更には再起動が必要です。
cli.banner.taglineMode を設定します:
{
  cli: {
    banner: {
      taglineMode: "off", // random | default | off
    },
  },
}
  • off: タグラインテキストを非表示にしますが、バナータイトル/バージョン行は保持します。
  • default: 常に All your chats, one OpenClaw. を使います。
  • random: ローテーションするユーモラス/季節的なタグライン (デフォルト動作)。
  • バナー自体を表示しない場合は、env OPENCLAW_HIDE_BANNER=1 を設定します。
web_fetch は API キーなしで動作します。web_search は選択したプロバイダーに依存します:
プロバイダーキー不要環境変数
BraveいいえBRAVE_API_KEY
DuckDuckGoはい (非公式の HTML ベース)-
ExaいいえEXA_API_KEY
FirecrawlいいえFIRECRAWL_API_KEY
GeminiいいえGEMINI_API_KEY
Grokいいえ (xAI OAuth またはキー)XAI_API_KEY
KimiいいえKIMI_API_KEY または MOONSHOT_API_KEY
MiniMax SearchいいえMINIMAX_CODE_PLAN_KEY、MINIMAX_CODING_API_KEY、または MINIMAX_API_KEY
Ollama Web Searchはい (ollama signin が必要)-
PerplexityいいえPERPLEXITY_API_KEY または OPENROUTER_API_KEY
SearXNGはい (セルフホスト)SEARXNG_BASE_URL
TavilyいいえTAVILY_API_KEY
Grok はモデル認証の xAI OAuth (openclaw onboard --auth-choice xai-oauth) も再利用できます。推奨: openclaw configure --section web を実行し、プロバイダーを選択します。
{
  plugins: {
    entries: {
      brave: {
        config: {
          webSearch: {
            apiKey: "BRAVE_API_KEY_HERE",
          },
        },
      },
    },
  },
  tools: {
    web: {
      search: {
        enabled: true,
        provider: "brave",
        maxResults: 5,
      },
      fetch: {
        enabled: true,
        provider: "firecrawl", // 任意。自動検出する場合は省略
      },
    },
  },
}
プロバイダー固有の Web 検索設定は plugins.entries.<plugin>.config.webSearch.* の下にあります。従来の tools.web.search.* プロバイダーパスも互換性のために読み込まれますが、新しい設定では使用しないでください。Firecrawl の Web 取得フォールバック設定は plugins.entries.firecrawl.config.webFetch.* の下にあります。
  • 許可リスト: 3 つすべてに対して web_search/web_fetch/x_search、または group:web を追加します。
  • web_fetch はデフォルトで有効です。
  • tools.web.fetch.provider を省略すると、OpenClaw は利用可能な認証情報から最初に準備できている取得フォールバックプロバイダーを自動検出します。公式 Firecrawl Plugin がそのフォールバックを提供します。
  • デーモンは ~/.openclaw/.env（またはサービス環境）から環境変数を読み取ります。
ドキュメント: Web ツール。
config.apply は 設定全体を置き換えます。部分的なオブジェクトを渡すと、それ以外はすべて削除されます。現在の OpenClaw は、ほとんどの偶発的な上書きから保護します。
  • OpenClaw が所有する設定書き込みは、書き込み前に変更後の設定全体を検証します。
  • 無効または破壊的な OpenClaw 所有の書き込みは拒否され、openclaw.json.rejected.* として保存されます。
  • 起動またはホットリロードを壊す直接編集があると、Gateway はフェイルクローズするかリロードをスキップします。openclaw.json は書き換えません。
  • openclaw doctor --fix が修復を担当し、最後に正常だった設定を復元でき、拒否されたファイルを openclaw.json.clobbered.* として保存します。
復旧:
  • openclaw logs --follow で Invalid config at、Config write rejected:、または config reload skipped (invalid config) を確認します。
  • アクティブな設定の横にある最新の openclaw.json.clobbered.* または openclaw.json.rejected.* を調べます。
  • openclaw config validate と openclaw doctor --fix を実行します。
  • 意図したキーだけを openclaw config set または config.patch で戻します。
  • 最後に正常だった設定や拒否ペイロードがない場合: バックアップから復元するか、openclaw doctor を再実行してチャンネル/モデルを再設定します。
  • 予期しない消失: 最後に分かっている設定またはバックアップを添えてバグを報告してください。ローカルのコーディングエージェントなら、多くの場合ログや履歴から動作する設定を再構築できます。
回避方法: 小さな変更には openclaw config set、対話的な編集には openclaw configure、不慣れなパスの確認には config.schema.lookup（浅いスキーマノードと直下の子要素サマリーを返します）、部分的な RPC 編集には config.patch を使用します。config.apply は設定全体の置き換え用に残してください。エージェント向けの gateway ランタイムツールは、従来の tools.bash.* エイリアス経由であっても tools.exec.ask / tools.exec.security の書き換えを拒否します。ドキュメント: Config、Configure、Gateway トラブルシューティング、Doctor。
一般的なパターンは、1 つの Gateway（たとえば Raspberry Pi）に ノードとエージェントを組み合わせる構成です。
  • Gateway（中央）: チャンネル（Signal/WhatsApp）、ルーティング、セッションを所有します。
  • ノード（デバイス）: Mac/iOS/Android が周辺機器として接続し、ローカルツール（system.run、canvas、camera）を公開します。
  • エージェント（ワーカー）: 特別な役割（たとえば運用と個人データ）ごとに分かれた頭脳/ワークスペースです。
  • サブエージェント: メインエージェントからバックグラウンド作業を生成して並列化します。
  • TUI: Gateway に接続し、エージェント/セッションを切り替えます。
ドキュメント: ノード、リモートアクセス、マルチエージェントルーティング、サブエージェント、TUI。
はい:
{
  browser: { headless: true },
  agents: {
    defaults: {
      sandbox: { browser: { headless: true } },
    },
  },
}
デフォルトは false（ヘッドあり）です。ヘッドレスは一部のサイトでボット対策チェックを引き起こしやすくなります（X/Twitter はヘッドレスセッションをブロックすることがよくあります）。同じ Chromium エンジンを使用し、ほとんどの自動化で動作します。主な違いは、表示されるブラウザーウィンドウがないことです（視覚確認にはスクリーンショットを使用します）。Browser を参照してください。
browser.executablePath を Brave バイナリ（または任意の Chromium ベースのブラウザー）に設定し、Gateway を再起動します。Browser を参照してください。

​
リモート Gateway とノード

Telegram メッセージは gateway によって処理されます。gateway がエージェントを実行し、ノードツールが必要な場合にのみ Gateway WebSocket 経由でノードを呼び出します。Telegram -> Gateway -> Agent -> node.* -> Node -> Gateway -> Telegramノードは受信プロバイダートラフィックを見ません。ノード RPC 呼び出しだけを受け取ります。
コンピューターをノードとしてペアリングします。Gateway は別の場所で実行されますが、Gateway WebSocket 経由でローカルマシン上の node.* ツール（画面、カメラ、システム）を呼び出せます。
  1. 常時稼働するホスト（VPS/ホームサーバー）で Gateway を実行します。
  2. Gateway ホストとコンピューターを同じ tailnet に入れます。
  3. Gateway WS に到達できることを確認します（tailnet バインドまたは SSH トンネル）。
  4. macOS アプリをローカルで開き、Remote over SSH モード（または直接 tailnet）で接続して、ノードとして登録します。
  5. ノードを承認します: 
    openclaw devices list
openclaw devices approve <requestId>
別個の TCP ブリッジは不要です。ノードは Gateway WebSocket 経由で接続します。セキュリティの注意: macOS ノードをペアリングすると、そのマシンで system.run が可能になります。信頼するデバイスだけをペアリングしてください。Security を確認してください。ドキュメント: ノード、Gateway プロトコル、macOS リモートモード、セキュリティ。
基本を確認します。
openclaw gateway status
openclaw status
openclaw channels status
次に認証とルーティングを確認します。Tailscale Serve を使っている場合は gateway.auth.allowTailscale が正しく設定されていることを確認します。SSH トンネルで接続している場合は、トンネルが起動していて正しいポートを指していることを確認します。DM/グループ許可リストに自分のアカウントが含まれていることも確認します。ドキュメント: Tailscale、リモートアクセス、チャンネル。
はい。ただし組み込みのボット間ブリッジはありません。最も簡単: 両方のボットがアクセスできる通常のチャットチャンネル（Slack/Telegram/WhatsApp）を使用します。Bot A から Bot B にメッセージを送り、その後は通常どおり Bot B に返信させます。CLI ブリッジ（汎用）: openclaw agent --message ... --deliver で別の Gateway を呼び出すスクリプトを実行し、相手のボットがリッスンしているチャットを対象にします。片方のボットがリモート VPS 上にある場合は、SSH/Tailscale 経由で CLI をそのリモート Gateway に向けます（リモートアクセス を参照）:
openclaw agent --message "Hello from local bot" --deliver --channel telegram --reply-to <chat-id>
2 つのボットが無限ループしないようにガードレールを追加します（メンションのみ、チャンネル許可リスト、または「ボットメッセージには返信しない」ルール）。ドキュメント: リモートアクセス、Agent CLI、Agent send。
いいえ。1 つの Gateway が複数のエージェントをホストし、それぞれが独自のワークスペース、モデルデフォルト、ルーティングを持ちます。これは通常のセットアップであり、エージェントごとに 1 つの VPS を用意するよりもはるかに安価でシンプルです。個別の VPS は、強い分離（セキュリティ境界）や共有したくない大きく異なる設定が必要な場合にのみ使用してください。
はい。ノードは、リモート Gateway からラップトップに到達し、シェルアクセス以上の機能を解放するための第一級の方法です。Gateway は macOS/Linux（Windows は WSL2 経由）で動作し、軽量です（小さな VPS や Raspberry Pi クラスのマシンで十分です。4 GB RAM で足ります）。そのため、常時稼働ホストにラップトップをノードとして追加する構成が一般的です。
  • インバウンド SSH は不要 - ノードはデバイスペアリングを介して Gateway WebSocket へアウトバウンド接続します。
  • より安全な実行制御 - system.run はそのラップトップ上のノード許可リスト/承認によって制御されます。
  • より多くのデバイスツール - ノードは system.run に加えて canvas、camera、screen を公開します。
  • ローカルブラウザー自動化 - Gateway は VPS 上に置いたまま、ノードホスト経由で Chrome をローカル実行するか、Chrome MCP 経由でローカル Chrome に接続できます。
SSH は一時的なシェルアクセスには適しています。継続的なエージェントワークフローとデバイス自動化には、ノードの方がシンプルです。ドキュメント: ノード、ノード CLI、Browser。
いいえ。分離プロファイルを意図的に実行する場合を除き（複数 Gateway を参照）、ホストごとに実行する gateway は 1 つだけにしてください。ノードは gateway に接続する周辺機器です（iOS/Android ノード、またはメニューバーアプリの macOS「ノードモード」）。ヘッドレスノードホストと CLI 制御については、ノードホスト CLI を参照してください。gateway、discovery、ホストされる Plugin サーフェスの変更には完全な再起動が必要です。
はい:
  • config.schema.lookup: 書き込み前に、浅いスキーマノード、一致した UI ヒント、直下の子要素サマリーとともに 1 つの設定サブツリーを調べます。
  • config.get: 現在のスナップショットとハッシュを取得します。
  • config.patch: 安全な部分更新（ほとんどの RPC 編集で推奨）。可能な場合はホットリロードし、必要な場合は再起動します。
  • config.apply: 設定全体を検証して置き換えます。可能な場合はホットリロードし、必要な場合は再起動します。
  • エージェント向けの gateway ランタイムツールは、引き続き tools.exec.ask / tools.exec.security の書き換えを拒否します。従来の tools.bash.* エイリアスも同じ保護対象パスに正規化されます。
{
  agents: { defaults: { workspace: "~/.openclaw/workspace" } },
  channels: { whatsapp: { allowFrom: ["+15555550123"] } },
}
ワークスペースを設定し、誰がボットを起動できるかを制限します。
  1. VPS にインストールしてログイン: 
    curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
  2. Mac にインストールしてログインします。Tailscale アプリを使い、同じ tailnet に入れます。
  3. MagicDNS を有効化します。Tailscale 管理コンソールで有効にすると、VPS に安定した名前が付きます。
  4. tailnet ホスト名を使用します: SSH は ssh user@your-vps.tailnet-xxxx.ts.net、Gateway WS は ws://your-vps.tailnet-xxxx.ts.net:18789。
SSH なしで Control UI を使うには、VPS で Tailscale Serve を使用します。
openclaw gateway --tailscale serve
これにより gateway はループバックにバインドされたままになり、Tailscale 経由で HTTPS が公開されます。Tailscale を参照してください。
Serve は Gateway Control UI + WS を公開します。ノードは同じ Gateway WS エンドポイント経由で接続します。
  1. VPS と Mac が同じ tailnet 上にあることを確認します。
  2. Remote モードで macOS アプリを使用します（SSH ターゲットには tailnet ホスト名を使用できます） - これにより Gateway ポートがトンネルされ、ノードとして接続されます。
  3. ノードを承認します: 
    openclaw devices list
openclaw devices approve <requestId>
Docs: Gateway プロトコル, Discovery, macOS リモートモード.
2 台目のラップトップで ローカルツールのみ（screen/camera/exec）を使う場合は、ノード として追加します - Gateway は 1 つで、設定の重複はありません。ローカルノードツールは現在 macOS のみ対応です。2 つ目の Gateway は、強い分離 または完全に別々の 2 つのボットが必要な場合にのみインストールします。Docs: ノード, ノード CLI, 複数 Gateway.

​
環境変数と .env の読み込み

OpenClaw は親プロセス（shell、launchd/systemd、CI など）から env vars を読み取り、さらに以下を読み込みます:
  • 現在の作業ディレクトリの .env。
  • ~/.openclaw/.env ($OPENCLAW_STATE_DIR/.env) からのグローバルフォールバック .env。
どちらの .env ファイルも既存の env vars を上書きしません。プロバイダー認証情報キーはワークスペース .env の例外です。GEMINI_API_KEY、XAI_API_KEY、MISTRAL_API_KEY などのキー（およびその他の同梱プロバイダー認証 env vars）はワークスペース .env からは無視され、プロセス環境、~/.openclaw/.env、または config env に置く必要があります。config 内のインライン env vars は、プロセス env に存在しない場合にのみ適用されます:
{
  env: {
    OPENROUTER_API_KEY: "sk-or-...",
    vars: { GROQ_API_KEY: "gsk-..." },
  },
}
完全な優先順位とソースについては /environment を参照してください。
修正方法は 2 つあります:
  1. 不足しているキーを ~/.openclaw/.env に置くと、service が shell env を継承しない場合でも読み込まれます。
  2. shell import を有効にします（任意の利便機能）: 
    {
  env: {
    shellEnv: {
      enabled: true,
      timeoutMs: 15000,
    },
  },
}
    これは login shell を実行し、不足している想定キーのみをインポートします（上書きはしません）。対応する env var: OPENCLAW_LOAD_SHELL_ENV=1, OPENCLAW_SHELL_ENV_TIMEOUT_MS=15000.
openclaw models status は shell env import が有効かどうかを報告します。“Shell env: off” は env vars が不足しているという意味ではありません - OpenClaw が login shell を自動的に読み込まないという意味です。Gateway が service（launchd/systemd）として実行されている場合、shell environment は継承されません。token を ~/.openclaw/.env に置くか、env.shellEnv.enabled: true を有効にするか、config env に追加して（不足している場合のみ適用）、gateway を再起動してから再確認してください:
openclaw models status
Copilot token は次の順序で解決されます: OPENCLAW_GITHUB_TOKEN、次に COPILOT_GITHUB_TOKEN、次に GH_TOKEN、次に GITHUB_TOKEN。/concepts/model-providers と /environment を参照してください。

​
セッションと複数のチャット

単独のメッセージとして /new または /reset を送信します。セッション管理 を参照してください。
はい。デフォルトのリセットポリシーは 毎日 です。セッションは、現在のセッションが開始された時刻を基準に、gateway ホスト上の設定されたローカル時刻（session.reset.atHour、デフォルト 4、0-23）でロールオーバーします。代わりに idle ベースのリセットに切り替えるには、mode: "idle" と session.reset.idleMinutes を使用します。これは非アクティブな期間後にセッションを期限切れにします（heartbeat/cron/exec system events ではなく、最後の実際の操作に基づきます）。
{
  session: {
    reset: { mode: "daily", atHour: 4 },
    resetByType: {
      group: { mode: "idle", idleMinutes: 120 },
      thread: { mode: "daily", atHour: 6 },
    },
    resetByChannel: {
      discord: { mode: "idle", idleMinutes: 10080 },
    },
  },
}
resetByType は direct（legacy alias dm）、group、thread をサポートします。従来のトップレベル session.idleMinutes は、session.reset/resetByType ブロックが設定されていない場合、idle-mode default の互換エイリアスとして引き続き機能します。active provider-owned CLI session を持つセッションは、暗黙の daily default では切断されません。完全なライフサイクルについては セッション管理 を参照してください。
はい、multi-agent routing と sub-agents により可能です。1 つの coordinator agent と、それぞれ独自の workspaces と models を持つ複数の worker agents を使用します。これは楽しい実験として見るのが最適です - token を大量に使い、別々の sessions を持つ 1 つの bot より効率が低いことがよくあります。典型的なモデルは、会話する bot が 1 つあり、並列作業には別々の sessions を使い、必要に応じて sub-agents を起動する形です。Docs: Multi-agent routing, Sub-agents, Agents CLI.
セッション context は model window によって制限されます。長い chats、大きな tool outputs、多数の files により compaction または truncation が発生することがあります。
  • bot に現在の状態を要約して file に書くよう依頼します。
  • 長い tasks の前に /compact を使い、topics を切り替えるときは /new を使います。
  • 重要な context は workspace に保持し、bot に読み返すよう依頼します。
  • 長い作業や並列作業には sub-agents を使い、main chat を小さく保ちます。
  • これが頻繁に起きる場合は、より大きな context window を持つ model を選びます。
openclaw reset
非対話式の full reset:
openclaw reset --scope full --yes --non-interactive
その後、setup を再実行します:
openclaw onboard --install-daemon
既存の config が検出された場合、オンボーディングでも Reset が提示されます。オンボーディング (CLI) を参照してください。profiles（--profile / OPENCLAW_PROFILE）を使用している場合は、各 state dir（デフォルト ~/.openclaw-<profile>）をリセットします。Dev-only reset: openclaw gateway --dev --reset は dev config、credentials、sessions、workspace を消去します。
  • Compact（会話を保持し、古い turns を要約します）: /compact、または要約を指示する /compact <instructions>。
  • Reset（同じ chat key の fresh session ID）: /new または /reset。
これが続く場合は、session pruning（agents.defaults.contextPruning）を調整して古い tool output を削減するか、より大きな context window を持つ model を使用してください。Docs: Compaction, Session pruning, Session management.
Provider validation error: model が必須の input なしで tool_use ブロックを出力しました。通常は、session history が古いか破損していることを意味します（長い threads や tool/schema change の後によくあります）。修正: /new（standalone message）で fresh session を開始します。
Heartbeats はデフォルトで 30m ごとに実行されます。resolved auth mode が Anthropic OAuth/token auth（Claude CLI reuse を含む）で heartbeat.every が未設定の場合は 1h ごとです。調整または無効化するには:
{
  agents: {
    defaults: {
      heartbeat: {
        every: "2h", // or "0m" to disable
      },
    },
  },
}
HEARTBEAT.md が存在していても実質的に空（空行、Markdown/HTML comments、ATX headings、fence markers、または空の list-item stubs のみ）の場合、OpenClaw は API calls を節約するため heartbeat run をスキップします。file が存在しない場合でも heartbeat は実行され、model が何をするかを決定します。Per-agent overrides は agents.list[].heartbeat を使用します。Docs: Heartbeat.
いいえ。OpenClaw は 自分の account で実行されます - 自分が group に入っていれば、OpenClaw はそれを見ることができます。デフォルトでは、senders を許可するまで group replies はブロックされます（groupPolicy: "allowlist"）。group replies を自分だけに制限するには:
{
  channels: {
    whatsapp: {
      groupPolicy: "allowlist",
      groupAllowFrom: ["+15551234567"],
    },
  },
}
最速の方法: logs を tail し、group で test message を送信します。
openclaw logs --follow --json
1234567890-1234567890@g.us のように @g.us で終わる chatId（または from）を探します。すでに設定済み/allowlisted の場合は、config から groups を一覧表示します:
openclaw directory groups list --channel whatsapp
Docs: WhatsApp, Directory, Logs.
一般的な原因は 2 つあります。mention gating がデフォルトでオンになっている（bot を @mention するか、mentionPatterns に一致する必要がある）か、channels.whatsapp.groups を "*" なしで設定していて、その group が allowlisted ではない場合です。Groups と Group messages を参照してください。
Direct chats はデフォルトで main session に集約されます。Groups/channels は独自の session keys を持ち、Telegram topics / Discord threads は別々の sessions です。Groups と Group messages を参照してください。
ハードリミットはありません - 数十または数百でも問題ありませんが、以下に注意してください:
  • Disk growth: sessions と transcripts は ~/.openclaw/agents/<agentId>/sessions/ 配下にあります。
  • Token cost: agents が増えるほど、同時 model usage が増えます。
  • Ops overhead: agent ごとの auth profiles、workspaces、channel routing。
agent ごとに active workspace を 1 つ維持し（agents.defaults.workspace）、disk が増えたら古い sessions を prune し、openclaw doctor を使って stray workspaces と profile mismatches を見つけます。
はい、Multi-Agent Routing により可能です。複数の isolated agents を実行し、inbound messages を channel/account/peer によって route します。Slack は channel としてサポートされ、特定の agents に bind できます。Browser access は強力ですが、「人間にできることは何でもできる」わけではありません - anti-bot、CAPTCHAs、MFA は automation をブロックすることがあります。最も信頼できる control には、host 上の local Chrome MCP、または実際に browser を実行している machine 上の CDP を使用します。Best-practice setup: always-on Gateway host（VPS/Mac mini）、role ごとに 1 つの agent（bindings）、それらの agents に bound された Slack channel(s)、必要に応じて Chrome MCP または node 経由の local browser。ドキュメント: Multi-Agent Routing、Slack、Browser、Nodes。

​
モデル、フェイルオーバー、認証プロファイル

モデル Q&A - デフォルト、選択、エイリアス、切り替え、フェイルオーバー、認証プロファイル - は Models FAQ にあります。

​
Gateway: ポート、「すでに実行中」、リモートモード

gateway.port は WebSocket + HTTP（Control UI、フックなど）用の単一の多重化ポートを制御します。優先順位:
--port > OPENCLAW_GATEWAY_PORT > gateway.port > default 18789
“Running” は スーパーバイザー の見方（launchd/systemd/schtasks）です。接続プローブは、CLI が実際に Gateway WebSocket に接続しています。openclaw gateway status の次の行を信頼してください: Probe target:（プローブが使用した URL）、Listening:（ポートで実際にバインドされているもの）、Last gateway error:（プロセスは生きているがポートが listen していない場合の一般的な根本原因）。
サービスが別の設定ファイルで実行されている一方で、別の設定ファイルを編集しています（多くの場合 --profile / OPENCLAW_STATE_DIR の不一致）。修正するには、サービスに使用させたい同じ --profile / 環境から実行します:
openclaw gateway install --force
OpenClaw は起動時に WebSocket リスナーを即座にバインドすることでランタイムロックを強制します（デフォルト ws://127.0.0.1:18789）。バインドが EADDRINUSE で失敗すると、GatewayLockError（“another gateway instance is already listening”）をスローします。修正: 他のインスタンスを停止する、ポートを解放する、または openclaw gateway --port <port> で実行します。
gateway.mode: "remote" を設定し、必要に応じて共有シークレットのリモート認証情報を付けて、リモート WebSocket URL を指定します:
{
  gateway: {
    mode: "remote",
    remote: {
      url: "ws://gateway.tailnet:18789",
      token: "your-token",
      password: "your-password",
    },
  },
}
  • openclaw gateway は gateway.mode が local の場合（または上書きフラグを渡した場合）にのみ起動します。
  • macOS アプリは設定ファイルを監視し、これらの値が変更されるとライブでモードを切り替えます。
  • gateway.remote.token / .password はクライアント側のリモート認証情報のみです。それ自体でローカル Gateway 認証を有効にするものではありません。
Gateway の認証パスと UI の認証方式が一致していません。事実（コードから）:
  • Control UI はトークンを sessionStorage に保持し、現在のブラウザータブと選択された Gateway URL にスコープします。そのため、同じタブでの更新は長期間保持される localStorage トークン永続化なしで動作し続けます。
  • AUTH_TOKEN_MISMATCH では、Gateway がリトライヒント（canRetryWithDeviceToken=true、recommendedNextStep=retry_with_device_token）を返した場合、信頼済みクライアントはキャッシュ済みデバイストークンで 1 回だけの限定リトライを試行できます。
  • そのキャッシュ済みトークンのリトライでは、デバイストークンとともに保存されたキャッシュ済みの承認済みスコープを再利用します。明示的な deviceToken / 明示的な scopes の呼び出し元は、キャッシュ済みスコープを継承せず、要求したスコープセットを保持します。
  • そのリトライパス以外では、接続認証の優先順位は、明示的な共有トークン/パスワード、次に明示的な deviceToken、次に保存済みデバイストークン、次にブートストラップトークンです。
  • 組み込みのセットアップコードブートストラップは、scopes: [] を持つノードデバイストークンと、信頼済みモバイルオンボーディング用の限定されたオペレーターハンドオフトークンを返します。オペレーターハンドオフはセットアップ時のネイティブ設定を読み取れますが、ペアリング変更スコープや operator.admin は付与しません。
修正:
  • 最速: openclaw dashboard（ダッシュボード URL を表示してコピーし、開こうとします。ヘッドレスの場合は SSH ヒントを表示します）。
  • まだトークンがない場合: openclaw doctor --generate-gateway-token。
  • リモート: まず ssh -N -L 18789:127.0.0.1:18789 user@host でトンネルし、その後 http://127.0.0.1:18789/ を開きます。
  • 共有シークレットモード: gateway.auth.token / OPENCLAW_GATEWAY_TOKEN または gateway.auth.password / OPENCLAW_GATEWAY_PASSWORD を設定し、Control UI 設定に一致するシークレットを貼り付けます。
  • Tailscale Serve モード: gateway.auth.allowTailscale が有効であり、Tailscale ID ヘッダーを迂回する生のループバック/tailnet URL ではなく、Serve URL を開いていることを確認します。
  • 信頼済みプロキシモード: 設定済みの ID 対応プロキシ経由でアクセスしていることを確認します。同一ホストのループバックプロキシにも gateway.auth.trustedProxy.allowLoopback = true が必要です。
  • 1 回のリトライ後も不一致が続く場合: ペアリング済みデバイストークンをローテーション/再承認します: 
    openclaw devices list
openclaw devices rotate --device <id> --role operator
  • ローテーションが拒否される場合: ペアリング済みデバイスセッションは、operator.admin も持っていない限り 自分自身の デバイスのみをローテーションできます。また、明示的な --scope 値は呼び出し元の現在のオペレータースコープを超えることはできません。
  • まだ詰まっている場合: openclaw status --all と Troubleshooting。認証の詳細は Dashboard を参照してください。
tailnet バインドはネットワークインターフェイスから Tailscale IP を選びます（100.64.0.0/10）。マシンが Tailscale 上にない（またはインターフェイスがダウンしている）場合、バインド先はありません。修正: そのホストで Tailscale を起動するか、gateway.bind: "loopback" / "lan" に切り替えます。tailnet は明示的です。auto はループバックを優先します。tailnet 専用バインドには gateway.bind: "tailnet" を使用します。
通常はできません。1 つの Gateway で複数のメッセージングチャンネルとエージェントを実行できます。複数の Gateway は、冗長性（たとえばレスキューボット）または厳密な分離のためだけに使用し、それぞれを独自の OPENCLAW_CONFIG_PATH、OPENCLAW_STATE_DIR、agents.defaults.workspace、一意の gateway.port で分離してください。推奨: インスタンスごとに openclaw --profile <name> ...（~/.openclaw-<name> を自動作成）、プロファイル設定ごとに一意の gateway.port（または手動実行では --port）、および openclaw --profile <name> gateway install によるプロファイルごとのサービス。プロファイルはサービス名にも接尾辞を付けます: launchd ai.openclaw.<profile>、systemd openclaw-gateway-<profile>.service、Windows OpenClaw Gateway (<profile>)。修飾なしの openclaw-gateway systemd ユニットはデフォルトプロファイルにのみ存在します。名前変更前のレガシー systemd ユニット名 clawdbot-gateway は自動的に移行されます。完全なガイド: Multiple gateways。
Gateway は WebSocket サーバー であり、最初のメッセージとして connect フレームを期待します。それ以外はすべて コード 1008（ポリシー違反）で接続を閉じます。一般的な原因: WS クライアントではなくブラウザーで HTTP URL を開いた、ポート/パスが間違っている、またはプロキシ/トンネルが認証ヘッダーを削除した、あるいは Gateway 以外のリクエストを送信した。修正: WS URL（ws://<host>:18789、または HTTPS 経由では wss://...）を使用し、通常のブラウザータブで WS ポートを開かず、認証が有効な場合は connect フレームにトークン/パスワードを含めます。CLI/TUI の例:
openclaw tui --url ws://<host>:18789 --token <token>
プロトコル詳細: Gateway protocol。

​
ロギングとデバッグ

ファイルログ（構造化）: /tmp/openclaw/openclaw-YYYY-MM-DD.log。安定したパスは logging.file で設定します。ファイルログレベルは logging.level、コンソールの詳細度は --verbose と logging.consoleLevel で設定します。最速の tail:
openclaw logs --follow
サービス/スーパーバイザーログ（Gateway が launchd/systemd 経由で実行される場合）:
  • macOS launchd stdout: ~/Library/Logs/openclaw/gateway.log（プロファイルは gateway-<profile>.log を使用します。stderr は抑制されます）。
  • Linux: journalctl --user -u openclaw-gateway[-<profile>].service -n 200 --no-pager。
  • Windows: schtasks /Query /TN "OpenClaw Gateway (<profile>)" /V /FO LIST。
詳細は Troubleshooting を参照してください。
openclaw gateway status
openclaw gateway restart
Gateway を手動で実行している場合、openclaw gateway --force でポートを再取得できます。Gateway を参照してください。
Windows のインストールモードは 3 つあります:1) Windows Hub ローカルセットアップ: ネイティブアプリが、ローカルのアプリ所有 WSL Gateway を管理します。スタートメニューまたはトレイから OpenClaw Companion を開き、Gateway Setup または Connections タブを使用します。2) 手動 WSL2 Gateway: Gateway は Linux 内で実行されます。
wsl
openclaw gateway status
openclaw gateway restart
サービスをインストールしていない場合は、フォアグラウンドで開始します: openclaw gateway run。3) ネイティブ Windows CLI/Gateway: Windows で直接実行されます。
openclaw gateway status
openclaw gateway restart
手動で実行する場合（サービスなし）: openclaw gateway run。ドキュメント: Windows、Gateway service runbook。
クイックヘルス確認:
openclaw status
openclaw models status
openclaw channels status
openclaw logs --follow
一般的な原因: モデル認証が Gateway ホスト に読み込まれていない（models status を確認）、チャンネルのペアリング/許可リストが返信をブロックしている（チャンネル設定とログを確認）、または WebChat/Dashboard を正しいトークンなしで開いている。リモートの場合は、トンネル/Tailscale 接続が稼働しており、Gateway WebSocket に到達できることを確認してください。ドキュメント: Channels、Troubleshooting、Remote access。
通常は、UI が WebSocket 接続を失ったことを意味します。確認してください: Gateway は実行中ですか（openclaw gateway status）？正常ですか（openclaw status）？UI は正しいトークンを持っていますか（openclaw dashboard）？リモートの場合、トンネル/Tailscale リンクは稼働していますか？次にログを tail します:
openclaw logs --follow
ドキュメント: Dashboard、Remote access、Troubleshooting。
openclaw channels status
openclaw channels logs --channel telegram
次にエラーを照合します:
  • BOT_COMMANDS_TOO_MUCH: Telegram メニューのエントリが多すぎます。OpenClaw はすでに Telegram の上限までトリミングし、より少ないコマンドで再試行しますが、一部のメニューエントリはまだ削除される場合があります。plugin/skill/カスタムコマンドを減らすか、メニューが不要であれば channels.telegram.commands.native を無効にしてください。
  • TypeError: fetch failed、Network request for 'setMyCommands' failed!、または同様のネットワークエラー: VPS 上またはプロキシ背後では、アウトバウンド HTTPS が許可され、api.telegram.org の DNS が機能していることを確認してください。
Gateway がリモートの場合は、Gateway ホスト上のログを確認してください。ドキュメント: Telegram、Channel troubleshooting。
openclaw status
openclaw models status
openclaw logs --follow
TUI では、/status を使って現在の状態を確認します。チャットチャネルで返信を期待している場合は、配信が有効になっていることを確認してください（/deliver on）。ドキュメント: TUI, スラッシュコマンド。
サービスとしてインストールしている場合（macOS の launchd、Linux の systemd）:
openclaw gateway stop
openclaw gateway start
フォアグラウンドでは、Ctrl-C で停止してから openclaw gateway run を実行します。ドキュメント: Gateway サービス運用手順。
openclaw gateway restart はバックグラウンドサービス（launchd/systemd）を再起動します。openclaw gateway は、このターミナルセッションで Gateway をフォアグラウンド実行します。サービスをインストールしている場合は Gateway サブコマンドを使い、単発の場合は素のフォアグラウンド実行を使います。
--verbose を付けて Gateway を起動してコンソール詳細を増やし、その後ログファイルでチャネル認証、モデルルーティング、RPC エラーを確認します。

​
メディアと添付ファイル

エージェントからの送信添付ファイルは、media、mediaUrl、path、filePath などの構造化メディアフィールドを使う必要があります。OpenClaw アシスタント設定とエージェント送信を参照してください。
openclaw message send --target +15555550123 --message "Here you go" --media /path/to/file.png
併せて確認してください: 対象チャネルが送信メディアをサポートしていて、許可リストでブロックされていないこと。ファイルがプロバイダーのサイズ制限内であること（画像は最大辺 2048px にリサイズされます）。tools.fs.workspaceOnly=true は、ローカルパス送信をワークスペース、temp/media-store、サンドボックス検証済みファイルに制限します。tools.fs.workspaceOnly=false（デフォルト）では、構造化ローカルメディア送信で、エージェントがすでに読み取れるホストローカルファイルを、メディアと安全なドキュメント種別（画像、音声、動画、PDF、Office ドキュメント、Markdown/MD、TXT、JSON、YAML/YML などの検証済みテキストドキュメント）に使えます。これはシークレットスキャナーではありません。拡張機能とコンテンツ検証が一致する場合、エージェントが読み取れる secret.txt や config.json を添付できます。機密ファイルはエージェントが読み取れるパスの外に置くか、より厳格なローカルパス送信のために tools.fs.workspaceOnly=true を維持してください。画像を参照してください。

​
セキュリティとアクセス制御

受信 DM は信頼できない入力として扱ってください。デフォルトではリスクが低減されます:
  • DM 対応チャネルのデフォルト動作はペアリングです。不明な送信者はペアリングコードを受け取り、そのメッセージは処理されません。openclaw pairing approve --channel <channel> [--account <id>] <code> で承認します。保留中のリクエストはチャネルごとに 3 件に制限されます。コードが届かなかった場合は、openclaw pairing list --channel <channel> [--account <id>] を確認してください。
  • DM を公開するには、明示的なオプトイン（dmPolicy: "open" と許可リスト "*"）が必要です。
openclaw doctor を実行して、リスクのある DM ポリシーを表示します。
いいえ。プロンプトインジェクションは、ボットに DM できる相手だけでなく、信頼できないコンテンツの問題です。アシスタントが外部コンテンツ（Web 検索/取得、ブラウザページ、メール、ドキュメント、添付ファイル、貼り付けられたログ）を読む場合、そのコンテンツにはモデルを乗っ取ろうとする指示が含まれる可能性があります。送信者が自分だけであっても同じです。最大のリスクはツールが有効な場合です。モデルがだまされて、コンテキストを外部に流出させたり、あなたの代わりにツールを呼び出したりする可能性があります。影響範囲を小さくしてください:
  • 信頼できないコンテンツを要約するには、読み取り専用またはツール無効の「リーダー」エージェントを使う
  • ツール有効エージェントでは web_search / web_fetch / browser をオフにしておく
  • デコードされたファイル/ドキュメントのテキストも信頼できないものとして扱う: OpenResponses input_file とメディア添付抽出はいずれも、生のファイルテキストを渡すのではなく、抽出テキストを明示的な外部コンテンツ境界マーカーで囲みます
  • サンドボックス化し、厳格なツール許可リストを使う
詳細: セキュリティ。
言語とランタイムは重要ですが、個人エージェントにとって主なリスクではありません。実際のリスクは、Gateway の公開、ボットにメッセージを送れる相手、プロンプトインジェクション、ツール範囲、認証情報の扱い、ブラウザアクセス、exec アクセス、サードパーティのスキル/Plugin の信頼性です。Rust と WASM は一部のコード分類に対してより強い分離を提供できますが、プロンプトインジェクション、不適切な許可リスト、公開 Gateway、過度に広いツール、機密アカウントにすでにログイン済みのブラウザプロファイルは解決しません。主要な制御として、Gateway を非公開または認証付きに保ち、DM/グループにはペアリングと許可リストを使い、信頼できない入力に対してリスクの高いツールを拒否またはサンドボックス化し、信頼できる Plugin とスキルのみをインストールし、設定変更後に openclaw security audit --deep を実行してください。詳細: セキュリティ, サンドボックス化。
openclaw security audit --deep
openclaw gateway status
より安全なベースライン: Gateway を loopback にバインドする、または認証済みのプライベートアクセス（tailnet、SSH トンネル、トークン/パスワード認証、正しく設定された信頼済みプロキシ）経由でのみ公開する。DM は pairing または allowlist モードにする。グループは許可リスト化し、全メンバーが信頼されていない限りメンション必須にする。信頼できないコンテンツを読むエージェントでは、高リスクツール（exec、browser、gateway、cron）を拒否するか厳しくスコープする。ツール実行の影響範囲を小さくする必要がある場所ではサンドボックス化を有効にする。認証なしの公開バインド、ツール付きの公開 DM/グループ、公開されたブラウザ制御は、最初に修正すべき検出事項です。詳細: openclaw security audit。
サードパーティのスキルと Plugin は、信頼することを選ぶコードとして扱ってください。ClawHub のスキルページはインストール前にスキャン状態を表示しますが、スキャンは完全なセキュリティ境界ではありません。OpenClaw は Plugin/スキルのインストールや更新時に、組み込みのローカル危険コードブロックを実行しません。ローカルの許可/ブロック判断には、オペレーター所有の security.installPolicy を使ってください。より安全なパターン: 信頼できる作者と固定バージョンを優先し、有効化前にスキル/Plugin を読み、Plugin/スキルの許可リストを狭く保ち、信頼できない入力のワークフローは最小限のツールを持つサンドボックスで実行し、サードパーティコードに広範なファイルシステム、exec、ブラウザ、シークレットアクセスを与えないようにします。詳細: Skills, Plugin, セキュリティ。
ほとんどの設定では、はい。ボットを別アカウントや別電話番号で分離すると、問題が起きた場合の影響範囲が小さくなり、個人アカウントに影響を与えずに認証情報のローテーションやアクセス取り消しがしやすくなります。小さく始めてください。実際に必要なツールとアカウントだけにアクセスを与え、必要になったら後で拡張します。ドキュメント: セキュリティ, ペアリング。
個人メッセージに対する完全な自律性は推奨しません。最も安全なパターン: DM はペアリングモードまたは厳格な許可リストに保ち、あなたの代わりにメッセージを送る必要がある場合は別の番号またはアカウントを使い、送信前に承認する形で下書きさせます。実験する場合は、専用の分離されたアカウントで行ってください。セキュリティを参照してください。
はい、エージェントがチャット専用で、入力が信頼できる場合に限ります。小さいティアは指示の乗っ取りを受けやすいため、ツール有効エージェントや信頼できないコンテンツを読む場合には避けてください。小さいモデルを使う必要がある場合は、ツールをロックダウンし、サンドボックス内で実行してください。セキュリティを参照してください。
ペアリングコードは、不明な送信者がボットにメッセージを送り、dmPolicy: "pairing" が有効な場合にのみ送信されます。/start だけではコードは生成されません。保留中のリクエストを確認します:
openclaw pairing list telegram
すぐにアクセスするには、送信者 ID を許可リストに追加するか、そのアカウントの dmPolicy: "open" を設定してください。
いいえ。デフォルトの WhatsApp DM ポリシーはペアリングです。不明な送信者はペアリングコードだけを受け取り、そのメッセージは処理されません。OpenClaw は、受信したチャットまたはあなたが明示的にトリガーした送信にのみ返信します。
openclaw pairing approve whatsapp <code>
openclaw pairing list whatsapp
ウィザードの電話番号プロンプトは、あなた自身の DM が許可されるように許可リスト/所有者を設定します。自動送信には使われません。個人の WhatsApp 番号では、その番号を使い、channels.whatsapp.selfChatMode を有効にしてください。

​
チャットコマンド、タスクの中止、「止まらない」場合

ほとんどの内部/ツールメッセージは、そのセッションで verbose、trace、reasoning が有効な場合にのみ表示されます。表示されているチャットで修正します:
/verbose off
/trace off
/reasoning off
まだうるさい場合: Control UI のセッション設定を確認し、verbose を継承に設定します。設定で verboseDefault: "on" のボットプロファイルを使っていないことを確認してください。ドキュメント: 思考と verbose, セキュリティ。
中止をトリガーするには、次のいずれかを単独のメッセージ（スラッシュなし）として送信します: stop, stop action, stop current action, stop run, stop current run, stop agent, stop the agent, stop openclaw, openclaw stop, stop don't do anything, stop do not do anything, stop doing anything, do not do that, please stop, stop please, abort, esc, wait, exit, interrupt, halt。一般的な英語以外のトリガー（フランス語、ドイツ語、スペイン語、中国語、日本語、ヒンディー語、アラビア語、ロシア語）も機能します。exec ツールで開始されたバックグラウンドプロセスについては、エージェントに次を実行するよう依頼してください:
process action:kill sessionId:XXX
ほとんどのスラッシュコマンドは、/ で始まる単独のメッセージとして送信する必要がありますが、いくつかのショートカット（/status など）は、許可リスト済み送信者であればインラインでも機能します。スラッシュコマンドを参照してください。
OpenClaw はデフォルトでプロバイダー間メッセージングをブロックします。ツール呼び出しが Telegram にバインドされている場合、明示的に許可しない限り Discord には送信されません。また、これは即時に有効になり、Gateway の再起動は不要です:
{
  tools: {
    message: {
      crossContext: {
        allowAcrossProviders: true,
        marker: { enabled: true, prefix: "[from {channel}] " },
      },
    },
  },
}
実行中のプロンプトは、デフォルトでアクティブな実行に誘導されます。/queue を使って、アクティブ実行の動作を選択します。
  • steer (デフォルト) - 次のモデル境界でアクティブな実行を誘導します。
  • followup - メッセージをキューに入れ、現在の実行が終了した後に 1 つずつ実行します。
  • collect - 互換性のあるメッセージをキューに入れ、現在の実行が終了した後に 1 回返信します。
  • interrupt - 現在の実行を中止し、新しく開始します。
debounce:0.5s cap:25 drop:summarize のようなオプションをキュー済みモードに追加します。コマンドキュー と Steering キュー を参照してください。

​
その他

認証情報とモデル選択は別です。ANTHROPIC_API_KEY を設定する (または認証プロファイルに Anthropic API キーを保存する) と認証が有効になりますが、実際のデフォルトモデルは agents.defaults.model.primary に設定したものです (たとえば anthropic/claude-sonnet-4-6 や anthropic/claude-opus-4-6)。No credentials found for profile "anthropic:default" は、Gateway が実行中のエージェントの想定される auth-profiles.json 内で Anthropic 認証情報を見つけられなかったことを意味します。
まだ解決しませんか？Discord で質問するか、GitHub discussion を開いてください。

​
関連