Execution backends
ファイルシステムに触れる、あるいはコマンドを実行するツールは、すべて実行バックエンドを通ります。その処理が どこで 起きるかを決めるのがバックエンドです。ツール群そのものは変わりません。read_file、shell、grep、git_commit などは、あなたのラップトップで動こうと、コンテナの中で動こうと、ネットワークの向こうのホストで動こうと、まったく同じように振る舞います。
Switching
/backend
/backend local
/backend docker {"image": "python:3.11-slim"}
/backend ssh {"host": "10.0.0.5", "user": "build", "key": "~/.ssh/id_ed25519"}引数なしの /backend は現在のバックエンドを表示します。変更はセッションに即座に適用され、すでに進行中の作業についても次のツール呼び出しから効きます。プロジェクトは <project>/.snowpea/settings.json の backend でデフォルトを指定できます。
local
デフォルトです。コマンドはあなたのユーザーとして、セッションの作業ディレクトリで、あなたの環境のまま実行されます。何も隔離されません。自分のコードを触っているときに使いたいバックエンドであり、auto モードのジョブを向けてはいけないバックエンドです。
docker
/backend docker {"image": "python:3.11-slim"}| Key | Default | Meaning |
|---|---|---|
image | python:3.11-slim | コンテナを作る元のイメージ |
workdir | セッションの作業ディレクトリ | 同じ絶対パスでバインドマウントされます |
コンテナはセッションにちなんだ名前を持ち、最初のツール呼び出しで遅延生成され、セッションが閉じると削除されます。作業ディレクトリは同じ絶対パスにバインドマウントされるので、モデルが考えるパスは内側でも外側でも同じです。それ以外 — インストール済みパッケージ、ネットワーク、環境 — はコンテナのものです。
auto モードにはこれが正しいバックエンドです。エージェントは好きなものをインストールし、好きなものを壊してよく、あなたはコンテナを捨てるだけです。
Docker デーモンが動いている必要があります。動いていない場合、バックエンドは黙って local にフォールバックするのではなく、失敗として報告します。
ssh
/backend ssh {"host": "10.0.0.5", "port": 22, "user": "build", "key": "~/.ssh/id_ed25519"}| Key | Meaning |
|---|---|
host | ホスト名またはアドレス |
port | デフォルトは 22 |
user | リモートのユーザー |
key | 秘密鍵のパス |
password | key の代わり |
cwd | リモートの作業ディレクトリ。デフォルトはリモートのホームディレクトリ |
コマンドは SSH 越しに実行され、ファイルの読み書きは SFTP を通ります。エージェントが書いたファイルはリモートホストにだけ存在します。ローカルには何もミラーされず、ssh バックエンドでの write_file はあなたのディスクに一切触れません。鍵認証を強く推奨します。セッション設定の中のパスワードは、設定ファイルの中のパスワードです。
Checking where you are
正直な確認方法は、こう尋ねることです。
snowpea -c "run hostname and tell me what it printed"local ならあなたのマシン、docker ならコンテナ ID、ssh ならリモートホストになります。エージェントのファイルシステムに対する見方はすべてバックエンド越しなので、これはエージェントが間違えようのない事実です。
What does not move
バックエンドが覆うのはツールの実行であって、デーモンではありません。セッション、メモリ、承認の待ち行列、スケジューラ、ゲートウェイは、セッションがどのバックエンドを使っていても、あなたのマシンのデーモンに留まります。ネットワーク系のツール — web_search、web_extract、ブラウザツール、メディアツール、MCP サーバー — はバックエンドのホストではなく、デーモンから実行されます。
Next
Headless — これらすべてをスクリプトから使う。