Hermes Agent のインストールには必ず sandbox 設定があって、それが shell コマンドが実際にどこで実行されるかを決める。これは重い選択だ：悪いコマンドの爆発半径、エージェントの体感速度、稼働 1 時間あたりの支払いが全部ここで決まる。
Hermes は 7 つのバックエンドを積んでいる。README が並べているのは local、docker、ssh、singularity、modal、daytona、vercel。v0.14.0 が Vercel Sandbox を足してこの面子が揃った。判断のための決定木を書く。
一枚の表で 7 つを俯瞰
| バックエンド | 隔離 | レイテンシ | コスト | 永続性 | 向いている用途 |
|---|---|---|---|---|---|
| local | なし | <10 ms | 無料 | あり（自分のディスク） | 使い捨て VM で一人で書く |
| Docker | コンテナ | 約 50 ms | 無料 | コンテナ単位 | あらゆる開発機の既定 |
| SSH | 遠隔側の強度に従う | 遠隔レイテンシ | 遠隔費用 | あり | エージェントが他人の箱で走る |
| Singularity | HPC コンテナ | 約 100 ms | 無料 | コンテナ単位 | HPC クラスタ、科学計算 |
| Modal | サーバレスコンテナ | コールド約 200 ms | 稼働秒課金 | snapshot 可 | バースト計算、GPU 仕事 |
| Daytona | サーバレスワークスペース | コールド約 300 ms | 稼働秒課金 | アイドル時に休眠 | 長生きするエージェント環境、アイドルコストほぼゼロ |
| Vercel Sandbox | サーバレスコンテナ | コールド約 200 ms | 稼働秒課金 | 一時的 | Web ツーリング、JS 重めのワークフロー |
local と docker は無料で、自分のマシンで走る。残り 5 つは別の場所で走る——レイテンシと金を払って、代わりに何かを買っている。
一つずつ：いつどれを選ぶか
local——「このマシンでこのエージェントを信用している」
エージェントは自分のファイルシステム上、自分のユーザ権限で直接コマンドを走らせる。隔離はゼロ。 エージェントが rm -rf ~/code を選んだら、本当に消える。プロンプトインジェクションがツール出力経由で入ったら、注入されたコマンドはそのまま実行される。
これが正解になる条件：使い捨て VM で書いていて、エージェントの作業は自分の手作業と同じ爆発半径しか持たず、レイテンシをゼロに張り付かせる方が安全マージンより大事。
これが間違いになる条件：それ以外のほぼ全部。
docker——正しい既定値
自分のマシン上のコンテナ、Linux namespace で隔離されている。エージェントが見るファイルシステムはコンテナのもので、本物の /home はマウントしない限り見えない。
hermes config set sandbox docker と hermes setup でイメージを取得・設定する。それ以降、shell ツール呼び出しはすべてコンテナを経由する。
これがユーザの 80% にとって正しい既定値だ。 レイテンシのオーバーヘッド（コマンドあたり約 50 ms）はチャットの体感には乗らない。隔離は十分に強く、rm -rf / してもコンテナのビューが消えるだけで、コンテナ自体が使い捨て。デバッグが必要なら docker exec で入れる。
ssh——「エージェントは別の箱に住んでいる」
エージェントの shell ツールは SSH で遠隔ホスト上で実行される。ローカルの Hermes プロセスはクライアントで、仕事は遠隔側で起きる。
これが正解になる場面：エージェントがやる仕事が本来遠隔に属する——サーバへのデプロイ、本番ログのデバッグ、マイグレーションの実行。ローカルのサンドボックスは要らない、ホストがサンドボックスだから。
遠隔ホストは「エージェントに shell アクセスを許してよい」相手でなければいけない。SSH の資格情報は本番の資格情報と同列に扱う——実際に同じものだ。
singularity——HPC クラスタ
Singularity（現 Apptainer）は HPC クラスタが実際に使うコンテナランタイムだ——Docker はホスト側で root を要求するが、HPC 環境ではそれを与えられない。研究クラスタで Hermes を走らせていて、SLURM スケジュール、Docker なし、GPU が大量にあるなら、これが正解。
「HPC」や「Singularity」という言葉に聞き覚えがないなら、この節は飛ばしていい。
modal——バースト計算、特に GPU
Modal はサーバレスコンテナのプラットフォームだ。Hermes はコマンドごと（あるいはセッションごとに再利用しつつ）Modal コンテナを立ち上げ、コマンドを走らせ、片付ける。稼働計算秒で課金される。GPU 階層もある。
Docker を上回る条件：エージェントが GPU を必要とする、あるいはローカル機を超える計算資源が要る。他のサーバレスを上回る条件：コールドスタートが約 200 ms で、チャットペースのツール利用に堪える；snapshot もそこそこ効いて、セッション中の状態が保たれる。
daytona——長生き、アイドルほぼゼロ
Daytona の決め手は休眠だ。エージェント環境は何も起きていない間は眠り、要求が来ると数百 ms で目覚める。支払いは稼働秒のみ、アイドル秒には払わない。
実際の効果：自分の dotfiles、自分の skill、進行中の作業を抱えた「マイ Hermes」環境を、ほぼゼロコストで数ヶ月生かしておける——使っているときだけ払うから。
これが正解になる場面：ラップトップに居着かないが「どこかに住んでいる」エージェントが欲しい。長いアイドル後の最初のリクエストは約 300 ms で目覚め、その後はコンテナ速度。
vercel——Vercel Sandbox（v0.14.0）
最新のバックエンドで、v0.14.0 で追加された。Modal と同じサーバレスコンテナモデル、ただし Vercel のインフラ上に乗る。デプロイ先がすでに Vercel なら、エージェントのサンドボックスを同じプロバイダに揃えるのが摩擦最小。
得意領域：JS 重めのワークフローで、エージェント環境を本番のデプロイ環境と揃えたいとき。
切り替え方
hermes config set sandbox docker
# あるいは：local、ssh、singularity、modal、daytona、vercel
資格情報が要るバックエンド（ssh / modal / daytona / vercel）には hermes setup が質問してくる。ドキュメント通り hermes config set で直接設定してもいい。
セッション単位で一時的に上書きもできる：hermes --sandbox modal で GPU が要る単発作業を走らせ、終わったら既定の sandbox に戻る、という感じだ。
サンドボックスを完全に切るのは？
サンドボックスを完全に無効化することはできる（local バックエンド）が、Hermes はその上にコマンド承認ワークフローを重ねる：rm -rf、curl | sh、/etc を触るような危険コマンドは、実行前に明示的に承認を求めてくる。v0.14.0 はこの層を強化していて、3 つの dangerous-command バイパスを閉じ、sudo ブルートフォースのブロックを追加した（#23736, #26829）。だから local でさえ「何もない」わけではない——「より軽い隔離 ＋ 本物のプロンプト」だ。層ごとの分解はセキュリティモデルの記事を見てほしい。
結論——実際の推奨
ほとんどの人、ほとんどの時間：Docker。
エージェントをラップトップ以外のサーバに住ませたい：Daytona（アイドル時休眠は本当に魔法のように効いて、コスト計算も合う）。
GPU 仕事がある、あるいはエージェントが本物の計算をしている：Modal。
クラスタで研究している：Singularity。
local はトレードオフを理解した上で。SSH は仕事が遠隔に属するときだけ。Vercel はすでに Vercel に乗っているなら。