Claude CodeのIDE拡張はどこまで自動編集を許すか
IDE拡張の注意書きが挙げるacceptEditsのリスクを、protected pathsの保護範囲・既定モード・VS CodeのRestricted Modeの実際の挙動から切り分けます。
IDE拡張の注意書きが警告しているのは何か
VS Code拡張とJetBrainsプラグインのセキュリティ節は、どちらも同じ懸念を挙げています。自動編集が有効なとき、IDEが自動実行する設定ファイルまで書き換えられうるというものです。
VS Code側の例はsettings.jsonとtasks.jsonです。JetBrains側は、acceptEditsモードだとIDEが自動実行しうる設定ファイルを変更でき、それがBashコマンドの権限確認を回避するリスクを高めうる、という書き方です。対策には重なる部分があります。どちらもManual modeでの編集を挙げています。VS Codeは変更を確認してから承認すること、JetBrainsは信頼できるプロンプトだけを使うことも挙げています。信頼できないワークスペースでのRestricted Modeは、VS Codeだけが挙げる対策です。
ではClaude Code本体は、この書き込みをどこまで止めてくれるのでしょうか。結論から言うと、.vscodeと.ideaへの書き込みはbypassPermissionsを使わない限り自動承認されません。ただし「確認プロンプトが出る」のは一部のモードだけで、既定のモードでは別の仕組みが判断します。
.vscodeと.ideaへの書き込みはモードごとにどう扱われるか
.vscodeと.ideaは、Claude Codeのprotected pathsに含まれています。protected pathsへの書き込みは、bypassPermissionsと、bypass permissionsが使える対話端末のplanモードを除き、自動承認されません。
| モード | protected pathsへの書き込み |
|---|---|
default(Manual) / acceptEdits | protected pathsへの書き込み確認プロンプトを経由する |
plan | protected pathsへの書き込みbypass permissionsが使える対話端末では許可。それ以外はauto modeが使えれば分類器へ、使えなければ確認プロンプト |
auto | protected pathsへの書き込み分類器の判定に回る |
dontAsk | protected pathsへの書き込み拒否される |
bypassPermissions | protected pathsへの書き込み許可される |
見落としやすいのはautoの行です。permission-modesの表では、v2.1.283以降の起動時の既定がautoです。それ以前は、Pro・Max・Teamで機能フラグを取得できたセッションがauto、そうでなければdefaultでした。
changelogでは、この変更が段階的に入っています。v2.1.283はサードパーティープロバイダーやテレメトリー無効の対話セッションが対象です。v2.1.284(2026-09-28)で、設定がない端末とVS Codeのセッションが全プラン・全プロバイダーでauto起動になりました。v2.1.285では、サードパーティープロバイダーやテレメトリー無効の環境で、-pとPython版Agent SDKのセッションもautoで始まるようになりました。
autoが使えないセッションは、Manualで始まります。モデルが非対応の場合や、設定ファイルでdisableAutoModeが"disable"の場合です。それ以外の設定を触っていない環境では、.vscode/tasks.jsonへの書き込みは人間への確認ではなく分類器に回ります。「acceptEditsを避ければ安全」という読み方は、既定のままでは当てはまりません。分類器が何を止めるかはauto mode分類器の解説にあります。
JetBrainsの注意書きも同じ区別をしています。acceptEditsとauto modeは、どちらも作業ディレクトリ内の編集を確認なしで承認します。例外がprotected pathsです。一覧に無い設定ファイルは、作業ディレクトリ内なら保護されません。
protected pathsに入っているもの
リストはIDEごとに分かれていません。VS CodeでもJetBrainsでも、同じ一覧が適用されます。
protected pathsの中身
ディレクトリ
.git/.config/git/.vscode/.idea/.husky/.cargo/.devcontainer/.yarn/.mvn/.claude(worktree用の.claude/worktreesを除く)ファイル
.gitconfig/.gitmodules/ シェルの起動ファイル(.bashrc/.zshrc/.profile/.envrcなど) /.npmrc/.yarnrc/.bazelrc/.pre-commit-config.yaml/lefthook.yml/.devcontainer.json/.mcp.json/.claude.jsonなどプラグイン
--plugin-dirで読み込んだディレクトリ。ファイルが変わるとClaude Codeがそのコードを再読み込みして実行するためです
IDEの設定ファイルに限らず、リポジトリを開いただけで動き出すもの(git hooks、devcontainer、パッケージマネージャーの設定)が広く含まれています。
書き込みを止める層と、実行を止める層は別物
protected pathsが止めるのは、あくまでClaude Codeによる書き込みです。そのファイルをIDEが自動実行する段階は、Claude Codeの管轄ではありません。信頼できないリポジトリを扱うときは、2つの層を別々に考える必要があります。
2つの防御層
Claude Code側
.vscode / .ideaなどへの編集を、モードに応じて確認プロンプト・分類器・拒否のいずれかに回します。確認プロンプトなら承認する人が、分類器なら分類器が判断します。
IDE側
VS Codeには、信頼していないフォルダーの機能を制限するRestricted Modeがあります。JetBrainsの注意書きが挙げる対策は、Manualモードの使用、信頼できるプロンプトだけの利用、変更可能なファイルの把握です。
たとえばクローンしたリポジトリに、タスク定義の.vscode/tasks.jsonが最初から入っていたとします。フォルダーを信頼したあとは、そのタスクを誰かが実行できる状況が、Claude Codeが何も書かなくても成立します。Restricted Modeでは、タスクを実行・列挙しようとすると信頼の確認が出ます。Claude Codeにtasks.jsonを書かせて承認した場合は、差分が何を実行するのかを読むのは承認する人です。
VS CodeのRestricted ModeではClaude Code拡張が動かない
ここで注意が要ります。VS Code拡張のトラブルシューティングには、「ワークスペースの信頼を確認する。拡張機能はRestricted Modeでは動作しない」と書かれています。注意書きが勧める「信頼できないワークスペースでRestricted Modeを有効にする」を実行すると、そのワークスペースではClaude Code拡張が使えません。
VS CodeのRestricted Modeは、AIエージェント・ターミナル・タスク・デバッグ・ワークスペース設定・拡張機能の動作を制限します。ワークスペースの設定の一部も無効になります。したがってRestricted Modeは「Claudeに作業させつつ実行だけ止める」設定ではなく、「信頼するまでClaude Code拡張を使わない」という線引きとして働きます。拡張を動かすなら、そのフォルダーを信頼する判断が先に要ります。
設定ファイルでモードを仕込まれることはあるか
悪意のあるリポジトリが、自分からbypassPermissionsやacceptEditsを既定にしてしまう経路があるかどうかは、拡張と端末で違います。
- VS Code拡張:
claudeCode.initialPermissionModeはユーザー設定からだけ読まれ、ワークスペースの値は無視されます。v2.1.225より前は、ワークスペースの値も適用されていました。拡張が起動するセッションは、プロジェクトの.claude/settings.jsonを起動時のモード決定には読みません - 端末: プロジェクトの
.claude/settings.jsonのpermissions.defaultModeは、autoとbypassPermissionsを除く値が有効です。リポジトリがacceptEditsを既定にすることは、設定上は可能です
VS CodeのbypassPermissionsは、allowDangerouslySkipPermissionsを有効にするとモード選択肢に加わります。信頼できないコードを開く環境では、この設定をfalseのままにします。
手元のclaude 2.1.287で確認できる範囲
claude --helpは、モードの選択肢を次のように表示します(v2.1.287)。
$ claude --version
2.1.287 (Claude Code)
$ claude --help
--permission-mode <mode> Permission mode to use for the session
(choices: "acceptEdits", "auto",
"bypassPermissions", "manual",
"dontAsk", "plan")
--ide Automatically connect to IDE on startup
if exactly one valid IDE is availablemanualが選択肢に並んでいて、設定ファイル側の値defaultと同じモードを指します。VS Codeの設定ではmanualはdefaultの別名です。--ideは、IDEが1つだけ見つかったときにだけ自動接続します。
名前が紛らわしいのが--restrictedです。これはVS CodeのRestricted Modeとは別物の起動オプションです(v2.1.248以降)。コマンド実行系のツールとWebFetchを外し、ファイルツールを作業ディレクトリに閉じ込め、bypassPermissionsを拒否します。このモードのセッションでは、分類器はprotected pathsへの書き込みを承認できません。
JetBrainsだけにある待受設定の落とし穴
IDE拡張が内部で動かすMCPサーバーの待受は、JetBrainsに固有の調整項目があります。VS Code側は127.0.0.1固定でポートも変更できません。
JetBrainsの設定はSettings → Tools → Claude Code [Beta] → Networking (Advanced)にあります。項目名は「Accept connections from all network interfaces」です。無効なら127.0.0.1のみ、有効にするとローカルネットワークからポートに到達できます。接続には認証トークンが要りますが、通信は暗号化されないws://のため、有効時はセッションの内容もトークンも平文でネットワークを流れます。この設定が想定しているのは、WSL2の既定のNATネットワークやリモートIDE構成のように、ループバックで届かない場合です。WSL2の接続不具合では、ファイアウォール規則の許可が第一の対処で、ループバックを共有できるmirrored networkingへの切り替えは代替です。内蔵MCPサーバーの認証やツールの全体像はIDE内蔵MCPサーバーのセキュリティモデルで扱っています。
信頼度の低いリポジトリを開くときの手順
VS CodeとJetBrainsの両方で、順序を決めておくと判断が減ります。
信頼できないリポジトリを扱う順序
- 1
モードを確認する
既定が
autoの環境が多いため、まずモードの表示がManualかどうかを見ます。VS Codeではモード表示にManual、端末ではmanual mode onと出ます。 - 2
Manualに切り替える
Manualなら、編集もほとんどのシェルコマンドも確認を経由します。protected pathsだけでなく通常の編集も、承認する前に目に入ります。
- 3
IDEの設定ファイルは差分を読む
tasks.jsonや.idea配下の実行設定への変更は、自動実行されるものかを読んでから承認します。
許可ルールを整備している組織にも注意点があります。protected pathsへの書き込みは、設定ファイルのpermissions.allowで前倒し承認できません。安全チェックが許可ルールの評価より先に走るため、Edit(.vscode/**)のような許可を書いても、上の表の挙動は変わりません。フックの設計はClaude Code Hooks完全ガイドに、モード全体の移り変わりはClaude Code権限モデルの変遷にあります。
よくある質問
Manual modeなら設定ファイルの書き換えは起きませんか
承認すれば書き換えは実行されます。防げるのは気づかないうちの書き換えだけで、差分を読まずに承認すると、acceptEditsと同じ結果になります。
まとめ
IDE拡張の注意書きは、acceptEditsに限らず、自動承認が働くモード全般に当てはまります。既定がautoのいま、.vscodeへの書き込みを最初に判断するのは人間ではなく分類器です。書き込みを止める層(protected paths)と、書かれた設定を実行する層(IDEのタスク)は別の仕組みです。後者を止めるのはIDE側のRestricted Modeか、差分を読む人です。