Gateway
サンドボックス化
OpenClaw は、影響範囲を抑えるために サンドボックスバックエンド内でツールを実行できます。これは任意であり、設定(agents.defaults.sandbox または agents.list[].sandbox)によって制御されます。サンドボックス化がオフの場合、ツールはホスト上で実行されます。Gateway はホスト上に残り、有効化されている場合はツール実行が隔離されたサンドボックス内で行われます。
サンドボックス化されるもの
- ツール実行(
exec、read、write、edit、apply_patch、processなど)。 - 任意のサンドボックス化されたブラウザ(
agents.defaults.sandbox.browser)。
サンドボックス化されたブラウザの詳細
- デフォルトでは、ブラウザツールが必要としたときにサンドボックスブラウザが自動起動します(CDP に到達可能であることを保証します)。
agents.defaults.sandbox.browser.autoStartとagents.defaults.sandbox.browser.autoStartTimeoutMsで設定します。 - デフォルトでは、サンドボックスブラウザコンテナはグローバルな
bridgeネットワークではなく、専用の Docker ネットワーク(openclaw-sandbox-browser)を使用します。agents.defaults.sandbox.browser.networkで設定します。 - 任意の
agents.defaults.sandbox.browser.cdpSourceRangeは、CIDR 許可リスト(例:172.21.0.1/32)によってコンテナ端の CDP 受信を制限します。 - noVNC オブザーバーアクセスはデフォルトでパスワード保護されています。OpenClaw は短命のトークン URL を発行し、それがローカルのブートストラップページを提供して、URL フラグメント(クエリやヘッダーログではありません)内のパスワードで noVNC を開きます。
agents.defaults.sandbox.browser.allowHostControlにより、サンドボックス化されたセッションがホストブラウザを明示的に対象にできます。- 任意の許可リストが
target: "custom"をゲートします:allowedControlUrls、allowedControlHosts、allowedControlPorts。
サンドボックス化されないもの:
- Gateway プロセス自体。
- サンドボックス外での実行が明示的に許可されたツール(例:
tools.elevated)。- 昇格された exec はサンドボックス化をバイパスし、設定された脱出パス(デフォルトは
gateway、exec 対象がnodeの場合はnode)を使用します。 - サンドボックス化がオフの場合、
tools.elevatedは実行を変更しません(すでにホスト上です)。Elevated Mode を参照してください。
- 昇格された exec はサンドボックス化をバイパスし、設定された脱出パス(デフォルトは
モード
agents.defaults.sandbox.mode は、サンドボックス化をいつ使用するかを制御します。
off
サンドボックス化なし。
non-main
non-main セッションのみをサンドボックス化します(通常のチャットをホスト上で実行したい場合のデフォルト)。
"non-main" はエージェント ID ではなく、session.mainKey(デフォルトは "main")に基づきます。グループ/チャンネルセッションは独自のキーを使用するため、non-main と見なされ、サンドボックス化されます。
all
すべてのセッションがサンドボックス内で実行されます。
スコープ
agents.defaults.sandbox.scope は、作成されるコンテナ数を制御します。
"agent"(デフォルト): エージェントごとに 1 つのコンテナ。"session": セッションごとに 1 つのコンテナ。"shared": すべてのサンドボックス化されたセッションで共有される 1 つのコンテナ。
バックエンド
agents.defaults.sandbox.backend は、サンドボックスを提供するランタイムを制御します。
"docker"(サンドボックス化が有効な場合のデフォルト): ローカルの Docker ベースのサンドボックスランタイム。"ssh": 汎用の SSH ベースのリモートサンドボックスランタイム。"openshell": OpenShell ベースのサンドボックスランタイム。
SSH 固有の設定は agents.defaults.sandbox.ssh 配下にあります。OpenShell 固有の設定は plugins.entries.openshell.config 配下にあります。
バックエンドの選択
| Docker | SSH | OpenShell | |
|---|---|---|---|
| 実行場所 | ローカルコンテナ | SSH でアクセス可能な任意のホスト | OpenShell 管理のサンドボックス |
| セットアップ | scripts/sandbox-setup.sh |
SSH キー + 対象ホスト | OpenShell Plugin が有効 |
| ワークスペースモデル | バインドマウントまたはコピー | リモート正準(初回のみシード) | mirror または remote |
| ネットワーク制御 | docker.network(デフォルト: なし) |
リモートホストに依存 | OpenShell に依存 |
| ブラウザサンドボックス | 対応 | 非対応 | まだ非対応 |
| バインドマウント | docker.binds |
N/A | N/A |
| 最適な用途 | ローカル開発、完全な隔離 | リモートマシンへのオフロード | 任意の双方向同期を備えた管理リモートサンドボックス |
Docker バックエンド
サンドボックス化はデフォルトでオフです。サンドボックス化を有効にしてバックエンドを選択しない場合、OpenClaw は Docker バックエンドを使用します。Docker デーモンソケット(/var/run/docker.sock)経由で、ツールとサンドボックスブラウザをローカルで実行します。サンドボックスコンテナの隔離は Docker 名前空間によって決まります。
ホスト GPU を Docker サンドボックスに公開するには、agents.defaults.sandbox.docker.gpus またはエージェント単位の agents.list[].sandbox.docker.gpus オーバーライドを設定します。この値は、たとえば "all" や "device=GPU-uuid" のように、Docker の --gpus フラグに別個の引数として渡され、NVIDIA Container Toolkit などの互換性のあるホストランタイムが必要です。
SSH バックエンド
OpenClaw に任意の SSH アクセス可能なマシン上で exec、ファイルツール、メディア読み取りをサンドボックス化させたい場合は、backend: "ssh" を使用します。
{ agents: { defaults: { sandbox: { mode: "all", backend: "ssh", scope: "session", workspaceAccess: "rw", ssh: { target: "user@gateway-host:22", workspaceRoot: "/tmp/openclaw-sandboxes", strictHostKeyChecking: true, updateHostKeys: true, identityFile: "~/.ssh/id_ed25519", certificateFile: "~/.ssh/id_ed25519-cert.pub", knownHostsFile: "~/.ssh/known_hosts", // Or use SecretRefs / inline contents instead of local files: // identityData: { source: "env", provider: "default", id: "SSH_IDENTITY" }, // certificateData: { source: "env", provider: "default", id: "SSH_CERTIFICATE" }, // knownHostsData: { source: "env", provider: "default", id: "SSH_KNOWN_HOSTS" }, }, }, }, },}仕組み
- OpenClaw は
sandbox.ssh.workspaceRoot配下にスコープごとのリモートルートを作成します。 - 作成または再作成後の初回使用時に、OpenClaw はローカルワークスペースからそのリモートワークスペースを一度シードします。
- その後、
exec、read、write、edit、apply_patch、プロンプトメディア読み取り、受信メディアのステージングは、SSH 経由でリモートワークスペースに対して直接実行されます。 - OpenClaw はリモートの変更をローカルワークスペースへ自動的には同期しません。
認証マテリアル
identityFile、certificateFile、knownHostsFile: 既存のローカルファイルを使用し、OpenSSH 設定を通じて渡します。identityData、certificateData、knownHostsData: インライン文字列または SecretRefs を使用します。OpenClaw は通常のシークレットランタイムスナップショットを通じてそれらを解決し、0600の一時ファイルに書き込み、SSH セッション終了時に削除します。- 同じ項目に対して
*Fileと*Dataの両方が設定されている場合、その SSH セッションでは*Dataが優先されます。
リモート正準の影響
これはリモート正準モデルです。初期シード後、リモート SSH ワークスペースが実際のサンドボックス状態になります。
- シード手順の後に OpenClaw の外部で行われたホストローカル編集は、サンドボックスを再作成するまでリモートには表示されません。
openclaw sandbox recreateはスコープごとのリモートルートを削除し、次回使用時にローカルから再度シードします。- SSH バックエンドではブラウザサンドボックス化は対応していません。
sandbox.docker.*設定は SSH バックエンドには適用されません。
OpenShell バックエンド
OpenClaw に OpenShell 管理のリモート環境でツールをサンドボックス化させたい場合は、backend: "openshell" を使用します。完全なセットアップガイド、設定リファレンス、ワークスペースモードの比較については、専用の OpenShell ページ を参照してください。
OpenShell は、汎用 SSH バックエンドと同じ中核 SSH トランスポートおよびリモートファイルシステムブリッジを再利用し、OpenShell 固有のライフサイクル(sandbox create/get/delete、sandbox ssh-config)と任意の mirror ワークスペースモードを追加します。
{ agents: { defaults: { sandbox: { mode: "all", backend: "openshell", scope: "session", workspaceAccess: "rw", }, }, }, plugins: { entries: { openshell: { enabled: true, config: { from: "openclaw", mode: "remote", // mirror | remote remoteWorkspaceDir: "/sandbox", remoteAgentWorkspaceDir: "/agent", }, }, }, },}OpenShell モード:
mirror(デフォルト): ローカルワークスペースが正準のままです。OpenClaw は exec 前にローカルファイルを OpenShell に同期し、exec 後にリモートワークスペースを同期し戻します。remote: サンドボックス作成後は OpenShell ワークスペースが正準です。OpenClaw はローカルワークスペースからリモートワークスペースを一度シードし、その後ファイルツールと exec は変更を同期し戻すことなく、リモートサンドボックスに対して直接実行されます。
リモートトランスポートの詳細
- OpenClaw は
openshell sandbox ssh-config <name>を使って、サンドボックス固有の SSH 設定を OpenShell に要求します。 - コアはその SSH 設定を一時ファイルに書き込み、SSH セッションを開き、
backend: "ssh"で使われるものと同じリモートファイルシステムブリッジを再利用します。 mirrorモードではライフサイクルだけが異なります。exec 前にローカルをリモートへ同期し、exec 後に同期し直します。
現在の OpenShell の制限
- サンドボックスブラウザーはまだサポートされていません
sandbox.docker.bindsは OpenShell バックエンドではサポートされていませんsandbox.docker.*配下の Docker 固有のランタイムノブは、引き続き Docker バックエンドにのみ適用されます
ワークスペースモード
OpenShell には 2 つのワークスペースモデルがあります。実際にはここが最も重要です。
mirror (ローカル正準)
ローカルワークスペースを正準のままにしたい場合は、plugins.entries.openshell.config.mode: "mirror" を使います。
動作:
execの前に、OpenClaw はローカルワークスペースを OpenShell サンドボックスへ同期します。execの後に、OpenClaw はリモートワークスペースをローカルワークスペースへ同期し直します。- ファイルツールは引き続きサンドボックスブリッジ経由で動作しますが、ターン間ではローカルワークスペースが信頼できる情報源のままです。
次の場合に使います:
- OpenClaw の外でローカルファイルを編集し、その変更をサンドボックスへ自動的に反映したい
- OpenShell サンドボックスをできるだけ Docker バックエンドと同じように動作させたい
- 各 exec ターンの後に、ホストワークスペースへサンドボックスの書き込みを反映したい
トレードオフ: exec の前後に追加の同期コストがかかります。
remote (OpenShell 正準)
OpenShell ワークスペースを正準にしたい場合は、plugins.entries.openshell.config.mode: "remote" を使います。
動作:
- サンドボックスが最初に作成されるとき、OpenClaw はローカルワークスペースからリモートワークスペースへ一度だけシードします。
- その後、
exec、read、write、edit、apply_patchはリモート OpenShell ワークスペースに対して直接動作します。 - OpenClaw は exec 後にリモートの変更をローカルワークスペースへ同期しません。
- プロンプト時のメディア読み取りは引き続き機能します。ファイルツールとメディアツールは、ローカルホストパスを仮定するのではなく、サンドボックスブリッジ経由で読み取るためです。
- トランスポートは、
openshell sandbox ssh-configが返す OpenShell サンドボックスへの SSH です。
重要な結果:
- シード手順の後に OpenClaw の外でホスト上のファイルを編集しても、リモートサンドボックスはその変更を自動的には認識しません。
- サンドボックスが再作成されると、ローカルワークスペースからリモートワークスペースが再びシードされます。
scope: "agent"またはscope: "shared"では、そのリモートワークスペースは同じスコープで共有されます。
次の場合に使います:
- サンドボックスを主にリモート OpenShell 側で保持したい
- ターンごとの同期オーバーヘッドを下げたい
- ホストローカルの編集でリモートサンドボックス状態が暗黙に上書きされることを避けたい
サンドボックスを一時的な実行環境と考える場合は mirror を選びます。サンドボックスを実際のワークスペースと考える場合は remote を選びます。
OpenShell ライフサイクル
OpenShell サンドボックスは、引き続き通常のサンドボックスライフサイクルで管理されます:
openclaw sandbox listは OpenShell ランタイムと Docker ランタイムの両方を表示しますopenclaw sandbox recreateは現在のランタイムを削除し、次回使用時に OpenClaw が再作成できるようにします- prune ロジックもバックエンドを認識します
remote モードでは、recreate が特に重要です:
- recreate はそのスコープの正準リモートワークスペースを削除します
- 次回使用時に、ローカルワークスペースから新しいリモートワークスペースをシードします
mirror モードでは、ローカルワークスペースはいずれにせよ正準のままなので、recreate は主にリモート実行環境をリセットします。
ワークスペースアクセス
agents.defaults.sandbox.workspaceAccess は、サンドボックスが何を見られるかを制御します:
none (デフォルト)
ツールは ~/.openclaw/sandboxes 配下のサンドボックスワークスペースを参照します。
ro
エージェントワークスペースを読み取り専用で /agent にマウントします(write/edit/apply_patch を無効化します)。
rw
エージェントワークスペースを読み書き可能で /workspace にマウントします。
OpenShell バックエンドでは:
mirrorモードは、exec ターン間の正準ソースとして引き続きローカルワークスペースを使いますremoteモードは、初期シード後の正準ソースとしてリモート OpenShell ワークスペースを使いますworkspaceAccess: "ro"と"none"は、書き込み動作を同じように制限します
受信メディアは、アクティブなサンドボックスワークスペース(media/inbound/*)へコピーされます。
カスタムバインドマウント
agents.defaults.sandbox.docker.binds は追加のホストディレクトリをコンテナへマウントします。形式: host:container:mode(例: "/home/user/source:/source:rw")。
グローバルバインドとエージェントごとのバインドはマージされます(置き換えられません)。scope: "shared" では、エージェントごとのバインドは無視されます。
agents.defaults.sandbox.browser.binds は追加のホストディレクトリをサンドボックスブラウザーコンテナにのみマウントします。
- 設定されている場合(
[]を含む)、ブラウザーコンテナではagents.defaults.sandbox.docker.bindsを置き換えます。 - 省略されている場合、ブラウザーコンテナは
agents.defaults.sandbox.docker.bindsにフォールバックします(後方互換)。
例(読み取り専用ソース + 追加のデータディレクトリ):
{ agents: { defaults: { sandbox: { docker: { binds: ["/home/user/source:/source:ro", "/var/data/myapp:/data:ro"], }, }, }, list: [ { id: "build", sandbox: { docker: { binds: ["/mnt/cache:/cache:rw"], }, }, }, ], },}イメージとセットアップ
デフォルトの Docker イメージ: openclaw-sandbox:bookworm-slim
デフォルトイメージをビルドする
ソースチェックアウトから:
scripts/sandbox-setup.shnpm インストールから(ソースチェックアウトは不要):
docker build -t openclaw-sandbox:bookworm-slim - <<'DOCKERFILE'FROM debian:bookworm-slimENV DEBIAN_FRONTEND=noninteractiveRUN apt-get update && apt-get install -y --no-install-recommends \ bash ca-certificates curl git jq python3 ripgrep \ && rm -rf /var/lib/apt/lists/*RUN useradd --create-home --shell /bin/bash sandboxUSER sandboxWORKDIR /home/sandboxCMD ["sleep", "infinity"]DOCKERFILEデフォルトイメージには Node は含まれていません。Skill が Node(または他のランタイム)を必要とする場合は、カスタムイメージに焼き込むか、sandbox.docker.setupCommand でインストールしてください(ネットワーク egress + 書き込み可能なルート + root ユーザーが必要です)。
openclaw-sandbox:bookworm-slim が見つからない場合でも、OpenClaw は通常の debian:bookworm-slim に暗黙に置き換えません。デフォルトイメージを対象にするサンドボックス実行は、ビルドするまでビルド手順を示して即座に失敗します。これは、バンドルされたイメージがサンドボックスの書き込み/編集ヘルパー用に python3 を含むためです。
任意: common イメージをビルドする
一般的なツール(例: curl、jq、Node 24、pnpm、python3、git)を含む、より機能的なサンドボックスイメージの場合:
ソースチェックアウトから:
scripts/sandbox-common-setup.shnpm インストールからは、まずデフォルトイメージをビルドし(上記参照)、その後リポジトリの scripts/docker/sandbox/Dockerfile.common を使って、その上に common イメージをビルドします。
次に、agents.defaults.sandbox.docker.image を openclaw-sandbox-common:bookworm-slim に設定します。
任意: サンドボックスブラウザーイメージをビルドする
ソースチェックアウトから:
scripts/sandbox-browser-setup.shnpm インストールからは、リポジトリの scripts/docker/sandbox/Dockerfile.browser を使ってビルドします。
デフォルトでは、Docker サンドボックスコンテナはネットワークなしで実行されます。agents.defaults.sandbox.docker.network で上書きします。
サンドボックスブラウザーの Chromium デフォルト
バンドルされたサンドボックスブラウザーイメージは、コンテナ化されたワークロード向けに保守的な Chromium 起動デフォルトも適用します。現在のコンテナデフォルトには次が含まれます:
--remote-debugging-address=127.0.0.1--remote-debugging-port=<derived from OPENCLAW_BROWSER_CDP_PORT>--user-data-dir=${HOME}/.chrome--no-first-run--no-default-browser-check--disable-3d-apis--disable-gpu--disable-dev-shm-usage--disable-background-networking--disable-extensions--disable-features=TranslateUI--disable-breakpad--disable-crash-reporter--disable-software-rasterizer--no-zygote--metrics-recording-only--renderer-process-limit=2noSandboxが有効な場合は--no-sandbox。- 3 つのグラフィックス強化フラグ(
--disable-3d-apis、--disable-software-rasterizer、--disable-gpu)は任意で、コンテナに GPU サポートがない場合に有用です。ワークロードが WebGL やその他の 3D/ブラウザー機能を必要とする場合は、OPENCLAW_BROWSER_DISABLE_GRAPHICS_FLAGS=0を設定してください。 --disable-extensionsはデフォルトで有効で、拡張機能に依存するフローではOPENCLAW_BROWSER_DISABLE_EXTENSIONS=0で無効にできます。--renderer-process-limit=2はOPENCLAW_BROWSER_RENDERER_PROCESS_LIMIT=<N>で制御され、0は Chromium のデフォルトを保持します。
別のランタイムプロファイルが必要な場合は、カスタムブラウザーイメージを使い、独自のエントリーポイントを提供してください。ローカル(非コンテナ)の Chromium プロファイルでは、browser.extraArgs を使って追加の起動フラグを付加します。
ネットワークセキュリティのデフォルト
network: "host"はブロックされます。network: "container:<id>"はデフォルトでブロックされます(namespace join のバイパスリスク)。- 緊急時の上書き:
agents.defaults.sandbox.docker.dangerouslyAllowContainerNamespaceJoin: true。
Docker のインストールとコンテナ化された Gateway はこちらにあります: Docker
Docker Gateway デプロイでは、scripts/docker/setup.sh でサンドボックス設定をブートストラップできます。そのパスを有効にするには、OPENCLAW_SANDBOX=1(または true/yes/on)を設定します。ソケットの場所は OPENCLAW_DOCKER_SOCKET で上書きできます。完全なセットアップと環境変数リファレンス: Docker。
setupCommand(一度だけのコンテナセットアップ)
setupCommand は、サンドボックスコンテナが作成された後に 一度だけ 実行されます(毎回の実行時ではありません)。コンテナ内で sh -lc 経由で実行されます。
パス:
- グローバル:
agents.defaults.sandbox.docker.setupCommand - エージェントごと:
agents.list[].sandbox.docker.setupCommand
よくある落とし穴
- デフォルトの
docker.networkは"none"(外向き通信なし)なので、パッケージのインストールは失敗します。 docker.network: "container:<id>"にはdangerouslyAllowContainerNamespaceJoin: trueが必要で、緊急時専用です。readOnlyRoot: trueは書き込みを防ぎます。readOnlyRoot: falseを設定するか、カスタムイメージを作成してください。- パッケージのインストールには
userが root である必要があります(userを省略するか、user: "0:0"を設定します)。 - サンドボックスの exec はホストの
process.envを継承しません。Skill API キーにはagents.defaults.sandbox.docker.env(またはカスタムイメージ)を使用してください。 agents.defaults.sandbox.docker.envの値は、明示的な Docker コンテナ環境変数として渡されます。Docker デーモンへアクセスできる人は、docker inspectなどの Docker メタデータコマンドでそれらを確認できます。そのメタデータ露出を許容できない場合は、カスタムイメージ、マウントされたシークレットファイル、または別のシークレット配信パスを使用してください。
ツールポリシーとエスケープハッチ
ツールの許可/拒否ポリシーは、サンドボックスルールより前に引き続き適用されます。ツールがグローバルまたはエージェントごとに拒否されている場合、サンドボックス化によってそれが再び使えるようになることはありません。
tools.elevated は、サンドボックス外で exec を実行する明示的なエスケープハッチです(デフォルトは gateway、exec ターゲットが node の場合は node)。/exec ディレクティブは承認済み送信者にのみ適用され、セッションごとに永続化されます。exec を強制的に無効化するには、ツールポリシーの deny を使用してください(サンドボックス vs ツールポリシー vs Elevated を参照)。
デバッグ:
- 有効なサンドボックスモード、ツールポリシー、修正用の設定キーを調べるには、
openclaw sandbox explainを使用します。 - 「なぜこれはブロックされているのか?」という考え方については、サンドボックス vs ツールポリシー vs Elevated を参照してください。
ロックダウンされた状態を維持してください。
マルチエージェントの上書き
各エージェントはサンドボックスとツールを上書きできます: agents.list[].sandbox と agents.list[].tools(さらにサンドボックスツールポリシー用の agents.list[].tools.sandbox.tools)。優先順位については、マルチエージェントのサンドボックスとツール を参照してください。
最小有効化例
{ agents: { defaults: { sandbox: { mode: "non-main", scope: "session", workspaceAccess: "none", }, }, },}関連
- マルチエージェントのサンドボックスとツール — エージェントごとの上書きと優先順位
- OpenShell — 管理されたサンドボックスバックエンドのセットアップ、ワークスペースモード、設定リファレンス
- サンドボックス設定
- サンドボックス vs ツールポリシー vs Elevated — 「なぜこれはブロックされているのか?」のデバッグ
- セキュリティ