知人から「共有のWindowsマシンでClaude Codeをちょっと試したいんだけど、変なコマンドを実行されたり外部にデータを送られたりしないか心配」と相談されたことがあります。私も業務効率化の相談を受けるたびに似たような不安をぶつけられます。rmを叩かれるのも怖いし、うっかり社外のAPIにWebFetchで何かを送られるのも困る。かといって毎回全部の提案を1つずつ確認していたら、AIエージェントを使う意味が半分くらいなくなってしまいます。
そんな悩みにわりとそのまま刺さる新モードが、Claude Code v2.1.248（2026-08-27の公式changelogに記載）で来ました。--restrictedフラグ（もしくは環境変数CLAUDE_CODE_RESTRICTED=1）です。今回はこのモードを、公式ドキュメント（code.claude.com/docs）の記述をもとに整理してみます。手元でv2.1.248以降を用意して実際に触ったわけではなく、一次情報の読み込みベースの記事であることは先に断っておきます。
毎回自分で確認する、では疲れる
一番安全なのは、Manualモードのまま全部の操作を自分の目で確認することです。コマンド実行のたびに「Yes」を押す。ファイル編集のたびに差分を見る。これなら事故は起きませんが、共有マシンで人に触らせる場面ではそもそも本人が張り付いていないといけません。以前Hooksで許可待ちのタイミングに音を鳴らす話を書きましたが、あれも結局「人間がどこかで確認する」ことが前提の仕組みでした。共有マシンを他人に渡すシーンでは、この前提そのものが崩れます。
–dangerously-skip-permissionsに全部任せるのも違う
じゃあ--dangerously-skip-permissions（bypassPermissions）で全部Claudeに任せてしまえばいいかというと、名前の通り危険です。Auto modeがデフォルト化した記事でも触れましたが、Auto modeはクラシファイアがレビューしてくれる分だけまだ抑制が効いています。bypassPermissionsは文字通り全部素通しなので、共有マシンや不慣れなリポジトリで気軽に使えるものではありません。しかも実はこのモード、root/sudo権限で起動しようとすると拒否される安全策が以前から入っています。ここは--restrictedの新機能ではなく、bypassPermissions自体が持っている既存の防御で、後で出てくる話と混同しないよう先に断っておきます。
そこで–restricted：4つの引き算
公式のCLIリファレンスには、--restrictedの説明がこう書かれています。
「評価用ハーネスが共有マシン上でclaudeを動かし、Claude Codeがコマンドを実行したりそのマシンのユーザー・プロジェクト設定を読んだりしてはいけない場合に使う。Claude Codeはコマンドやコードを実行する組み込みツールとWebFetchを取り除く。
--toolsで個別に名指し（defaultプリセット経由ではなく）しない限りは。組み込みのファイルツールも作業ディレクトリの中に閉じ込め、managed settingsと--settingsだけを読み込み、bypassPermissionsを拒否し、restrictedセッションからのクラウドセッション作成も拒否する」（筆者要約訳）
整理すると次の4つです。
- コマンド・コード実行系のツールと
WebFetchを丸ごと除去する（--toolsで個別に指定すれば戻せるが、defaultプリセットでの一括指定は不可） - ファイル操作系ツールを作業ディレクトリの中に固定する
- 読み込む設定はmanaged settingsと
--settingsだけに限定し、ユーザー・プロジェクト・ローカルのsettings.jsonは無視する - bypassPermissionsを拒否し、クラウドセッションの作成も拒否する
クローンしてきたリポジトリの.claude/settings.jsonにどんな許可ルールやhooksが仕込まれていても、restrictedモードならそれごと無視してくれるわけです。素性のわからないリポジトリを触るときにありがたい仕様ですね。
ここまでを一度モードの一覧として整理しておきます。
| モード | 確認なしで動く範囲 | bypassPermissions | 設定ファイル |
|---|---|---|---|
| Manual（default） | ほぼ毎回プロンプト | 使える | ユーザー/プロジェクト/ローカルすべて読む |
| Auto | クラシファイアが判断 | 使える | 同上 |
| dontAsk | allowルールと読み取り専用コマンドのみ | 使える | 同上 |
| bypassPermissions | 全部素通し | （これ自体） | 同上 |
| –restricted | 作業ディレクトリ内のファイル操作＋--toolsで指定した分 |
拒否 | managed settingsと--settingsのみ |
こう並べると、--restrictedだけ毛色が違うのがわかりますよね。他のモードが「確認の頻度」を変える設計なのに対して、--restrictedは「そもそも読み込む設定と使えるツールの種類」を変える設計になっています。
評価用ハーネスやCIでの利用も想定に入っている
公式のCLIリファレンスの説明文には「評価用ハーネスが共有マシン上でclaudeを動かす」場面が名指しで挙がっていました。無人ループでClaude Codeを毎日回している身としては、この一文に妙に納得しました。CIのジョブや採点用のハーネスにClaude Codeを組み込むとき、そのマシンに元から置いてあるsettings.jsonやhooksに何が仕込まれているか、実行時に全部把握しきれるとは限りません。--restrictedならそのマシン固有の設定を無視して、渡した--settingsとmanaged settingsだけで動いてくれます。再現性が欲しい自動実行の文脈でも使い道がありそうです。
ただし、作業ディレクトリを広げる--add-dirが--restrictedと併用したときにどう振る舞うのかは、今回読んだ範囲のドキュメントには明記がありませんでした。working directoriesの説明ページと--restrictedのページが別々に書かれていて、両者の交差点までは踏み込んでいない印象です。ここも実際に試すまでは何とも言えません。
Auto modeで動かしても抜け道がない
これ、意外と効きます。保護対象パスへの書き込みまわりの話です。通常のAuto modeでは、.gitや.vscodeのような保護ディレクトリへの書き込みはクラシファイアが判断してくれます（許可されることもある）。ところが公式ドキュメントには、--restrictedで始めたセッションでは「クラシファイアは保護パスへの書き込みを承認できない」とはっきり書かれています。つまりAuto modeで動かしていても、restrictedである限りは.gitまわりへの書き込みは常にプロンプト行きか拒否になるということです。settings.jsonのpermissions.allowルールも、この安全チェックより後で評価されるので効きません。二重どころか三重にガードがかかっている印象です。
CLAUDE_CODE_RESTRICTED、ドキュメントには出てこない
ここは正直に書いておきます。公式changelogには「--restricted（もしくはCLAUDE_CODE_RESTRICTED=1）」という書き方で環境変数も紹介されているのですが、CLIリファレンスのフラグ解説ページを見た限りでは環境変数の名前が明記されたセクションを見つけられませんでした。挙動としては同じはずですが、環境変数経由の指定はドキュメント上の裏取りがchangelogの記述どまりだった、という点は注記しておきます（実機で試せる方がいたら教えてください）。
それでもどこまで動くのか
ここまで読むと「結局何もできないのでは」と思うかもしれませんが、そういうわけではありません。ドキュメントの書きぶりから素直に読み取れる範囲では、作業ディレクトリの中でのファイルの読み書き・検索（Read/Edit/Write/Grep/Glob系のツール）は生きています。除去されるのは明示的に「コマンドやコードを実行するツール」と「WebFetch」だけです。コードレビューやリファクタリング提案のように、ファイルを読んで書き換えるだけで完結する作業なら、restrictedモードのままでも十分成立しそうです。
一方でWebSearchやMCP経由のツールがこの制限をどう扱われるのかは、今回読んだ範囲のドキュメントには明記がありませんでした（次のマイナーバージョンで書き足されるのかもしれません）。ここは私も「わからない」ので、断定はしません。試すとしたら、まず--toolsで何を追加できるか、追加したツールが本当に作業ディレクトリの外を触れないままなのかを、まずはご自身の手元で試してみましょう。
共有マシンや不慣れなリポジトリで試すときの基準に
というわけで、--restrictedは「コマンド実行とWebFetchを封じ、ファイルを作業ディレクトリに閉じ込め、外部の設定に一切左右されない、素の権限」でClaude Codeを動かすためのモードです。冒頭の相談のように、共有マシンで人に触らせたいけれどrmや外部送信は怖い、という場面にはかなり具体的に効きそうです。ただし今回の記事は公式ドキュメントの読み込みが中心で、実機での検証はしていません。実際に運用に組み込む前には、ご自身の環境でv2.1.248以降を用意して、想定している操作が本当に通るか・通らないかを一度手を動かして確かめることをおすすめします。試された方はぜひコメントで結果を教えてください。
コメント