clawk

コーディングエージェントは、実際に何かを実行させることを許可したときだけ役に立ちます。パッケージのインストール、生成したコードの実行、サーバーの起動、ネットワークの利用などです。自分のマシンでは、これには2つの悪い選択肢しかありません。すべてのコマンドを承認する（そして数秒ごとにプロンプトを監視する）か、--dangerously-skip-permissions を実行して、重要なものが rm -rf やトークン漏洩の一歩手前でないことを祈るかです。

clawkは第三の選択肢です。リポジトリに cd して clawk と入力すると、Claude Code（またはCodex、pi、シェル）が使い捨てのLinux VM内で動作します（コードはマウントされ、ゲスト内ではroot、権限プロンプトなし）。一方、あなたのファイル、キーチェーン、その他のマシン環境には一切触れられません。エージェントはあなたのマシンではなく、専用のマシンを手に入れるのです。

_{1つのコマンドで動作するエージェントを起動; 未知のサーバーへのデータ送信の試みは、ネットワーク許可リストによってブロックされる; clawk attach で後でセッションを再開。}

境界は、エージェントが説得されて破られる可能性のあるプロンプト内のルールではありません。それは独立したマシンであり、開かれた経路はあなたがマウントしたものだけです。サンドボックス内のシェルから:```console $ curl https://tracker.evil.example # not on the allow-list: blocked curl: (7) Failed to connect to tracker.evil.example port 443 after 2 ms: Connection refused

$ cat ~/.ssh/id_rsa # your keys never entered the VM cat: /home/agent/.ssh/id_rsa: No such file or directory

$ git push # ...yet this works: ssh-agent is forwarded Enumerating objects: 5, done.

正直に言うと、許可リストは*未知の*サーバーへの接続をブロックするものであり、許可したサーバーへの接続をブロックするものではありません。github.comは事前に許可されており、転送されたssh-agentはプッシュできるため、エージェントが読み取れるものはすべて公開され得るものとして扱ってください。[セキュリティモデル](#security-model-and-its-limits)にその詳細が明記されています。

また、エージェントがVMを壊してしまった場合は、`clawk destroy && clawk`を実行してください。新しいVM、同じリポジトリ、そして`--resume`で会話が復元されます。

> [!IMPORTANT]
> **1.0以前であり、急速に進化しています。** リリース間で破壊的な変更や、時折の粗い部分が発生することを想定してください。物事は壊れる可能性があり、実際に壊れます。問題を報告してください。そのフィードバックが1.0を形作っています。

## ハイライト

- **エージェントに何でもさせる。** 制限付きネットワークを持つ使い捨てVM内で実行されるため、`rm -rf`、パッケージインストール、信頼できないコードがホスト、ファイル、明示的に共有していないものに到達することはありません。
- **1つのコマンドで動作。** リポジトリに`cd`して`clawk`を実行するだけです。Dockerfile、devcontainer、セットアップファイルは不要です。初回起動時にイメージからrootfsを構築し、以降の起動は数秒で完了します。
- **何も失わずに壊せる。** 自由に破棄して再作成できます。コードとエージェントの会話はホスト上に残ります。破棄されるのは使い捨てVMディスクだけです。
- **本物のLinuxボックス、あなたのツールチェーン。** 任意のOCIイメージがrootfsになります。プロジェクトに必要なツールが正確に揃った完全なOSです。Dockerデーモンは不要です。
- **シークレットはマシン上に留まる。** 送信トラフィックは許可リストで制限され、ssh-agentが転送されるため、キーがVMに入ることなく`git push`が機能します。
- **プロジェクトまたはチケットごとにサンドボックス。** 複数を同時に実行できます。マルチリポジトリのチケットでは、リポジトリごとにgit worktreeが作成され、調整されたPRが生成されます。アイドル状態のVMは自動的にメモリを解放してディスクにサスペンドするため、忘れられたサンドボックスのコストは（ほぼ）ゼロです。

## なぜVMなのか？

clawkは、自律型コーディングエージェントのための汎用ローカル環境です。VMがポイントです。それはエージェントが所有できるマシン全体であり、使用中のマシン上でポリシーに包まれたプロセスではありません。

- **独立したカーネル。** ゲストは独自のLinuxカーネルを実行するため、ホストのファイルシステムは拒否ルールの背後に隠されているのではなく、そもそもマウントされていません。
- **従来のLinux環境。** 標準的なカーネル、標準的なユーザーランド、`/dev/kvm`に沿った期待値。これにより、ツールはsyscallフィルタの驚きなしに、ドキュメントどおりに動作します。
- **ゲスト内でのroot権限。** システムパッケージのインストール、`/etc`の編集、モジュールのロード、特権ポートへのバインドが可能です。再構成できるのはエージェントのボックスです。
- **使い捨てのライフサイクル。** 壊すのは安価で、再作成は迅速です。壊れたVMは`clawk destroy && clawk`を実行するだけで、リポジトリと会話はホスト上でそのまま残ります。
- **ホストからのより強力な分離。** 分離はプロセスサンドボックスポリシーを正確に設定することではなく、ハイパーバイザーの境界に依存します。

この組み合わせにより、制限付きプロセスサンドボックスが妨げがちなワークロードを実行できます。

- パッケージとネイティブ依存関係のインストール。
- バックグラウンドサービス（データベース、キュー、開発サーバー）の実行。
- 信頼できないビルドとテストのフルスピードでの実行。
- 実マシンを期待するシステムレベルのLinuxツールの使用。
- そして、対応ハードウェア上でKVM対応ゲストカーネルを使用すると、DockerやKindなどのコンテナおよびKubernetes開発ワークフローをサンドボックス*内*で実行できます。これはオプトインであり、ハードウェアに依存します。正確な要件は[イメージ](https://github.com/clawkwork/clawk/blob/main/docs/images.md#guest-kernel-override)を参照してください。

これらは*製品*ではありません。clawkは一般的なローカルエージェント作業のためのものです。DockerとKubernetesは、「サンドボックス化されたプロセスではなく、実マシンが必要」という最も顕著な例にすぎません。

## インストール

Appleシリコン上のmacOS 14+が必要です。（Linuxはfirecracker経由でサポートされており、現在は実験的です。セットアップ、ワークフロー、ギャップをカバーする**[docs/linux-quickstart.md](https://github.com/clawkwork/clawk/blob/main/docs/linux-quickstart.md)**から始めてください。このREADMEはmacOS優先です。）```sh
brew install clawkwork/tap/clawk

ソースから（コントリビューター、またはHomebrewを使用しない場合）、Go 1.26+が必要です：```sh git clone https://github.com/clawkwork/clawk && cd clawk make install

どちらにせよ、追加のホストツールは不要です。Dockerもqemuもsudoもありません。ハイパーバイザーはAppleのVirtualization.frameworkで、バイナリにリンクされており、リリースバイナリにはゲスト内エージェントがプリビルドで同梱されています。そのため、Goツールチェーンが必要になるのはソースからビルドする場合だけで、その場合はすでに持っているはずです。初回実行時には不足しているものがないか確認し、修正を提案します。

**アンインストール:** `clawk destroy` でサンドボックスを破棄し、`rm -rf ~/.clawk` を実行してから、`brew uninstall clawk` でバイナリを削除します（ソースインストールの場合は `$GOBIN` から削除します）。他にインストールされたものはありません。launchdジョブもなく、サンドボックスごとのデーモンはVMとともに終了する通常のプロセスです。

## クイックスタート

日常的なケース、現在いるディレクトリ用のサンドボックス:```sh
cd ~/code/my-project
clawk                      # boot a sandbox for this dir + attach claude
clawk run shell            # drop into a shell in the same sandbox
clawk run codex            # or another agent: codex, pi, opencode, shell
clawk down                 # stop the VM (repo + agent state persist)
clawk attach               # come back later — boots if stopped, reattaches claude
clawk destroy              # remove the VM (conversation history is kept)

共通オプション:```sh clawk run claude -- --resume # pass args through to the agent clawk forward add my-project 3000 # expose a guest dev server on localhost:3000 clawk network allow my-project api.example.com

複数のリポジトリにまたがるチケットを担当していますか？1つのコマンドで、各リポジトリに新しいブランチ上のgit worktreeを持つサンドボックスを作成し、後で`clawk pr`を実行すると、変更された内容に対して相互リンクされたPRが開かれます。```sh
cd ~/code/my-workspace     # contains a clawk.mod listing the repos
clawk work INFRA-123       # one sandbox, a worktree per repo, claude attached
clawk pr INFRA-123         # push branches + open one PR per repo

チケットのライフサイクル全体（ステータス、マージ後のフォローアップブランチ、リベース）は docs/ticket-mode.md にあります。

ヒント: Claude Codeを使っていますか？ claude setup-token を実行してから clawk auth set-token を一度実行すれば、すべてのサンドボックスがログイン済みの状態で起動し、/login も並列サンドボックス間のログイン競合も不要になります。詳細は docs/claude-auth.md を参照してください。

何が何を生き残るか

永続性を支配するルールは1つです: VMは使い捨てであり、失いたくないものはすべてホスト上に置かれます。

	clawk down	clawk destroy
あなたのリポジトリ（マウントされたワークツリー、コミット、ブランチ）	✅	✅
エージェントの状態（Claude/Codex/pi/opencodeの会話、メモリ）	✅	✅
VMディスク（aptインストール、キャッシュ、$HOME）	❌（起動のたびに新しく再構築*）	❌（それが目的）

* 例外が2つあります: clawk snapshot を再開するとディスクとメモリが中断時とまったく同じ状態に復元され、Linux/firecrackerプロバイダーはdestroyまでディスクを保持します。起動のたびに必要なツールはイメージ（vm ( image … )）に含めるべきであり、起動ごとのセットアップは on up フックに属します。

エージェントの状態はサンドボックスごとにホストにマウントされます: 各ランナーのホームディレクトリ — claudeの ~/.claude/、codexの ~/.codex/、piの ~/.pi/、opencodeの2つのXDGディレクトリ — はホスト上の ~/.clawk/namespaces/default/state/<name>/ に置かれ、再作成されたサンドボックスは --resume で以前の会話を引き継ぎます。このマウントこそが約束を現実のものにします: VMディスク自体は起動のたびにイメージから再クローンされるため、ランナーがこれらのディレクトリ外に書き込んだものはすべて次の clawk up で消えます。

デフォルトで完全な自律性（および --safe によるオプトアウト）