Docker / Compose では OpenClaw Gateway は起動できても、Agent サンドボックス を有効にすると、コンテナ起動失敗、ワークスペースが読取専用で書けない、サンドボックスにコマンドが無い、ビルド中に 137 の OOM で落ちる といった症状が出ます。本文は 2026 年の主流導入を、実行順に 止→起→検証→手当 に整理し、主要キー、docker.user とのボリューム権限の揃え方、イメージ構築と OOM 分岐表 と、既掲の Docker／ボリューム／doctor 記事の切り分けにします。読み終えた時点で、悪いイメージ、マウント UID 問題、リソース上限とログ上の合言葉の違いを区別できます。
多くの場合、原因は プロセス境界 にあり、破損したインストールではありません。
brew install した物が、追加マウントや層の無い限り、サンドボックスの PATH には乗りません。501:20 なのに、コンテナ内のプロセスが 1000:1000 で走ると、Permission denied や EROFS として出る読み取り・書き込み拒否が多いです。| モード | 向き | 支払う代償 | 誤解しやすい点 |
|---|---|---|---|
| Docker サンド | 信頼できないシェルやスクリプト を厳格に分離し、「清潔な」環境を再現する | イメージ容量、取得やビルド、UID や GID やボリュームの揃い | ホストのツールが引き継がれると思い込む |
| SSH ・リモート | ツールチェーン揃いの、信頼できるリモート Mac 上に直接出す | 露出面と口座まわりが大きい | 自機をサンド化したとみなし監査を忘れる |
| サンドなし ・ 全ローカル | 内網、低危険、手早い切り分け | モデル経由のコードを実行する時の危険が高い | CI や本番でも常に止める |
agents.defaults.sandbox.docker と sandbox-setup.sh概念上は二層です。どのサンド実装を使うか（イメージとランタイム）と、イメージをどこから来させるか です。公式リポジトリでは多くの場合、ホスト上の docker CLI から扱えるイメージを 事前にビルド・取得 する scripts/sandbox-setup.sh（手元の版の名前）が出ます。設定上 agents.defaults.sandbox.docker.image は セッションを回すイメージ です。両者が食い違うと、Gateway からは有効に見えて docker run が manifest not found や pull access denied になる、といった典型例があります。
他記事との分業は？ OPENCLAW_IMAGE や Control UI で行き詰まるなら、まず 公式 Docker 一括と GHCR イメージ へ。データのボリューム・権限・永続化・ Skills パス で行き詰まるなら、Docker ボリュームと権限のチェックリスト を参照してください。本稿は サブシステムのサンドと OOM/137 だけ扱います。
docker.user と OPENCLAW_HOME マウント：症状に合わせ、乱 chmod 777 は止める推奨手順は次のとおりです。
docker.user を、ボリュームに一致して書き込み可能な UID:GID に揃える（文書上のキー名に従い、版によっては sandbox.docker 配下）。chown を禁じているなら、コンテナに渡す下位ディレクトリを調整し、丸ごと磁盤に広げない。Linux とリモート Mac の差分として、名前付きと bind、SELinux ラベル（版によって）は「Compose では合っているのにコンテナ内で壊れている」を増幅します。モデルの会話で当てずっぽうをせず、Gateway／サンド起動ログの 先頭 I/O エラー行 を採ることが重要です。
PATH 上のディレクトリ に入っているか。サンドへ docker exec し command -v した方が、口語より信頼できます。~/.cache 等、ホストの 読取専用 bind を要するか。要るなら、手当てでホストを雑多に通すのではなく、イメージや共通体にキャッシュを乗せる方を檢討する。HTTP(S)_PROXY が要る失敗を command not found と取り違えやすいです。exit 137：Docker 内の「殺された」と「足りない」137 = 128 + 9 (SIGKILL) は多くの場合 OOM キラーを連想しますが、人間の docker kill や cgroup によるメモリ上限 もあり得ます。分岐では少なくとも、失敗が docker build なのか docker run なのか、エンジン上で 並行ビルド がデスクトップや VM のメモリを潰していないか、リモート Mac では 実在の空きとスワプ、単一コンテナの制限ばかり見ていないか、を併せます。別枠に、本文は多いのに exit 1 か 2 である Cannot allocate memory 列も、メモリや一時磁盤と同じ表に乗せ、モデル側のパラメータ遊びだけに閉じない方が安全です。
「ビルド時 OOM」でよい順序は、並行を落とす（--parallel 等）こと、多段でコンパイルの山を下げること、Docker VM の枠を上げること、大きめのメモリ帯域の専有リモート Mac へ乗り換えて 安定基盤 にする、等です。ノートに複数 IDE ・ ローカル大模型 ・ Docker が一度に乗り切った、とは別物です。既に共有ストレージのチームは、inode や小ファイル が OOM めいた固まり方を起こしがちで、要ればボリューム分けと掃除方針を変えてください。
sandbox-setup を走らせてビルドまたは取得し、設定と一致する イメージ名と ID を控える。docker.user とマウント の A/B は一度に一変数。差分を残し、三箇所同時変更で戻せない状態にしない。{
"agents": {
"defaults": {
"sandbox": { "mode": "docker" },
"docker": { "user": "1000:1000" }
}
}
}
// 本番では sandbox.docker 配下など実プロジェクト向け。openclaw doctor ／ 公式文書を参照
docker events かエンジンログ、ホストの memory pressure も併せて書き、事業上の OOM と docker build 並行の OOM を一緒に混ぜない。chown -R 1000:1000 と、家全般を動かす事は危険度が違います。依頼票と戻し点を付ける。pip 索引、永続なしの繰返し配信は、「一度通る」と「百通る」のコストを大きく開けます。容量レビューに 先頭起動時間 の数字を置きます。多くの場合、同時のメモリと I/O の山 と、再現可能な環境境界 で止まります。昨日通ったのは並行の谷が合ったからで、生産的な Agent では 137 と書き出し拡大が一緒に来ることが多いです。7×24 の Gateway ＋ サンド を要するなら、専有の Apple Silicon クラウド、明確な磁盤とログ、見通しの利く期間 の方が扱いやすい条件です。そこで MACCOME リモート Mac クラウド を OpenClaw 常設の土台 にすると、ローカル環境の当てずっぽうに奪われる時間を減らし、ツールチェーンと納品へ回せます。
よくある質問
サンドボックス内でホストに入れたコマンドが見つかりません。どうすればよいですか。
イメージに焼き込み か、層を重ね、あるいはポリシーに従い追加のディレクトリをマウントし PATH を更新します。MCP/Skills 検証 の「Gateway での見え方」と同じ心持ちで、境はコンテナ内です。
exit 137 なら必ず OOM ですか。
必ずしもそうではありません。cgroup ・ システム OOM ・ 手動 kill を分け、少なくとも同時刻のエンジンと系のメモリ傾向を併せます。日次の入り方としては、公式 doctor/無反応分岐 の読み方が先にあります。
先にサンドを付けるか、大きいメモリの Mac クラウドにするか。
まず 隔離が要るのか、容量不足なのか を最小再現で示す。137 が Docker やホストの枠拡大で消えるのはリソース。常に信頼不能なコードを要するのならサンドと統制。公表の Mac クラウド レンタル価格 も併せて、注文用シンガポール ページ で地域注文の目安にしてください。