- Claude Codeの
--dangerously-skip-permissionsフラグを安全に使う方法
- Docker、VM、Firejailなどさまざまな隔離実行環境を検討した結果、**Vagrantベースの仮想マシン（VM）**が最適だと判断
- Vagrantにより、完全なVM隔離、再現可能な設定、ローカルフォルダ共有を維持しつつ、Docker-in-Dockerの問題を回避
- Claude CodeがVM内でsudo権限で自由にシステム操作を行えるように設定し、実際にWebアプリ実行・DB構成・テスト自動化などを実施
- この方法は誤操作によるファイルシステム破損防止に有効で、必要に応じてVMを削除・再作成して安全に初期化可能
背景
- Claude Codeを使うたびに毎回権限要求を確認しなければならない不便さを解消するため、
--dangerously-skip-permissionsフラグの使用を試みた
- このフラグは、パッケージインストール、設定変更、ファイル削除などあらゆる作業を事前承認なしで自動実行する
- ワークフローが中断されず効率的だが、ファイルシステム破損のリスクがある
- これを防ぐため、ホストOSアカウントと分離された環境で実行する必要性を認識した
検討した方法
- Dockerによる隔離をまず検討したが、ClaudeがDockerイメージをビルドしてコンテナを実行する必要があるため、Docker-in-Docker構成が必要
- この場合
--privilegedモードが必要となり、サンドボックス化の目的が無意味になる
- ネットワークの多重化、ボリュームマウント権限の問題などで複雑さと不安定さが増す
- その他の代替案としては次を検討した
- ベアメタル実行: Redditの事例ではデータベースやホームディレクトリ削除など深刻な破損事例が存在
sandbox-runtime: ACLベースのアクセス制御で、Claudeはコード以外にアクセスできないが、完全な自由度に欠ける- Firejail: Dockerと同様の制約がある
- 手動VM設定: 再現性不足
- クラウドVM: コスト・遅延・コードアップロードの必要性が問題
Vagrantベースのアプローチ
- Vagrantを使って完全なVM隔離と再現可能な設定を確保
- 共有フォルダによりローカルのようにアクセス可能
- Docker-in-Dockerの問題なし、必要ならVMを簡単に削除・再作成できる
- VirtualBox 7.2.4の使用中にCPU 100%占有バグを発見し、GitHub Issueを通じて原因を確認
- 最終的なVagrantfile構成は次のような特徴を持つ
bento/ubuntu-24.04ベースイメージを使用- 4GBメモリ、2 CPUを割り当て
- Docker、Node.js、npm、git、unzipをインストール
@anthropic-ai/claude-codeをグローバルインストールvagrantユーザーをDockerグループに追加
実際の使い方
- プロジェクトディレクトリで
vagrant up → vagrant ssh → claude --dangerously-skip-permissionsの順に実行
- 初回起動時はプロビジョニングに数分かかり、プロジェクトごとに一度だけClaudeへのログインが必要
- 作業終了時は
vagrant suspendでVMを一時停止できる
- ClaudeはVM内でsudo権限を与えられ、次のような作業を行う
- WebアプリAPIを実行し、
curlで確認
- ブラウザをインストールしてアプリを手動確認し、E2Eテストを作成
- PostgreSQL DBを設定し、マイグレーションをテスト
- Dockerイメージをビルドして実行
- このような環境により、Claudeがコマンド実行・出力確認・反復作業を自力で処理できる
性能と安全性
- Linux + VirtualBox環境ではリソースに十分余裕があり、ファイル同期の遅延もない
- 保護できる項目
- 誤操作によるファイルシステム破損
- 無秩序なパッケージインストールおよび設定変更
- 保護できない項目
- プロジェクトフォルダの削除（双方向同期のため）
- VM脱出脆弱性を悪用した攻撃
- ネットワークレベルの問題
- データ流出（VMはインターネットにアクセス可能）
- この構成は事故防止用であり、高度な攻撃防御が目的ではない
- Gitベースのプロジェクトなので、破損しても復旧しやすく、必要なら
rsyncの単方向同期でより厳格な隔離も可能
結論
- VirtualBoxのCPUバグ解決後、摩擦のない実行環境が完成
- Claude Codeを完全なVMサンドボックス内で自由に実行できる
- 問題が発生したらVMを削除して再作成すればよく、Vagrantfileひとつで再現性を確保できる
--dangerously-skip-permissionsフラグを使う場合、このような隔離環境の構築が強く推奨される
1件のコメント
Hacker Newsのコメント
Claudeを使っていると、結局は決定疲れ（decision fatigue）のせいで、数か月後にはただEnterを押してしまうようになる
だから私は、YOLOモードで動かしつつサンドボックス環境を用意しておくほうが、ずっと安全だと感じている
Ubuntu 22.04でbubblewrapとLandlock LSMを組み合わせて、階層型のサンドボックスを構成した
Landlockはファイルシステムアクセスをホワイトリスト方式で制限し、TCPポートへのアクセスも制御する
bubblewrapはマウント名前空間を分離して、プロジェクトごとの /tmp を作り、秘密鍵を隠す
dnsmasqでDNSホワイトリストを設定し、必要なドメインだけが名前解決されるようにする
この構成のおかげで、エージェントをずっと監視しなければならないというストレスが減った
Claudeが提案するelispの断片をいちいち承認するのはあまりにも消耗する体験だった
Bashコマンドでおかしなものをインストールしないよう注意するだけでも大変だった
/sandboxコマンドでClaude Codeにサンドボックス機能が内蔵されていると理解していたDockerのSriniです
多くの開発者がこの問題を解決するためにDockerを使っており、Docker-in-Dockerの制約に関するフィードバックも多く受けていた
そこで実験的にDocker Sandboxesをプレビューとして公開した
まだ初期段階だが、MicroVMベースで次のバージョンを開発中で、Docker-in-Dockerの問題を避けようとしている
ClaudeがDocker Sandboxの中で別のコンテナを権限なしで起動できるのか知りたい
ほとんどの人はローカルVMを自分で動かすのを避けたがっているようだが、なぜなのかわからない
実際、ローカルVMが最もシンプルで、すべての問題を解決する
MacでDockerを使うなら、すでにLinux VM上で動いているわけで、実環境とは一段違うだけだ
IDEからSSHで直接接続してコード確認もできる
私は
--dangerously-skip-permissionsオプションを有効にし、すべての変更はPRで処理しているここに workmux を組み合わせて数か月使っているが、複数のPRを同時に処理できて非常に効率的だ
クラウドVMより良い理由は、複数のコンテナを同時に起動するとメモリを多く消費するからだ
高性能なクラウドVMを24時間365日動かすとコストが大きすぎる
悪意あるAIはVM脱出の脆弱性を使わなくても、Vagrantfileに任意コードを追加してホストアクセスを得られる
単純なミスだけを心配する場合でも、Claudeがコミットフックを書き換えてしまえば、それが実行されたときに問題が起きる
完全な隔離を保ちながら便利に開発するのは本当に難しいと感じる
たとえばDockerのボリュームマウントを使って
sandbox/フォルダだけ編集可能にし、.gitにはアクセスできないよう設定する私はスナップショットを取り、小さなVMを立ち上げてエージェントを実行し、その後で再びスナップショットを比較する形で作業している
自動同期は隔離の目的を壊すので絶対にしない
私は別のアプローチを試している — Claudeが実行しようとするものを横取りする方式だ
Shannot は実行前に意図をキャプチャし、PyPyサンドボックスでシステムコールを横取りする
コマンドやファイル書き込みはログに残るだけで、実際には実行されない
ユーザーがTUIで確認して承認してはじめて実行される
VMとの違いは、VMは完全に隔離された環境で自由に実行させるのに対し、Shannotは実システムに人間の承認に基づく変更を適用することだ
サーバー修正のような作業に向いている
Claude MCP統合、SSHリモート実行、チェックポイント／ロールバック機能もある
結局、最初の承認リクエストで止まる構造なので、エージェントが自由に探索できない
私がほしいのは、エージェントが途中で止まらず最後まで試したうえで結果を評価する方式だ
そのほうが時間の節約になる
Leashのmac-nativeシステム拡張モードに近いが、完全なインタラクティブ承認モードはまだない
興味深いプロジェクトだ
承認疲れがたまると、結局
--dangerously-skip-permissionsを使いたくなるだから私はClaude Codeをdevcontainerの中で動かしている
ファイルアクセスはリポジトリだけ、ネットワークはホワイトリストのみ許可している
その後docker composeで一般化し、次はCodexやOpenCodeのような他のエージェントへの対応も追加する予定だ
ネットワークはホストのプロキシ経由に強制ルーティングして、ログ取得と制御を強化しようとしている
現在はiptablesで暫定対応している
まだ初期段階だが、かなりうまく動いている
コード: agent-sandbox
ネットワークプロキシに mitmproxy を使っているが、まだ完璧ではないものの、ほぼできている
Claudeが数時間にわたってシステムを自力で設定し、アプリを完成させた
私たちはコードを一行も書かず、結果は驚くほど良かった
AI開発のスピードは本当にすごいと感じた
私のソリューションはシンプルだ
こうするとnpxコマンドがBubblewrapサンドボックスの中で透過的に実行され、現在のディレクトリだけが公開される
純粋なPOSIXシェル数行で実装できる
sandbox-run
いったん権限を落とすと元に戻せないのも欠点だ
私はただ非特権LXCコンテナに入れて終わりにしている
私の脅威モデルは複雑な攻撃よりも、「うっかりホームディレクトリを消してしまう」状況だ
私はプロジェクトの
run/ディレクトリにユーティリティスクリプトを置き、composeベースでコンテナを立ち上げているdevcontainerはホストディレクトリとボリュームマッピングされている
サービス設定、スクリプト更新、ランタイム問題の診断までClaudeがうまく処理する
ブラウザ統合はないが、PlaywrightやPuppeteerで十分可能だと思う
Claude Codeの内蔵サンドボックスについての意見が知りたい
公式ドキュメントへのリンク
Claude Codeには必要に応じてサンドボックスを解除できるescape hatchがある
コマンドがサンドボックス制限で失敗すると、Claudeが原因を分析して
dangerouslyDisableSandboxで再試行できるエージェントが自分でサンドボックスを解除できる点が脆弱性のように見えるのだが、この場合にユーザー承認の手順があるのか気になる
関連イシュー: #14268, #13583, #10089