clawk解説｜コーディングエージェントに使い捨てLinux VMを渡すサンドボックスと既定許可137件

コーディングエージェントに実際の作業をさせようとすると、必ず同じ二択に突き当たる。1コマンドごとに確認プロンプトへ答え続けるか、--dangerously-skip-permissions を付けて祈るかだ。2026年7月6日に公開されたclawkwork/clawkは、この二択そのものを組み替えようとするGo製のOSSで、キャッチコピーは「Give coding agents a disposable Linux VM, not your laptop（コーディングエージェントには、あなたのノートPCではなく使い捨てのLinux VMを渡せ）」。リポジトリのディレクトリで clawk と打つと、Claude CodeやCodexが手元のMacではなく使い捨てのLinux VMの中で動き出す。

エージェント基盤全体の中でこの種のツールがどこに位置するかは、AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証で整理している。本記事はそのうち「エージェントを走らせる土台」を、clawkの一次資料（README・ARCHITECTURE.md・DESIGN.md・SECURITY.md・ソースコード）と、実機での確認結果から読み解く。検証環境はmacOS 14.5（Apple silicon / arm64）、clawk v0.2.0（Homebrew版）、2026年8月2日。実際にサンドボックスを1つ起動し、ゲスト内から許可リストの挙動まで確かめている。

clawkとは——エージェントに「自分のマシン」を渡すという発想

clawkの主張は単純だ。エージェントを制約するのではなく、壊してよい別のマシンを丸ごと渡す。READMEの表現を借りれば「境界は、エージェントが言いくるめられるかもしれないプロンプト上のルールではない。それは別のマシンであり、開いているのはあなたがマウントした口だけだ」となる。

この設計が効くのは、エージェントに任せたい作業ほどホストで嫌われる種類のものだからだ。パッケージのインストール、ネイティブ依存のビルド、バックグラウンドのデータベースやdevサーバー起動、信頼できないコードのテスト実行——いずれもプロセス単位のサンドボックスと相性が悪い。VMならゲスト内でrootを取れるので、/etc の編集も特権ポートのbindもカーネルモジュールの読み込みも、エージェントの裁量で完結する。

リポジトリの実測値

2026年8月2日時点でGitHub APIから取得した実測値は次のとおり。

公開から1か月足らずでv0.2.0という段階で、README自身が「Pre-1.0 and moving fast（1.0前で高速に動いている）」「リリース間で破壊的変更を見込め」と明記している。本記事が扱うのは完成度ではなく設計と運用上の勘所である点を先に断っておく。

なお作者はHacker Newsの Show HN（226ポイント・159コメント）で、動機を「実際のクラスタを必要とするKubernetesツールを作っていた。コンテナだとDocker-in-Dockerになり、いつも継ぎ接ぎに感じていた。VMなら普通のLinuxマシンでしかない」と説明している。プラットフォーム対応についても「ほぼmacOSがそのまま動く対象。Linuxでも試して動いたが、日常的に使ってはいない」と述べており、READMEのexperimental表記と整合する。

インストールと最初の1コマンド——macOS 14.5実機での確認

インストールはHomebrewのtapから1行。追加のホストツールは要らず、Docker・qemu・sudoのいずれも使わない。ハイパーバイザはApple純正のVirtualization.frameworkがバイナリにリンクされている。

brew install clawkwork/tap/clawk
clawk version
# clawk v0.2.0 (9c35a76c0b37, 2026-07-13T13:41:17Z) darwin/arm64

日常の使い方は、リポジトリのディレクトリに入って clawk と打つだけだ。VMが立ち上がり、カレントディレクトリがゲストへマウントされ、既定のランナー（claude）がアタッチされる。

cd ~/code/my-project
clawk                      # このディレクトリ用のサンドボックスを起動しclaudeをアタッチ
clawk run shell            # 同じサンドボックスでシェルに入る
clawk run codex            # 別のランナー（codex / opencode / shell）に切り替える
clawk down                 # VMを停止（リポジトリとエージェント状態は残る）
clawk attach               # 後から復帰（停止していれば起動してから再アタッチ）
clawk destroy              # VMを削除（会話履歴は残る）

実機で clawk doctor を叩くと、ホスト側の前提が項目ごとに検査される。macOS 14.5／Apple silicon（darwin/arm64）では次のようになった。

$ clawk doctor
[OK]   host: os/arch — darwin/arm64
[FAIL] host: go toolchain — not found on PATH (builds the guest init/agent for image-based sandboxes)
    fix: install from https://go.dev/dl or brew install go
[OK]   host: state dir — /Users/user/.clawk

ここは注意が要る。READMEは「リリースバイナリはゲスト内エージェントを同梱しているので、Goツールチェーンはソースからビルドする場合にだけ必要」と書いているが、Homebrewが配るのは v0.2.0（2026年7月13日）で、その同梱化はまだリリースに入っていない。CHANGELOGを見ると該当項目は “Unreleased”（未リリース）節にあり、リリース済みのv0.2.0では doctor がGoツールチェーンを要求する。READMEはmainブランチの姿を説明しているため、2026年8月2日時点でbrew経由で入れた読者はこの差に出くわす。brew install go を足せば [OK] host: go toolchain — on PATH に変わる。

何が残り、何が消えるのか

永続性のルールは1つだけで、READMEの表に集約されている。

エージェント状態はサンドボックスごとにホスト側へマウントされる。ゲストの ~/.claude/projects/ や ~/.claude/memory/（codexなら ~/.codex/）の実体はホストの ~/.clawk/namespaces/default/state/<name>/ にあるため、VMを作り直しても --resume で以前の会話へ戻れる。毎回必要なツールはイメージ側（vm ( image … )）へ、起動ごとの準備は on up フックへ置くのが想定された使い分けだ。

ただし例外が2つある。clawk snapshot から復帰した場合はディスクとメモリが停止時のまま復元され、Linux（firecracker）プロバイダは destroy までディスクを保持する。

既定で開いている137ドメイン——「何を遮断するか」より「どこまで開いているか」

ここからが、この種のツールを運用に載せるときに最も見落とされる部分だ。

clawkの送信制御は「既定拒否」と説明される。DNSは何でも解決するが、許可リストに無いホストへのTCP・UDP（QUIC／HTTP-3を含む）・ICMP echoはすべて拒否される。それ以外のIPプロトコルはそもそも転送されない。フィルタはゲストの下——ホスト側デーモン内のgvproxy（ユーザースペースのTCP/IPスタック）——で効くため、ゲスト内でrootを取っても書き換えられない。ここまでは強い設計だ。

だが「既定拒否」という言葉から想像する状態と、実際に適用される初期状態は違う。組み込みの許可リストが最初から効いているからだ。実機のv0.2.0で確認した。

$ clawk policy list
NAME     RULES  SOURCE      FETCHED
default  137    (built-in)  -

137ルール。ソース側の internal/config/types.go にある DefaultAllowedDomains を数えても137エントリで、うち30件は *.amazonaws.com のようなワイルドカードだった。実行時の表示とソースの実体が一致している。なおこのリストは v0.2.0 とmainブランチ（2026年8月1日時点）で完全に同一で（両方のタグから該当ブロックを抜き出して差分を取り、1件の増減も無いことを確認した）、以下の内訳はbrewで入るリリース版にもそのまま当てはまる。

内訳は次のとおり。

重要なのは、この事実をclawk自身がソースコード中で正面から書いていることだ。DefaultAllowedDomains の直上のコメントにはこうある——このリストの各エントリは双方向の契約であり、リリース後に削れば依存しているユーザーが壊れる。そして各エントリは、エージェントが許可を求めずに到達できる宛先、つまり潜在的な持ち出し先（exfiltration endpoint）である。追加には「その組織自身が運営していること」「一つのプロジェクトではなく主流の開発ワークフローが必要とすること」の2条件を課し、迷ったら入れない、と明記されている。

つまり、このリストは雑に膨らんだものではなく、意識的に管理された設計判断だ（コメントによれば Andrew Lock氏のmicroVMサンドボックス許可リストが出発点になっている）。それでも運用者にとっての意味は変わらない。遮断の強さを評価する前に、初期状態でどこまで開いているかを自分の要件に照らす必要がある。

実機で挙動を確かめる

数え上げだけでは、この許可リストが実際にどう効くのかは分からない。macOS 14.5／Apple siliconでサンドボックスを1つ起動し、ゲスト内から確認した。まず環境そのもの。

$ clawk run shell vmtest
agent@vmtest:~/workspace/vmtest$ uname -a
Linux vmtest 6.18.15 #1 SMP Mon Jul 13 13:51:59 UTC 2026 aarch64 GNU/Linux
agent@vmtest:~/workspace/vmtest$ id
uid=501(agent) gid=20(dialout) groups=20(dialout)
agent@vmtest:~/workspace/vmtest$ sudo id
uid=0(root) gid=0(root) groups=0(root)

独立したLinuxカーネル（6.18.15・aarch64）が動いている。通常のシェルは agent ユーザーだが、sudo でrootを取れる。READMEの「ゲスト内でroot」はこの形で提供されている。

次に送信許可リスト（egress allow-list）の挙動。許可リストに載っているホストと、載っていないホストを並べて叩いた。

# 許可リストにある宛先
$ curl -s -o /dev/null -w "pypi:%{http_code}\n" https://pypi.org/
pypi:200
$ curl -s -o /dev/null -w "anthropic:%{http_code}\n" https://api.anthropic.com/
anthropic:404

# 許可リストに無い宛先（実在するドメイン）
$ curl -sS https://example.com
curl: (7) Failed to connect to example.com port 443 after 18 ms: Couldn't connect to server

# ただしDNSは引ける
$ getent hosts example.com
104.20.23.154   example.com
172.66.147.243  example.com

ドキュメントの説明どおりだった。pypi.org は200を返し、api.anthropic.com も404（ルートへのGETに対するAPIの応答であり、接続自体は成立している）で到達する。一方、許可リストに無い example.com は 18ミリ秒 で接続失敗する——タイムアウトではなく、ゲストの手前で拒否されているから即座に返る。そして getent hosts では実IPが引けている。「DNSは何でも解決するが、未許可の宛先への接続は拒否される」という設計が、そのまま観測できる。

ホスト側の秘密鍵がVMに入っていないことも確認できた。

$ cat ~/.ssh/id_rsa
cat: /home/agent/.ssh/id_rsa: No such file or directory

そして最も示唆的だったのは、こちらが何も指示していない段階で記録されていた遮断だ。

$ clawk network denials vmtest
HOST                                LAST IP        PORT  COUNT  LAST SEEN  RULE
http-intake.logs.us5.datadoghq.com  34.149.66.165  443   1      7m ago     -

サンドボックスを起動しただけで、ゲスト内のプロセスがDatadogのログ収集エンドポイントへ送信を試み、許可リストに無いため遮断されていた（どのプロセスが発信元かはこの記録からは特定できない）。datadoghq.com は137件の既定リストに含まれていないため落ちた形で、許可リストが実際に何かを止めていることと、clawk network denials が「エージェント環境が外へ出ようとした先の記録」として読めることが同時に確認できた。逆に言えば、この宛先が既定リストに入っていれば、記録すら残らずに通っていたということでもある。

運用に落とすなら

READMEはこの点について自ら踏み込んでいる。許可リストが遮断するのは未知のサーバーであって、許可済みのサーバーではない。github.com は初めから許可されており、ssh-agentは転送されるので git push が通る。だから「エージェントが読めるものは、エージェントが公開しうるものとして扱え」というのが公式の言い分だ。

対処はコマンド側に用意されている。

clawk network allow my-project api.stripe.com '*.internal.mycorp.com' 10.0.0.5
clawk network block my-project tracker.example.com    # 許可より強い明示拒否
clawk network denials my-project                      # 遮断された宛先を新しい順に表示
clawk network watch my-project                        # 遮断を対話的に許可／拒否する

allow は宛先単位で、ポートやプロトコルは指定しない（全プロトコル・全ポートが対象なので https://example.com:443 ではなく example.com と書く）。block はドメインとそのサブドメイン全体を、許可を上書きして無条件に拒否する。遮断はゲストが解決したホスト名で記録されるため、clawk network denials はそのまま「エージェントが到達を試みた先の記録」として読める。

組み込みの137件を外したい場合は、network ( … ) ブロックに use 行を書く。use を書かなければ暗黙に use default が適用されるが、明示的に書けば default を外して自前のポリシーだけを積める。外部のブロックリスト（oisd等）を policy として購読し、層として重ねることもできる。

network (
    use   oisd corp-egress        # defaultを含めない＝組み込み137件を使わない
    allow api.example.com
)

clawkの内側で何が動いているか——デーモン・gvproxy・vsock

構成を押さえておくと、境界がどこに引かれているかが具体的に見える。clawkのCLIは短命で、コマンドが終われば終了する。VMはCLIの中では生きられない——サンドボックスごとに切り離されたデーモン（macOSでは __vzd、Linuxでは __fcd）が所有する。

設計上、意図的に選ばれている点が3つある。

・rootfsは普通のOCIイメージ。clawkが自分でpullし（Dockerデーモンは介在しない）、レイヤーを平坦化してext4ディスクを直接書く。rootもループデバイスも使わない。同じイメージから作るサンドボックスはコピーオンライトのクローン（APFSのclonefile／FICLONE）なので、サンドボックスごとのディスク消費はゲストが書いた分だけになる
・ネットワークのフィルタはゲストの下。VMのL3（ゲートウェイ・DHCP・DNS・NAT）まるごとがデーモンプロセス内のユーザースペーススタックで、送信接続とDNS応答はすべてそこで許可リストを参照する。ホスト側のiptablesもsudoも要らず、ゲスト内のrootからは触れない
・入口は1つだけ。sshdもcloud-initも無く、ゲストへの制御経路はvsock（AF_VSOCK ポート1024）のpty-agent1本。アタッチのたびに新しいプロセスが起き、切断で破棄される（コンテナのexecに近い挙動）

なおgvproxyはフォーク（clawkwork/gvisor-tap-vsock）が使われており、go.modのコメントは「TCP・UDP・ICMPのフォワーダにパッチを当て、dialする前に送信許可リストを参照させるため」と説明している。許可リストの評価が後付けの被せ物ではなく、接続を張る直前の経路に入っていることになる。

リソース面では3つの仕組みが用意されている。アイドルのVMはメモリのベースライン（既定で約1GiB）まで回収され、必要時に上限まで burst する（ballooning）。全VMが同時に上限まで使ってもホストRAMを超えないよう、起動時点で受け入れ判定が入る（admission control）。そして30分アイドルすると停止する。ビルドやテストを走らせていればゲストの負荷が活動と見なされ停止しない。ただしアイドル停止は現時点でmacOS（vz）のみで、firecracker側はデーモンがクライアントのセッションを観測できないため未対応だ。

clawkが守らないもの——公式が明記する3つの限界

このリポジトリの美点は、限界を自分で書いていることだ。SECURITY.mdとREADMEが挙げる「守らないもの」は3つある。運用者が実際に判断すべきなのはここなので、そのまま整理する。

・マウントしたもの・許可したものは露出する。ワークツリーは書き込み可能なので、エージェントは悪いコードをコミットできるし、転送されたssh-agentが到達できるリポジトリへpushできる。READMEの表現では「サンドボックスから出てくるものは、見知らぬ他人のPRと同じようにレビューせよ」
・押し込んだ秘密情報は見える。files ( … ) や shares ( … ) の中身、転送した環境変数、Claudeのトークンは、すべてエージェントが読める。許可された宛先があれば、そこへ送ることもできる。共有は最小限に
・ハイパーバイザの脱出は対象外。clawkはVirtualization.framework／KVMの隔離に依存しており、その上に独自の防御を足してはいない

3点目は率直な線引きだ。1点目と2点目は、この記事の前半で見た137ドメインの話と地続きになる。境界の内側に何を入れたかが実質的な被害範囲を決めるのであって、VMの壁そのものではない。

だから運用の勘所は「clawkを入れたから安全」ではなく、次の3つを自分で決めることになる。

1. マウント範囲を絞る——cd したディレクトリがそのまま境界の内側になる。ホームディレクトリ直下や複数プロジェクトを含む親ディレクトリで起動しない
2. ssh-agent転送の射程を意識する——git push が通るのは利便性だが、pushできる先すべてが射程に入る。転送したエージェントが持つ鍵で到達できる範囲を把握しておく
3. 出力をレビューする——権限確認を切る運用は、確認のタイミングを「実行のたび」から「成果物のレビュー時」へ移動させただけであって、消したわけではない

権限確認を残したいセッションでは --safe を付ける。clawk --safe や clawk run claude --safe とすると、そのセッションだけバイパスフラグ無しでランナーが起動する。

類似ツールとの比較——サーバー側基盤・プロセス隔離との住み分け

「AIエージェント サンドボックス」という言葉は、実際にはかなり違うものを指している。clawkの位置を、当サイトで扱ってきた近隣のツールと並べて整理する。優劣ではなく、解こうとしている問題が違う。

日本語圏で「Claude Code サンドボックス」と検索して出てくる解説の中心は内蔵機能（macOSのSeatbelt、Linuxのbubblewrap）であり、これはホスト上のプロセスに規則を適用する方式だ。守る対象もBashツールとその子プロセスに限られる。clawkのREADMEはこの系統を「OS-level agent sandboxes」と呼び、Anthropicのsandbox-runtimeを名指ししたうえで「軽量なルールには良いが、ポリシーを1つ間違えるとキーチェーンを含めてすべてが露出する。インストールやバックグラウンドサービス、入れ子の仮想化を安全に許すのは難しい」と対比している。clawkはワークロードごと別のマシンへ移す方を選んだ、という整理になる。

コンテナ／devcontainerとの違いについても踏み込んでいる。コンテナはホストのカーネルを共有し、拒否ルールを引いた残りのファイルシステムが見える状態にある。devcontainerの構成ではイメージビルドのためにホストのDockerソケットをbind mountすることが多く、それはコンテナにホストデーモンの制御権を渡すことになる。clawkはDockerをVMの内側に置く。そしてDockerfileもdevcontainer.jsonも書かない——任意のOCIイメージがそのままrootfsになる。

汎用のVMマネージャ（Limaなど）との差は、VMそのものではなくワークフローだと説明されている。プロジェクトごとのVM、マウント済みのリポジトリ、認証済みでアタッチされたエージェント、既定で許可リスト化された送信と記録される遮断、destroyをまたいで残る会話履歴、ワークツリーとPRを面倒見るチケットモード——この一式が乗っている点が違う（内部的にはどちらもVirtualization.frameworkを使う）。

クラウドサンドボックスとの差は「ローカル優先」であることだ。コードがマシンから出ず、時間課金も無く、エージェントが編集するワークツリーはエディタで開いているものと同じものがライブマウントされる（macOSの場合。Linuxプロバイダは現状、作成時に焼き込む）。

複数リポジトリにまたがるチケット

もう1つ、clawk固有の機能としてチケットモードがある。複数リポジトリを列挙した clawk.mod を置いたディレクトリで実行すると、1つのサンドボックスの中にリポジトリごとのgit worktreeを新しいブランチで作り、エージェントをアタッチする。作業後に clawk pr を叩くと、変更のあったリポジトリごとにPRを相互リンク付きで開く。

cd ~/code/my-workspace     # 対象リポジトリを列挙した clawk.mod がある
clawk work INFRA-123       # 1サンドボックス＋リポジトリ毎のworktree＋claudeをアタッチ
clawk pr INFRA-123         # ブランチをpushしてリポジトリ毎にPRを開く

設定ファイルは必須ではない。必要になったときだけ、go.mod風の文法で clawk.mod を書く。CPU・メモリ・イメージ、送信許可、ポート転送、ホストから渡す環境変数、作成時フック、エージェントへの指示などを1ブロックにまとめられる。このブロックはサンドボックス作成時にスナップショットされるテンプレートで、走っているサンドボックスが後から勝手に変わることはない。

導入前に確認しておく制約

最後に、実際に入れる前に把握しておきたい点をまとめる。

動作環境：macOS 14以降のApple silicon。Intel MacとWindowsは非対応とFAQで明言されている。Linuxはfirecrackerプロバイダで動くが実験的で、ワークツリーのライブ反映がなく（作成時にext4へ焼き込む）、アイドル自動停止も未対応。ロードマップにはこの差を埋める「Firecracker parity」が挙がっている。

pre-1.0であること：READMEもCHANGELOGも、リリース間の破壊的変更を明示的に見込んでいる。CLI表面の変化は最も小さく内部が最も動く、と説明されているが、1.0までは何も凍結されていない。

リリース版とmainの差：本記事で見たGoツールチェーンの件のように、READMEが説明する挙動が最新リリースにまだ入っていない場合がある。2026年8月2日時点でHomebrewが配るのはv0.2.0（2026年7月13日）で、最終pushは8月1日。ドキュメントを読んで動かない挙動に当たったら、まずCHANGELOGの “Unreleased” 節を確認するとよい。

ライセンス：Apache License 2.0。third-partyとして gvisor-tap-vsock（Apache-2.0）と hcsshim のext4ライタ（MIT）をvendorしており、NOTICEに記載がある。

初回起動のコスト：イメージからの初回ブートは一度だけrootfsのビルド（pull → 平坦化 → ext4）を払う。以降はコピーオンライトのクローンとカーネルの直接ブートで、ファームウェアもインストーラも通らない。既定のイメージは ghcr.io/clawkwork/clawk-dev:v0 が使われる（実機の clawk status で確認）。

まとめ

clawkは、コーディングエージェントに使い捨てのLinux VMを1台ずつ渡すことで、権限確認を切る運用を現実的な選択肢にしようとするツールだ。境界をプロンプト上の約束からハイパーバイザとユーザースペースの送信フィルタへ移し、ゲスト内でrootを取られても書き換えられない位置にネットワーク制御を置いた設計は筋が通っている。任意のOCIイメージがそのままrootfsになり、Dockerデーモンもsudoも要らない点も、手元で回す道具として素直だ。

一方で、運用に載せるときに見るべきなのは遮断の強さではない。既定で137ドメインが開いていること、そしてマウントしたワークツリーと転送したssh-agentは境界の内側に残ること——この2つが実質的な被害範囲を決める。clawk自身がソースコードのコメントで「各エントリは潜在的な持ち出し先である」と書き、READMEが「エージェントが読めるものは公開しうるものとして扱え」と書いているとおりだ。ツールが自分の限界を明記している以上、運用者の仕事はその限界を自分の要件に照らすことになる。

pre-1.0で破壊的変更が続く段階であり、Intel MacとWindowsは対象外、Linuxは実験的という制約もある。それでも「エージェントに自分のマシンを渡す」という発想を、手元のMac 1台で試せる形にまとめた点は評価できる。まずは重要でないリポジトリのディレクトリで clawk と打ち、clawk network denials にどんな宛先が並ぶかを眺めるところから始めるのが、この種のツールの性格を掴む一番速い方法だろう。

参照ソース

・clawkwork/clawk（公式リポジトリ・README） — 概要、インストール、ネットワーク、比較、FAQ、ロードマップ
・clawk ARCHITECTURE.md — デーモン構成、ゲストスタック、gvproxy、プロバイダ差分
・clawk SECURITY.md — 2つの境界と、権限確認を切る設計の根拠
・clawk DESIGN.md — セキュリティモデルと設計判断
・clawk docs/networking.md — 許可リストの文法、policy／use チェーン、ポート転送
・Show HN: Clawk – Give coding agents a disposable Linux VM, not your laptop — 作者による設計意図とプラットフォーム対応の説明
・GitHub REST API（/repos/clawkwork/clawk、/releases、/languages）— スター数・ライセンス・リリース・言語構成の実測（2026年8月2日取得）