Claude Code を本格的に活用する上で避けて通れないのが --dangerously-skip-permissions オプションです。ファイルの読み書きやコマンド実行のたびに許可を求められる手間をスキップし、Claude Code を自律的に動かせるようになります。
しかし名前に「dangerously」と入っている通り、ホストマシン上でそのまま使うのはリスクがあります。では、Anthropic 公式推奨の DevContainer 内で使えば安全なのか？ 何が守られて、何が守られないのかを整理します。
そもそも --dangerously-skip-permissions とは
通常、Claude Code はファイルの変更やシェルコマンドの実行前に毎回ユーザーの承認を求めます。
Claude wants to run: rm -rf node_modules && npm install
Allow? (y/n)
--dangerously-skip-permissions を付けると、この確認がすべてスキップされます。Claude Code が判断したコマンドを即座に実行するため、作業効率は飛躍的に上がりますが、意図しない操作も即座に実行されるということです。
ホストマシン上でこれを使うと、理論上は以下のようなことが起こり得ます。
- 重要なファイルの削除や上書き
- 意図しないパッケージのインストール
- 環境変数や設定ファイルの書き換え
- 機密情報を外部に送信するコマンドの実行
DevContainer で守られること
DevContainer（Docker コンテナ）内で Claude Code を動かすことで、以下のリスクが排除されます。
✅ ファイルシステムの分離
コンテナ内の操作は Windows ホストのファイルシステムに一切影響しません。Claude Code が rm -rf / を実行したとしても、壊れるのはコンテナの中だけです。ホスト上の個人ファイル、システム設定、SSH 鍵、他のプロジェクトには一切触れません。
✅ プロセスの分離
コンテナ内で動くプロセスは、ホスト側のプロセスから完全に隔離されています。Claude Code がバックグラウンドで何かを起動しても、Windows 側には影響しません。
✅ パッケージのインストール汚染防止
npm install -g や apt install でインストールされたものはコンテナ内に閉じ込められます。ホストの開発環境が汚れることはありません。
✅ 簡単な復旧
最悪の事態が起きても、コンテナを削除して再ビルドするだけで元通りです。Git 管理されているプロジェクトファイルは、リモートリポジトリからいつでも復元できます。
DevContainer でも残るリスク
ここが重要です。DevContainer は万能ではありません。
⚠️ 認証情報の漏洩
Claude Code のトークンは ~/.claude ディレクトリに保存されており、Docker Volume を通じてコンテナ内からアクセスできます。悪意のあるコードがこのトークンを読み取り、外部に送信する可能性は排除できません。
⚠️ プロジェクトファイルの流出
DevContainer は /workspace にプロジェクトファイルをマウントします。Claude Code がこれらのファイルを読み取って外部に送信するコマンドを実行する可能性があります。
⚠️ ネットワーク経由のデータ送信
Anthropic 公式の DevContainer にはファイアウォール（init-firewall.sh）が含まれていますが、Docker Desktop + WSL 2 環境ではコンテナに NET_ADMIN 権限がなく、ファイアウォールが機能しないケースがあります。ファイアウォールが無効な状態では、コンテナから任意のサーバーへの通信が可能です。
⚠️ サプライチェーン攻撃
npm install や pip install でインストールされるパッケージに悪意のあるコードが含まれていた場合、Claude Code がそのパッケージのインストールを実行することで、コンテナ内で悪意のあるコードが動く可能性があります。
リスクの整理表
| 脅威 | ホスト直接実行 | DevContainer（FW なし） | DevContainer（FW あり） |
|---|---|---|---|
| ホスト OS の破壊 | ❌ 危険 | ✅ 安全 | ✅ 安全 |
| 他プロジェクトへの影響 | ❌ 危険 | ✅ 安全 | ✅ 安全 |
| 意図しないファイル変更 | ❌ 危険 | ⚠️ プロジェクト内に限定 | ⚠️ プロジェクト内に限定 |
| 認証情報の漏洩 | ❌ 危険 | ⚠️ リスクあり | ✅ 大幅に軽減 |
| プロジェクトコードの流出 | ❌ 危険 | ⚠️ リスクあり | ✅ 大幅に軽減 |
| パッケージの汚染 | ❌ 危険 | ✅ コンテナ内に限定 | ✅ コンテナ内に限定 |
ファイアウォールを有効にする方法
Docker Desktop + WSL 2 環境でファイアウォールを有効にするには、コンテナに NET_ADMIN 権限を追加する必要があります。
devcontainer.json に以下を追加してください。
"runArgs": ["--cap-add=NET_ADMIN"],
その上で、postStartCommand で init-firewall.sh が実行される設定を有効にします。
"postStartCommand": "sudo /usr/local/bin/init-firewall.sh",
変更後、コマンドパレット（Ctrl+Shift+P）→ Dev Containers: Rebuild Container でコンテナを再ビルドします。
ファイアウォールが有効になると、以下のドメインへの通信のみが許可され、それ以外はすべてブロックされます。
api.anthropic.com（Claude API）github.com（Git 操作）registry.npmjs.org（npm パッケージ）- DNS と SSH の通信
Note:
NET_ADMIN権限の追加は、コンテナにネットワーク設定の変更を許可することを意味します。これは iptables によるファイアウォール設定に必要ですが、コンテナ内の悪意のあるコードがファイアウォールルール自体を書き換える可能性も理論上はあります。ただし、--dangerously-skip-permissionsを信頼できるリポジトリでのみ使うのであれば、実用上は問題ありません。
ファイアウォール以外の追加対策
Docker のネットワーク制限を使う
ファイアウォールの代わりに、Docker レベルでネットワークを制限する方法もあります。
"runArgs": ["--network=none"],
これでコンテナからの外部通信が完全に遮断されます。ただし、Claude Code 自体が Anthropic API と通信する必要があるため、--network=none では Claude Code が動作しません。
API 通信だけを許可する場合は、Docker のカスタムネットワークとプロキシの組み合わせが必要になり、設定が複雑になります。現実的にはファイアウォール方式（init-firewall.sh）が最もバランスが良いでしょう。
認証情報を使い捨てにする
クローンしたばかりの信頼度の低いリポジトリで作業する場合は、認証情報の永続化ボリュームを外して毎回ログインし直す運用にすることで、トークン漏洩のリスクを軽減できます。
devcontainer.json の mounts から ~/.claude のボリュームマウントを削除すれば、コンテナ終了時に認証情報も消えます。
結局、どういう使い方なら安心か
✅ 安心して使える場面
- 自分が書いたコードのリポジトリで使う
- 社内チームのリポジトリで使う
- 信頼できる OSS プロジェクトに貢献する
- 新規プロジェクトの立ち上げで使う（既存の悪意あるコードが存在しない）
⚠️ 注意が必要な場面
- 見知らぬ第三者のリポジトリをクローンして Claude Code を走らせる
- 悪意のある
package.jsonやMakefileが含まれている可能性があるリポジトリ - 機密性の高いコードと同じコンテナ内で作業する
❌ 避けるべき場面
- ホストマシン上で直接
--dangerously-skip-permissionsを使う（DevContainer なし） - 機密情報（API キー、パスワード等）をハードコードしたファイルが
/workspace内にある状態で、信頼できないコードを扱う
まとめ
DevContainer 内での --dangerously-skip-permissions は、ホスト直接実行と比べて格段に安全です。ファイルシステム分離とプロセス分離により、最も深刻な「ホストマシンの破壊」というリスクは排除されます。
ただし、DevContainer は「何をやっても絶対に安全な箱」ではありません。特にネットワーク経由の情報流出リスクはファイアウォールなしでは残ります。
実用的な指針としては以下のとおりです。
- 自分の信頼できるプロジェクトで使う → 十分安全
- 信頼できないコードを扱う → ファイアウォール有効化を推奨
- ホスト上で直接使う → 避ける
--dangerously-skip-permissions の名前に臆する必要はありませんが、「何が守られていて何が守られていないか」を理解した上で使うことが大切です。