Claude CodeのIDE拡張はどこまで自動編集を許すか

IDE拡張の公式ドキュメントは何を注意点として挙げているか

VS Code拡張とJetBrainsプラグインのセキュリティ節は、どちらも同じ懸念を扱っています。acceptEditsモードでファイル編集を自動承認しているとき、IDEが自動実行する設定ファイルまで書き換えられてしまうという懸念です。

VS Code拡張のドキュメントは、acceptEditsが有効な状態だと何が起きるかを明記しています。VS Codeが自動実行するsettings.jsonやtasks.jsonのようなワークスペース設定ファイルを、Claude Codeが変更できてしまうというものです。対策として3点を挙げています。信頼できないワークスペースではVS CodeのRestricted Modeを有効にすること、編集は自動承認せずManual modeを使うこと、変更を承認する前に必ず内容を確認することです。

JetBrainsプラグインのドキュメントも同じ構図です。acceptEditsモードでは、IDEが自動実行しうる設定ファイルを書き換えられる可能性があります。これがBashコマンドの権限確認を回避するリスクを高めうると説明しています。対策として、Manual modeの利用・信頼できるプロンプトだけを使う・Claude Codeがどのファイルにアクセスできるかを把握しておくことを挙げています。

Claude Code本体の権限モデルはどこまでこれを防いでいるか

この懸念に対して、Claude Code自体の権限モデルにはあらかじめ組み込まれた歯止めがあります。protected pathsです。.vscodeと.ideaはどちらもprotected pathsに含まれる保護対象ディレクトリです。この2つへの書き込みはdefaultモードでもacceptEditsモードでも、常に確認プロンプトを経由します。bypassPermissionsモードと、bypass permissionsが使えるplanモードのセッションを除けば、無確認で自動承認されることはありません。

JetBrainsのドキュメント自身がこの仕組みに言及しています。「acceptEditsとauto modeはどちらも作業ディレクトリ内の編集を確認なしで承認するが、protected pathsは例外」という一文です。つまりIDE拡張の注意書きが警告しているリスクは、Claude Code本体の権限モデルによってすでに部分的に抑え込まれています。.vscode/settings.jsonや.idea配下の設定ファイルをacceptEditsが黙って書き換えることは、通常の運用では起きません。

それでもリスクが残る場面

歯止めがあっても、リスクがゼロになるわけではありません。リスクが実際に顕在化するのは、この歯止めそのものが外れているか、確認プロンプトを深く考えずに承認したときです。

bypassPermissionsモードで運用している場合、protected pathsの保護は働きません。.vscode/tasks.jsonや.idea配下の設定ファイルへの書き込みも他の変更と同じように即座に実行されます。auto modeの場合は分類器の判定に委ねられるため、確認プロンプト自体が出ないまま承認される可能性があります。VS Code・JetBrains双方のドキュメントは「Manual modeを使う」「変更内容を確認する」と繰り返し勧めています。確認プロンプト自体は出るモードであっても、内容を見ずに承認すれば実害につながりうるためです。

JetBrainsにはもう1つ、VS Codeには無い固有のリスク面があります。IDE拡張が内部で動かすMCPサーバーの待受設定です。既定では127.0.0.1のみで待ち受けます。JetBrainsの設定で「すべてのネットワークインターフェースからの接続を許可」を有効にすると、同じローカルネットワーク上の他ホストからもこのポートに到達できるようになります。通信は暗号化されていないws://のため、有効化すると認証トークンと通信内容がネットワーク上を平文で流れます。この設定はWSL2でループバック経由の接続がうまくいかない場合などにのみ使う想定で、既定では無効です。この内蔵MCPサーバー自体の通信・認証・公開ツールの詳細はIDE内蔵MCPサーバーのセキュリティモデルにまとめています。

VS CodeとJetBrainsで何が違うか

同じ懸念を扱っていても、両者の防御線は完全には一致しません。

VS CodeはRestricted Modeという追加の防御層を持つ一方、JetBrainsはネットワーク公開の可否という別の調整項目を持ちます。どちらのIDEを使うかで、意識すべき追加設定が変わります。

なぜこの2つの防御線が両方要るのか

IDE拡張のドキュメントが挙げる懸念と、Claude Code本体のprotected pathsは、守っている対象が少しずれています。protected pathsが直接ブロックするのは.vscodeや.ideaというディレクトリ単位の書き込みです。しかし実際に実行される設定ファイルの範囲は、VS Codeならsettings.jsonやtasks.json、JetBrainsならIDE固有の実行設定というように、IDE側の仕様で決まります。Claude Code側は「このディレクトリへの書き込みは常に確認を挟む」という一律のルールでリスクの入り口を塞いでいます。ただし確認プロンプトに出てくる差分の中身が、実際に自動実行されるものかどうかまでは判定しません。そこを判断するのは、確認プロンプトを見る利用者の役目です。

具体的な場面を想像すると分かりやすくなります。信頼度の低いリポジトリをクローンして、Claude Codeで作業を始めたとします。そのリポジトリには.vscode/tasks.jsonが仕込まれていて、ワークスペースを開くと同時に実行される設定になっていました。acceptEditsモードであっても、このファイルへの書き込み自体はprotected pathsの確認プロンプトを経由します。Claude Codeが無言でこのファイルを新規作成・変更することはありません。ただし確認プロンプトで内容を精査せずに承認してしまえば、次にVS Codeがそのタスクを自動実行するところまでは止められません。VS Code側のRestricted Modeは、まさにこの「実行される段階」を別レイヤーで止める仕組みで、protected pathsの「書き込みを止める」段階とは役割が違います。2つの防御線が異なる段階を担っているからこそ、どちらか一方だけでは不十分です。

実務でどう運用するか

レビューしていない、あるいは信頼度が低いコードを扱うセッションでは、acceptEditsやauto modeよりもManual modeを優先します。Manual modeなら、protected paths以外の通常のファイル編集も含めてすべて確認プロンプトを経由するため、設定ファイルの意図しない書き換えに気づける機会が増えます。Claude Codeの権限モードそのものの全体像はClaude Code権限モデルの変遷で扱っています。auto modeの分類器がどこまでを自動承認しているかはClaude Codeのauto mode分類器は何を止めているかにまとめています。

組織でPreToolUseフックを使ってツールを許可リスト化している場合にも注意点があります。protected pathsへの書き込みは、permissions.allowの許可ルールでは前倒し承認できません。安全チェックは設定ファイルの許可ルール評価より前に走るため、.claude/settings.jsonにEdit(.vscode/**)のような許可を書いても、モードごとの挙動表は変わりません。フックの設計自体はClaude Code Hooks完全ガイドにまとめています。

よくある質問

Manual modeなら設定ファイルの書き換えは絶対に起きませんか

Manual modeでも確認プロンプト自体は表示され、承認すれば書き換えは実行されます。防げるのは「気づかないうちに書き換わる」ことであって、内容を見ずに承認すればacceptEditsと同じ結果になります。

.vscodeや.idea以外の設定ファイルも保護されますか

protected pathsには.git・.config/git・.husky・.claude(worktree用ディレクトリを除く)なども含まれます。IDE固有のディレクトリだけが特別扱いされているわけではなく、リポジトリの動作やClaude Code自身の設定に関わる一連のディレクトリがまとめて対象です。

bypassPermissionsモードでIDE拡張を使うのは危険ですか

protected pathsの保護が効かなくなるため、.vscodeや.idea配下への書き込みも他の変更と同様に無確認で実行されます。信頼できるプロンプトだけに使う、レビュー済みのタスクに限定するといった運用上の注意がより重要になります。

VS CodeのRestricted Modeを有効にすると、Claude Codeでの作業に支障が出ますか

Restricted ModeはVS Code標準の機能で、ワークスペースを信頼するまで自動実行されるタスクや一部の拡張機能の動作を制限します。信頼できないリポジトリを一時的に開いて確認するような場面での追加の防御として使うもので、日常的に自分が管理しているリポジトリまで常時有効にする必要はありません。

JetBrainsのネットワーク公開設定は既定で有効ですか

既定では無効で、待ち受けは127.0.0.1のみです。CLIがループバック経由でIDEに到達できないWSL2環境などでのみ有効化が想定されており、通常の利用では変更する必要はありません。

まとめ

VS Code拡張とJetBrainsプラグインのセキュリティ節は、どちらもacceptEditsモードがIDEの自動実行対象になる設定ファイルを書き換えうる点を注意点として挙げています。この懸念は、Claude Code本体のprotected pathsによって部分的に抑え込まれています。.vscode・.ideaへの書き込みは、bypassPermissionsを使わない限り確認プロンプトを経由します。リスクが顕在化するのは、この歯止めが外れているか、確認プロンプトを内容を見ずに承認したときです。信頼度の低いコードを扱うときはManual modeを基本にし、JetBrainsではネットワーク公開設定を必要な場合以外は有効にしないことが実務上の防御線になります。