2026 OpenClaw sessions_spawn とサンドボックス・セッションの切り分け：Macクラウドで再現可能な診断手順
ゲートウェイは動くが子プロセスやサンドボックス内処理で落ちる場合、原因はしばしばカレントディレクトリ、プロセスユーザー、権限、サンドボックス方針です。初回デプロイ、共通エラー、本番ハードニングと併読すると整理しやすいです。
1. 三つのパターン：ゲートウェイ稼働 ≠ セッションspawn成功
初回デプロイと共通エラーまで終わったあと、次に紛れやすいのは「プロセスは動いているのに、セッション生成やサンドボックス内コマンドだけが落ちる」ケースです。ログに sessions_spawn やサンドボックス関連の語が出るときは、ポート18789のリスンとは別のコードパスを疑ってください。本番ハードニングと併読すると、方針とパスの両方を同じ表で整理できます。
- cwdと設定パスのズレ：対話SSHでは
~/projectにいるのに、launchd 起動のゲートウェイは/や別ユーザのホームになる。子プロセスは空のcwdや書き込み不可のcwdを継承し、spawn段階で失敗する。macOSのAPFSはデフォルトで大小文字を区別しないため、Linux由来のパスを誤コピーすると「たまに失敗」に見える。 - UID/GIDとファイル所有者の不一致：
openclaw.jsonを編集したあと、プロセスユーザとキャッシュ／リポジトリの所有者が食い違うと、サンドボックス内の書き込みや実行が拒否される。手動gateway startと launchd では実ユーザが違うと「偶発」に見えるが、入口が違うだけである。 - サンドボックス方針とチャネル能力の不一致：出域制限・子プロセス制限・ワークセット制限を締めると、正当な自動化も止まる。ゲートウェイ側ログが「spawn error」だけだとアプリバグに見えがちだが、実際は方針の組み合わせであることが多い。
切り分けのベンチマークとして、冷起動後にlaunchdだけでゲートウェイを上げたとき、最初のspawn成功までの時間を測るとよいです。SSHに入ると直るなら、入口か環境変数の継承が壊れています。方針を厳しくしたあとspawn遅延だけが悪化するなら、CPUよりもシステムコール回数とI/O待ちを見てください。
2. 症状分岐表：セッション／ゲートウェイ／ポート
同時に認証・ポート・サンドボックスをいじると、どの層が効いたか分からなくなります。「通常違う」列で早い段階で誤爆を避けてください。
| 観察 | まず疑う | 確認 | 通常違う |
|---|---|---|---|
doctorは成功、タスクでspawn／sessionエラー | セッション／サンドボックス／パス | 同一ユーザで最小コマンドを再現、cwdと設定パスを照合 | 単なる18789占有（listen前に落ちていない場合） |
| クライアントがUnauthorized／Token | ゲートウェイ認証 | openclaw config get 系で gateway.auth をドキュメントと突合 | ディレクトリchmod（トークンファイルが読めない場合を除く） |
| ゲートウェイが起動しない／即終了 | ポート・環境・依存 | lsof -i :18789、メモリ、Nodeバージョン | サンドボックス業務ロジック（セッション層に未到達） |
| 特定種類のタスクだけ失敗（書き込み・スクリプト等） | 方針またはパス許可 | 一時的に緩めて差分比較、ハードニング文を参照 | チャネルプラグイン単体（先にOS層を潰す） |
| アップグレード直後に変化 | 設定キー移行・デフォルト厳格化 | リリースノートと旧 OPENCLAW_* の対応表 | ランダムな不安定さ（多くは設定ドリフト） |
3. 再現可能な診断手順（5＋回帰）
本番と同じUnixユーザでゲートウェイを動かす前提です。SSHユーザとlaunchdユーザが違う場合は、先にそこを揃えてください。
- 起動入口の固定：launchd／手動／プロセス管理のどれで上げているかを文書化。切り替え前に
openclaw gateway stopとlsof -i :18789で二重起動を潰す。 - 最小再現：本番と同じ
cwdで、ドキュメントの最小セッション／タスク例だけを実行。SSHでは通るがlaunchdでは落ちるなら、環境継承の欠陥を疑う。 - 権限と所有者：エラーに出たパスへ
ls -le（ACLはmacOSで重要）。必要なら単一所有者で状態ディレクトリを作り直し、uid/gidをRunbookに残す。 - ログの分離：OpenClawのログと、統合ログ（下例）の拒否を別々に見る。アプリが「spawn失敗」と言い、カーネルが無言ならユーザ空間に留まる。
- 設定diff：アップグレードやマージ後に
openclaw.jsonを構造化diffし、サンドボックス・パス・envブロックを重点確認。 - 回帰：
doctor→最小セッション→実タスク→24時間の定期トリガで観測。
launchctl print gui/$(id -u) 内のplistに WorkingDirectory があるか確認してください。無いと子プロセスのcwdが空になり、spawnが静かに壊れます。Macクラウドで長期運用するなら、「入口＋cwd＋所有者」をCIと同じレベルでRunbook化し、口頭の「前はSSHで起動した」に頼らないことが重要です。
4. 測定可能な技術情報
① プロセス身分：launchdはログインシェルより環境が少なく、PATHにHomebrewが入らず「見えるバイナリが書けない」パターンが出る。② APFS：大小文字の取り違えと、Linuxからの同期でのパス重複。③ メモリ：初期化で一時的にRSSが跳ね、2GB未満の小さなインスタンスではOOM（終了コード137）がspawn失敗に見える。④ 並行：同一状態ディレクトリを二つのゲートウェイが奪うと、セッションエラーに見える競合が起きる。⑤ 監査：サンドボックスを締めるたびに変更一行を残し、ロールバックを証跡付きで行う。
5. コンテナ任せからネイティブmacOSのセッション基盤へ
DockerやリモートLinuxでもデモはできますが、ボリューム権限・ユーザー名前空間・シグナル挙動の差で、調査対象が二重化します。sessions_spawn が実パスに触れると、コンテナとホストのどちらが悪いかの議論が先に立ちます。ノートPC常駐も、スリープ・VPN・ホーム配下の変化で再現性が壊れます。
本番でネイティブmacOSの挙動・安定UID・書き込み可能な状態ディレクトリ・7×24稼働が欲しいチームには、専用のMacクラウド上でOpenClawを動かす方がレイヤーが少なく済みます。汎用Linux VPSのサポートはWeb向けRunbookが中心で、launchd＋ファイル所有者＋Keychain前提の切り分けは薄いことが多いです。
VPSMACのM4 Macクラウドを借り、launchdでユーザとWorkingDirectoryを固定し、サンドボックス方針とゲートウェイ設定を同じリポジトリで管理すれば、spawn／セッション問題を単一OSの意味論に閉じ込められます。
6. FAQ
spawnは失敗するがゲートウェイは生きている。何から？
まずcwd・ユーザー・所有者。本番と同じ起動経路で pwd を取り、plistのWorkingDirectoryと一致させる。最小のspawn例を同一ユーザで実行し、SSHとlaunchdで env の差分を比較してください。
アップグレード直後だけ壊れた
よくあります。キー名変更・デフォルト厳格化・サンドボックスブロックの移動で、openclaw.json のdiffが本丸です。リリースノートの OPENCLAW_* 移行表と、ハードニング文の方針ブロックを照合してください。
同一ホストに複数インスタンス
状態ディレクトリを共有しないでください。設定ルート分離・ポート分離・ホスト分離のいずれかを。サイレント二重起動は「レースのような」セッションエラーの典型原因です。