Claude Code セキュリティ｜サンドボックスの守備範囲と公開アドバイザリで見る攻撃面・確認コマンド

「Claude Code セキュリティ」を調べると、多くの記事が「権限を絞りましょう」「サンドボックスを有効にしましょう」で終わる。だが実際に公開されている脆弱性報告を並べると、問題の中心は「AIが何をするか」ではなく「AIを動かす前に、誰が何を承認したことになっているか」の実装にある。この記事は、anthropics/claude-code に公開済みのGitHub Security Advisory 30件（2026-08-14時点・GitHub API実測）を類型化し、公式ドキュメントが明記している既定値と突き合わせて、サンドボックスが実際には何を守り、何を守らないのかを確定させる。

ソフトウェア供給網全体の攻撃手法と防御ツールの地図は サプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリスト にまとめてある。本稿はその中でも「開発者の手元で動くAIエージェント」という一点に絞り、設定の既定値と、その既定値が破られた実例だけを扱う。

Claude Code セキュリティの前提——守られているのは「承認境界」であってモデルではない

公式ドキュメントの Security ページは、防御の考え方を一文で言い切っている。

Claude Code only has the permissions you grant it. You’re responsible for reviewing proposed code and commands for safety before approval. （Security — Claude Code Docs）

つまり Claude Code の安全性は、モデルが賢いことではなく、「許可されていない操作は実行に到達しない」という実装に依存している。この実装は独立した3枚の板でできている。

・権限（permissions）：ツール単位・コマンド単位の allow / deny。既定は読み取り専用で、ls・cat・git status などの組み込み読み取り専用コマンドだけがプロンプト無しで走る
・信頼（trust verification）：初回のリポジトリと新規MCPサーバーに対する信頼確認ダイアログ
・サンドボックス（sandbox）：Bashコマンドとその子プロセスに対するOSレベルのファイルシステム／ネットワーク隔離

この図の右下、E → G の枝が本稿でいちばん重要な既定値である。詳細は次章に譲るが、先に押さえておきたいのは 3枚の板は直列であって多重ではないという点だ。上流の信頼確認が外れれば、その下の権限判定は攻撃者が用意した設定ファイルの上で行われることになる。

承認判定は fail-closed、サンドボックスは fail-open——非対称がある

公式ドキュメントは、コマンドの承認判定について明示的に fail-closed を宣言している。

Fail-closed matching: Unmatched commands default to requiring manual approval

一方、サンドボックスの起動失敗については逆の設計になっている（次章で引用する）。「判定に迷ったら止める」が採られているのは承認レイヤーだけで、隔離レイヤーは「使えなければ使わずに進む」。この非対称は、公式ドキュメントを2ページ横断して読まないと見えない。

非対話実行（-p）は信頼確認をまるごと外す

CI やスクリプトから Claude Code を回している場合、次の一文が効いてくる。

Note: Trust verification is disabled when running non-interactively with the -p flag

信頼確認は「攻撃者が用意したリポジトリの設定ファイルを読む前に人間に聞く」ためのゲートである。それが -p で外れるということは、CIで未検証のリポジトリを処理するワークフローでは、このゲートを最初から数に入れてはいけないということになる。あわせて、ホームディレクトリ直下で起動した場合の信頼受諾はセッション限りでディスクに保存されず、永続化する設定も無い（公式ドキュメント記載）。

Accept Edits モードが自動承認する範囲は「編集」だけではない

もうひとつ、名前から受ける印象と実装がずれている箇所がある。

Accept Edits mode: Auto-approves file edits and a fixed set of filesystem Bash commands like mkdir, touch, rm, mv, cp, and sed for paths in the working directory.

「編集を受け入れる」モードは、作業ディレクトリ内に限ってではあるが rm と mv と sed を自動承認する。作業ディレクトリの中に消えて困るものを置いているかどうかが、そのままこのモードのリスクになる。過去に報じられた「AIエージェントが本番データベースを短時間で消した」類の事故が示したのも、モデルの判断力より先に そこに何が置いてあり、何が自動承認になっているか が効くという構図だった。

サンドボックスの守備範囲——対象はBashのみ、既定は「起動できなければ素通し」

claude code サンドボックス というクエリで検索する人が実際に知りたいのは、「有効にしたら何が防げるのか」だと思う。公式ドキュメントの記述を、防げる／防げないで割り切って並べる。

既定の fail-open は「設計ミス」ではなく「明示された選択」

この挙動は隠されているわけではなく、ドキュメントに Note として書かれている。

By default, if the sandbox cannot start because dependencies are missing or the platform is unsupported, Claude Code shows a warning and runs commands without sandboxing. To make this a hard failure instead, set sandbox.failIfUnavailable to true. This is intended for managed deployments that require sandboxing as a security gate.

読むべきは最後の一文である。「サンドボックスをセキュリティゲートとして必須にしたい配備向け」と書かれているということは、裏を返せば 既定の配備ではサンドボックスはゲートとして扱われていない。「サンドボックスを有効にした」と思っている環境が、依存パッケージの欠落やWindowsネイティブ起動によって静かに素通しになっている可能性は、設定を読むだけでは分からない。だから確認コマンドが要る（後述）。

Linuxでは、パッケージを入れてもなお起動できないケースが1つ文書化されている。Ubuntu 24.04以降は既定のAppArmorポリシーが bubblewrap のユーザー名前空間作成を阻むため、sysctl kernel.apparmor_restrict_unprivileged_userns が 1 を返す環境では bwrap 用のAppArmorプロファイルを追加するまで隔離が立ち上がらない（キーが存在しない・0 を返すなら対処不要）。「入れたのに効いていない」がいちばん起きやすいのがこの組み合わせである。

ファイルシステム隔離を切ると、自己昇格の余地が生まれる

sandbox.filesystem.disabled: true はネットワーク隔離だけ残す設定だが、この危険性についてもドキュメント自身が警告している。

With filesystem isolation off and commands auto-allowed, a sandboxed command can write files that later commands run or read, such as shell startup files, executables on $PATH, or ~/.claude/settings.json, and use them to widen its own access on the next run.

サンドボックス内のコマンドが ~/.claude/settings.json を書き換えて、次回の自分の権限を広げられるという自己昇格の筋道が、公式に認められている。これは後述する公開アドバイザリの類型（設定ファイル経由の権限昇格）とまったく同じ形である。設定ファイルが「実行より前に読まれる入力」である以上、そこに書き込める者が実質的な権限保持者になる。

読み取りブロックの優先順位には非直感的な規則がある

denyRead と allowRead が重なった場合、より具体的なパスが勝つ。

後者が重要で、「広く許可してしまったせいで秘密が漏れる」事故は仕様上起きない。逆に言えば、秘密の保護は denyRead を自分で書いた分しか効かない。

公開アドバイザリで見る攻撃面——GitHub Security Advisories 30件の実測

ここからは実測データに移る。gh api repos/anthropics/claude-code/security-advisories で取得できる公開アドバイザリは、2026-08-14時点で 30件だった。

類型化：壊れているのは「サンドボックスの中」ではなく「サンドボックスに入る前」

30件のサマリ文字列を、攻撃が成立する位置で分類した（分類は本稿によるもので、Anthropic公式のカテゴリではない。判定にはアドバイザリの summary を用いた）。

この分布が本稿の結論を決めている。 サンドボックス脱出は3件しかない。多数派は「承認を通ってしまう」「信頼確認を通ってしまう」「作業ディレクトリの外に書けてしまう」——隔離の話に到達する前の段階である。したがって「サンドボックスを有効にしたから安全」という運用は、実際に報告されている攻撃面の大半に対応していない。

最新のCVE-2026-55607は、.git という名前のworktreeとsymlink、core.fsmonitor を連鎖させてseatbeltサンドボックスの外でコードを実行させるもので、信頼確認・パス解決・サンドボックスの3枚すべてを順に抜けている。個別の機構と修正版の確認手順は Claude Code脆弱性CVE-2026-55607解説｜git worktree経由のサンドボックス脱出と対策 にまとめてある。

時系列（タイムライン）——2026年に公表された17件、GHSA公表日順

日付は repo API の published_at（GHSA公開日）で、NVDの登録日とは一致しないことがある。2月に7件が集中しているのは、承認バイパス系の報告がまとめて公表されたためである。

「claude code 危険」という検索が想定しているような ワンクリックで全部持っていかれる致命的な穴 は、この一覧の中には無い。代わりに並んでいるのは、「承認したつもりの範囲」と「実際に実行される範囲」が少しずつずれるタイプの不具合である。だからこそ、単発のCVEを個別に追うより、自分の環境でどの境界が有効になっているかを定期的に確認するほうが費用対効果が高い。

設定ファイルは「実行前に読まれる入力」である

類型を横断して繰り返し現れるのが、リポジトリ側が用意した設定を、信頼確認より前あるいは検証不十分なまま読んでしまうという形である（CVE-2026-21852・CVE-2026-33068・CVE-2026-25725・CVE-2026-35603）。前章で見た公式ドキュメントの「~/.claude/settings.json に書ければ次回の権限を広げられる」という警告と、同じ構造をしている。

・設定ファイルに書き込める＝将来の権限を決められる
・設定ファイルを読ませられる＝現在の権限を決められる
・したがって、防御側が守るべき第一の資産はソースコードではなく設定ファイルの書き込み権限である

Cursorとの比較——2026年の脆弱性はサンドボックス脱出に集中している

同じ手法で cursor/cursor のアドバイザリを数えると 33件（2024年3件／2025年21件／2026年9件。critical 2・high 22・medium 7・low 2）。件数はClaude Codeと同水準だが、内訳の形がはっきり違う。日本語で cursor 脆弱性 を調べると個別CVEの解説記事が出てくるが、並べて数えると傾向が見えてくる。

Cursorの2026年分は、sandbox escape via Git hooks（CVE-2026-26268）、Cursor Desktop sandbox escape via Claude hook configuration（CVE-2026-48124）、sandbox escape via agent-controlled working directory／via symlink and failed path canonicalization（CVE-2026-50548／50549、いずれもcritical）、Cloud Agent Browser Sandbox Escape（CVE-2026-61613）、Sandbox escape via tampered Python virtual environments／via launching privileged containers（CVE-2026-73217／73218）と、7件すべてがサンドボックスの外に出る話である。CVSS 9.8が付いた50548/50549の機構は Cursor IDE脆弱性DuneSlide解説｜CVE-2026-50548/50549でゼロクリックRCE で詳しく扱っている。

読み取れること：Cursorは「隔離の実装」が繰り返し破られており、Claude Codeは「隔離に入る前の判定」が繰り返し破られている。どちらもエージェントを閉じ込める境界の実装が主戦場であり、モデルの出力フィルタの話ではない。したがって導入判断の質問は「このツールのAIは安全か」ではなく、「このツールの境界はどこにあり、それが破れたとき何が読まれ・書かれるのか」になる。

Claude Code セキュリティを自環境で確認する6つのコマンド

ここまでの前提を、自分の環境で確かめる。claude --version だけでは、上で見た既定値のどれが効いているかは分からない。

検証環境: macOS 14.5 ／ Claude Code 2.1.220 ／ 2026-08-14 実行

# 1) バージョンと実体。PATH上に複数の実体が併存していないか
claude --version
which -a claude

# 2) 設定の実効値。sandbox・permissions 系のキーが実際に入っているか
#    （user / project / local / managed の4スコープを個別に見る）
for f in ~/.claude/settings.json .claude/settings.json .claude/settings.local.json \
         "/Library/Application Support/ClaudeCode/managed-settings.json"; do
  [ -f "$f" ] && printf '\n== %s ==\n' "$f" && \
  python3 -c "import json,sys;d=json.load(open(sys.argv[1]));print(json.dumps({k:d[k] for k in ('sandbox','permissions','enableAllProjectMcpServers') if k in d},ensure_ascii=False,indent=2))" "$f"
done

# 3) fail-open のままか。true でなければ「起動できなければ素通し」
grep -rh "failIfUnavailable\|allowUnsandboxedCommands\|autoAllowBashIfSandboxed" \
  ~/.claude/settings.json .claude/settings.json .claude/settings.local.json 2>/dev/null \
  || echo "→ いずれも未設定＝既定値（fail-open / 再試行あり / 自動承認あり）"

# 4) Linux/WSL2 でサンドボックスの依存が揃っているか（macOSはSeatbelt利用のため不要）
command -v bwrap socat 2>/dev/null || echo "→ 依存が無い環境では既定でサンドボックスが起動しない"
# 4b) Ubuntu 24.04以降：AppArmorがbubblewrapの名前空間作成を止めていないか（1 なら要対処）
sysctl kernel.apparmor_restrict_unprivileged_userns 2>/dev/null || echo "→ キー無し＝この制限は無い"

# 5) 登録済みMCPサーバーの棚卸し。stdio 起動のコマンド行まで見る
find . ~/.claude -maxdepth 3 -name ".mcp.json" -o -maxdepth 3 -name "settings.json" 2>/dev/null \
  | xargs grep -l "mcpServers" 2>/dev/null \
  | xargs -I{} sh -c 'echo "== {}"; python3 -c "import json,sys;print(list(json.load(open(sys.argv[1])).get(\"mcpServers\",{}).keys()))" {}'

# 6) 資格情報の deny/mask リストが空でないか（既定は空＝無保護）
grep -rh -A5 "\"credentials\"" ~/.claude/settings.json .claude/settings.json 2>/dev/null \
  || echo "→ credentials 未設定＝APIキー・~/.aws/credentials 等はサンドボックス内から読める"

上の実行例では、検証機（macOS 14.5）に managed-settings.json は存在せず、socat も未導入だった。macOSはSeatbelt利用のため socat 不要だが、同じ設定ファイルをLinux/WSL2に配ると、そこでは依存不足でサンドボックスが起動せず fail-open になる——設定を共有していても実効値が環境で変わる、という点がこの確認の要である。

対策：既定値を上書きすべき3行

上のコマンドで「未設定＝既定値」と出た場合、最小の対策は次の3つを明示することになる。

{
  "sandbox": {
    "failIfUnavailable": true,        // 起動できないならコマンドを実行しない（fail-open をやめる）
    "allowUnsandboxedCommands": false, // dangerouslyDisableSandbox による再試行を無効化
    "credentials": {
      "files":   [{ "path": "~/.aws/credentials", "mode": "deny" }, { "path": "~/.ssh", "mode": "deny" }],
      "envVars": [{ "name": "GITHUB_TOKEN", "mode": "deny" }, { "name": "NPM_TOKEN", "mode": "deny" }]
    }
  }
}

補足として、credentials はサンドボックス下のBashコマンドにしか効かない。サンドボックスの有無に関係なく全サブプロセスから Anthropic およびクラウドプロバイダの資格情報を落としたい場合は、環境変数 CLAUDE_CODE_SUBPROCESS_ENV_SCRUB を使う（公式ドキュメント記載）。また mode: "mask"（実値を出さずにプロキシが送信時だけ差し替える）は Claude Code v2.1.199以降が必要で、deny と併記された場合は deny が優先される。

影響範囲マトリクス——どの設定が、どの攻撃面を止めるか

前章までに出た攻撃面と、設定・運用の対応を1枚に落とす。空欄が多いことがこの表の情報である——単一の設定で広く効くものは無い。

MCP行の「サンドボックス対象外」は運用上とくに効く。公式ドキュメントは、Anthropicがコネクタをディレクトリ掲載基準で審査するとしつつ、こう明記している。

Anthropic … does not security-audit or manage any MCP server.

MCPサーバーは自分で選び、自分で監査する対象である。エージェント側からMCPサーバーが乗っ取られる経路（設定ファイルの書き換え、stdio越しの権限混同、承認UIの誤誘導）は本サイトでも個別に扱ってきたが、共通しているのは「MCPを足すたびに信頼境界が1本増える」という点だ。

この記事が扱っていないこと——「学習に使われるか」は別の問題

Claude Code セキュリティ という言葉は、実際には性質の違う2つの問いを含んでいる。

この2つは対策も担当も違う。前者は契約・設定・監査ログの話で、情シスや法務が主体になる。後者は開発者が自分の端末で確認するしかない。「学習には使われない契約になっている」ことは、手元で任意コードが走らないことを何ら保証しない。

なお、Claude Code そのものの導入・設定・運用全般（インストール、CLAUDE.md、Hooks、権限の書き方）は Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引き にまとめてある。本稿はそこからセキュリティ境界の部分だけを切り出したものだと考えてほしい。

まとめ——3つの持ち帰り

・「サンドボックスを有効にした」は状態ではなく仮説である。 対応プラットフォームか、依存が揃っているか、failIfUnavailable を立てたかを確認するまで、既定では素通しでも警告が出るだけで動き続ける
・公開アドバイザリ30件の多数派は隔離の外側で起きている。 承認・信頼・パス制限という、サンドボックスに到達する前の判定が主戦場
・設定ファイルへの書き込み権限が最上流の資産である。 公式ドキュメント自身が、サンドボックス内から ~/.claude/settings.json を書けば次回の権限を広げられると警告している

参照ソース

・Security — Claude Code Docs（Anthropic公式） — 権限アーキテクチャ・プロンプトインジェクション対策・-p での信頼確認無効化・MCPの責任範囲・Accept Editsの自動承認範囲
・Configure the sandboxed Bash tool — Claude Code Docs（Anthropic公式） — 適用対象・対応プラットフォーム・failIfUnavailable の既定・dangerouslyDisableSandbox・credentials の既定が空である旨
・GitHub Security Advisories — anthropics/claude-code — 本稿の30件の一次データ（gh api repos/anthropics/claude-code/security-advisories で2026-08-14に取得）
・GitHub Security Advisories — cursor/cursor — Cursorの33件および2026年分の類型
・GHSA-7835-87q9-rgvv — Sandbox Escape via Git Worktree Path Confusion（Anthropic公式アドバイザリ） — CVE-2026-55607 の機構と修正版
・NVD — CVE-2026-55607 — CVSS採点・CWE分類・登録日（GitHub側と日付定義が異なる点の確認に使用）