世界を動かす技術を、日本語で。

Show HN: Clawk – コーディングエージェントに使い捨てのLinux VMを提供しよう、あなたのラップトップではなく

2026年7月13日原文(github.com)

概要

clawk は、コーディングエージェント用の 使い捨てLinux仮想マシン を提供するツール。 自身のPCを守りつつ、エージェントに自由な操作権限を与える。 ネットワーク制限ファイル隔離 により安全性を確保。 セットアップは簡単 で、1コマンドで即利用可能。 プロジェクトごとの分離環境 で、リスクを最小限に抑える設計。

clawkとは何か

  • コーディングエージェント を安全に動かすための 使い捨てLinux仮想マシン 提供ツール
  • パッケージインストール、サーバ起動、ネットワーク利用 などをエージェントに許可
  • ホストPCのファイルやキーチェーン は仮想マシンから隔離
  • 危険な操作もVM内のみ で完結、ホストには影響なし
  • ネットワークは許可リスト方式 で制御、不明な外部サーバへの通信は遮断
  • ssh-agent転送 で、秘密鍵をVM内に持ち込まずにgit操作可能
  • VM破壊も即再構築可能、コードや会話履歴はホスト側で維持

なぜVM方式なのか

  • 完全な分離環境 を実現、プロセスサンドボックスより強固な隔離
  • 独立したLinuxカーネル を使用、ホストファイルシステムを直接隠す必要なし
  • 標準的なLinuxツールチェーン がそのまま利用可能
  • ゲスト側でroot権限 を持ち、パッケージやシステム設定も自由
  • VMは使い捨て前提、壊れてもすぐ再作成可能
  • KVM対応でDockerやKubernetesの開発にも対応 (ハードウェア要件あり)

インストール方法

  • macOS 14+(Apple silicon) が必要(Linuxはfirecrackerで実験的対応)
  • Homebrew でインストール:
    • brew install clawkwork/tap/clawk
  • ソースからビルド (Go 1.26+):
    • git clone https://github.com/clawkwork/clawk && cd clawk
    • make install
  • 追加ツール不要 (Docker, qemu, sudo不要)
  • アンインストール も簡単:
    • clawk destroyでサンドボックス削除
    • rm -rf ~/.clawkで設定削除
    • brew uninstall clawkでバイナリ削除

クイックスタート

  • 1コマンドでサンドボックス起動
    • cd ~/code/my-project
    • clawk
  • エージェントやシェルに接続
    • clawk run shell
    • clawk run codex
  • VMの停止・再接続・削除
    • clawk down
    • clawk attach
    • clawk destroy
  • ネットワーク・ポートの許可/転送
    • clawk network allow my-project api.example.com
    • clawk forward add my-project 3000

セキュリティモデル

  • エージェントはフル権限 (--dangerously-skip-permissions等)で動作
  • VM境界とネットワーク許可リスト が安全性を担保
  • ホスト側のファイル・秘密情報はVMから不可視
  • ssh-agent転送で安全なgit操作
  • プロンプトによる確認が必要な場合は--safeオプション
  • 許可外のネットワークアクセスは自動で遮断・記録

サンドボックスのライフサイクル

  • clawk list :全サンドボックス一覧
  • clawk status :状態確認(--json対応)
  • clawk up/down :起動/停止
  • clawk pause/resume :サスペンド/復帰
  • clawk snapshot :メモリごとスナップショット保存
  • clawk destroy :VM削除(会話履歴やコードは維持)
  • 状態・会話履歴はホスト側で永続化、VMディスクのみ使い捨て

設定ファイル(clawk.mod)

  • 設定ファイル不要、デフォルトで即利用可能
  • 必要に応じてgo.mod風の設定ファイルでカスタマイズ
    • CPU数、メモリ、イメージ、ネットワーク許可、ポート転送、環境変数、起動時コマンド、エージェント指示など
  • 設定例
    sandbox my-project (
      vm ( cpu 4 memory 8GiB image golang:1.25 )
      network ( allow api.example.com )
      forwards ( 3000 )
      env ( DATABASE_URL )
      on create ( "go mod download" )
      agent ( instructions "Ask before running destructive commands." )
    )
    

他方式との比較

  • プロセスサンドボックス :エージェントがポリシーを回避するリスクあり
  • Docker/Devcontainer :セットアップが複雑、ホストと分離が不十分な場合あり
  • clawk :本物の仮想マシンで強力な隔離、セットアップもシンプル

FAQ・注意点

  • Pre-1.0段階、仕様変更やバグ発生の可能性あり
  • フィードバック歓迎、issue報告が1.0開発の参考に
  • プロジェクト単位で複数VM同時運用可能、リソース自動解放
  • KVM対応やカスタムイメージの詳細は公式ドキュメント参照

clawk は、AIコーディングエージェントを安全かつ自由に活用したい開発者向けの 次世代ローカル仮想環境自分のPCを守りつつ、エージェントに思い切り仕事をさせたい なら、最適な選択肢。

Hackerたちの意見

clawk forward add my-project 3000 clawk network allow my-project api.example.com 実装の詳細を教えてもらえる?どうやってルートなしでファイアウォールを実装したの?俺はこのプロジェクトみたいな仮想マシンオーケストレーションプロジェクト「virtdev」を作ったことがあるんだけど、ルートは必要ないように設計したんだ。nftablesファイアウォールだけが例外になっちゃった。どうやって実装したのかめっちゃ気になる。もっと良い方法見つけた?

ありがとう!パケットファイアウォールは全くなくて、iptables/nftablesもないんだ。macOSでは、VMのNICはVirtualization.frameworkのファイルハンドルデバイスになってる。デーモンはgvproxyを実行していて、ゲストの接続を終了させてホストソケットとして再接続するから、ダイヤルの直前に許可リストでフィルタリングしてる。一つ注意点があるんだけど、ルートについて具体的に聞かれたから言うと、これはmacOSのやり方で、fd NICのおかげで機能してるんだ。LinuxのFirecrackerはTAPしか話さないから、ルートが必要で、そこでsudoを使うけど、デバイスのためだけだよ。フィルタリングは同じユーザースペースの許可リストのまま。

(数年前、PuppetとCobblerでPXE経由でVMをプロビジョニングして、その後iPXEを使った。俺の理解ではForemanはDjangoウェブフレームワークに基づいているCobblerよりもアクティブにメンテナンスされてる。) VagrantはVMと仮想ネットワークをRubyで管理する。ansible-moleculeはVMやコンテナを作成、収束、破棄して、クリーンなビルドルートでansibleプレイブックやansibleロールをテストするために使う。podman machineはVMを管理する:

  • podman-container-tools/podman-machine-os: マシンイメージファイル: https://github.com/podman-container-tools/podman-machine-os/... podman kube playpodman machineの上で実行すると、複数のVM/コンテナが必要なエージェントのための解決策になるかも。
  • Podman DesktopはDocker Desktopと同じローカルK8sセットアップで動作できる。エージェントセッションファームのためにK8sで管理する状態が増えるけど、K8sは各ノードのVM管理スクリプトよりも優れたログ記録やクォータを持ってるかもしれない。 OpenShift on OpenStackは、VMの上でコンテナを実行する一つの方法だ。Microshiftもcontainer-selinuxを扱ってる。コンテナ用のAppArmorポリシーは設定されてないの?bwrapやliboverlayfs、libseccompはほぼコンテナだけど、完全なVMや軽量VMに近い強力なコンテナ隔離レイヤーがあって、エージェントセッションにはそっちの方が良いかも:gVisor、Firecracker VM、Todo Cloudflare workerdはCloudflare Workersのオープンソース部分で、軽量のWASMやJS VMをマルチテナント隔離で実行する。Cloudflareでコンテナを実行するよりも、Cloudflare Workerを実行する方が遥かに少ないリソースで済むから、エージェントがWASMランタイム内で動作することができれば、エージェントセッションには多分最適だろうね。Cloudflare/artifact-fsはFUSEファイルシステムでレイジーシャロウGitクローンを行う。
  • "Show HN: VM-curator – libvirtやvirt-managerのTUI代替" https://news.ycombinator.com/item?id=46750437 https://news.ycombinator.com/item?id=46825026 ; amla sandbox、agentvm、ARM64 MTE https://news.ycombinator.com/item?id=46825119 ; container2wasm、vscode-container-wasm-gcc-example ; DockerfileでWASMコンテナをビルドする dockerとpodmanは、エージェントセッション用のWASMコンテナを実行するための複数のWASMランタイムをサポートしてる。

yoloAIも似たようなことをやってるよ:

  • Docker、Podman、containerd、gVisor、Kata、Firecrackerを使ったLinuxのサンドボックス
  • Docker(Docker DesktopかOrbstack)、Podman、Appleコンテナ、Seatbelt、Tartを使ったMacのサンドボックス(Tartを使うとシミュレーターを実行できる)
  • ネットワーク制限
  • シークレット管理(ファイルマウントや資格情報ブローカー)
  • 環境データなし(ENVは最小限のローカルサンドボックス用に置き換えられ、明示的に許可したもの以外のホスト側ファイルシステムにはアクセスできない)
  • 作業ディレクトリ保護:変更を適用するまで作業ディレクトリは変更されない(スタンドアロンでもgitコミットでも)
  • 適用前にdiffもできる。リポジトリにフィルターがある場合は、gitはサンドボックス側で実行される。
  • ファイルシステムがサポートしていればコピーオンライトを使用(ほとんどの最新のものはサポートしてる)
  • claude、codex、gemini、aider、opencodeのためのビルトインサポートがあるけど、「シェル」モードで好きなものを実行することもできる。
  • VS Codeトンネルをサポートしてるから、ターミナルを使いたくない場合はVS Codeからリモートアクセスできる。
  • 完全なライフサイクルサポート:起動、接続、停止、再起動、待機、ワンショット、クローン、破棄
  • MCPパススルー
  • 他のものをサンドボックス化したい場合のためのレイヤードAPI(golang)
  • 自己完結型のバイナリ。使用したいバックエンド以外の外部要件はなし。デフォルトでは~/.yoloaiディレクトリに設定やデータが保存されるけど、どこにでもポイントできる。
  • FOSS https://github.com/kstenerud/yoloai

yoloaiは初めて見た!新しい/diff/apply/destroyのワークフローがすごく面白いね。自分のニーズとしては、マルチリポジトリのワークツリー(いくつかのリポジトリをまたぐサンドボックス、それぞれに独自のワークツリーがある)と、完全にコントロールできる単一のネットワーク制限付きVMパスが欲しかったんだ。最初は多くのバックエンドを使ってたけど、ネットワークフィルタリングを追加するのが面倒だったから。重複する部分も多いけど、いい仕事してるね!あなたのをじっくり読ませてもらうよ。

エージェントが自分のマシンで動いてると、ノートパソコンをスリープさせるとサスペンドしちゃうんだ。俺はリモートのLinux VMを使って、コーディングエージェントが動き続けるのが好き。exe.devには満足してるよ。俺のノートパソコンは上の階でスリープ中だけど、タブレットのブラウザタブでエージェントがコーディングしてる。スマホからもチェックできるしね。でも、exe.devみたいな自己ホスティングのセットアップがあったらいいなとも思う。あんまり使ってないMac Miniがあるんだ。

https://paseo.sh/ は自己ホスティングをサポートしてるけど、正直あんまり使ったことない。

ノートパソコンをスリープさせるとサスペンドしちゃう それをしないこともできるよ。ノートパソコンはサーバーとしても普通に動くからね。内蔵モニターやUPSもあるし。

クラウドサンドボックス(とexe.dev)に+1だね、ラップトップサンドボックスよりも。24/7で完全にエアギャップされてるから。サンドボックスがGitHubやStripeにアクセスできるように、サービスプロキシも必要だよ。エージェントにアクセスできるキーなしでね。ラップトップサンドボックスツールでこれをやってるのはあまり見たことがないけど、exe.devは「統合」を使ってすぐにできるんだ。私はいつも自分のバイナリエージェントコーディングツールキットをサンドボックス内に入れて、コードブラウジングやレビューができるようにしてる。https://github.com/housecat-inc/scratch それから、私もMac Miniを持ってて、自分の24/7開発ボックスにしようか考えたけど、これを作るのとexe.devから50VMを月20ドルで買うのを比べると、あまり合わないんだよね。

ローカルファーストも特徴の一つだね。仕事では、会社が所有してないリモートVMで会社のコードを実行できないことが多いから。でも、リモート開発環境はロードマップに入ってるよ。だから、宣言的なclawk.modマニフェストを設計した理由の一つでもあるんだ。

AppleシリコンでmacOS 14以上が必要。 (LinuxはFirecracker経由でサポートされていて、現在は実験的な状態…) だから、基本的にはmacOSがメインで、少しLinuxのサポートがあるってことだよね。

ほとんどmacOSでそのまま使えるよ。Linuxでテストしたけど動いたけど、普段使ってるわけじゃない。READMEでプラットフォームの範囲をもっと明確にするつもり。

Hacker Newsで議論の続きを見る