Claude Codeで作業ディレクトリ外の読み取りを一括禁止する設定

Claude Codeにはpermissions.blockReadsOutsideWorkingDirectoriesという設定があります。有効にすると、Read・Grep・Glob・LSPの各ツールは作業ディレクトリの外を一切読めなくなります。denyReadやallowReadでパスを1本ずつ書く手間もいりません。1つのBooleanを立てるだけで、ホームディレクトリやマウントされたボリュームへの読み取りを一括で塞げます。

permissions.blockReadsOutsideWorkingDirectoriesとは

permissions.blockReadsOutsideWorkingDirectoriesは、セッションの作業ディレクトリの外にあるパスを、Read・Grep・Glob・LSPの4ツールに読ませなくするBoolean設定です。bypassPermissionsモードを含む、すべての権限モードで適用されます。Claude Code v2.1.257以降が必要です。

ここでいう「作業ディレクトリ」は、Claude Codeを起動したディレクトリ(プライマリ作業ディレクトリ)と、--add-dir・/add-dir・permissions.additionalDirectoriesで追加したディレクトリを合わせた範囲です。/cdでセッションを別のディレクトリへ移動すると、プライマリ作業ディレクトリ自体もそちらに切り替わります。この範囲の外を指すパスすべてが、このブロックの対象になります。

Bashコマンドも対象です。Claude Codeはls・cat・echo・pwd・head・tail・grep・find・wc・which・diff・stat・du・cd、そして読み取り専用のgitサブコマンドを、組み込みの読み取り専用コマンドとして認識しています。これらは通常どのモードでもプロンプトなしで実行されますが、塞がれたパスを実際に読もうとすると、auto modeやbypassPermissionsモードでも確認プロンプトが出ます。シェルのパーサーが構造を追いきれないコマンド(cdを2回連続で行う、サブシェルを使う、など)も同様にプロンプトが出ます。この場合は、コマンドが作業ディレクトリ外のパスを名指ししていなくてもプロンプトが表示されます。ただしサンドボックス側がこのブロックを担っているときは、この確認は出ません。

設定方法 — settings.jsonに1行足すだけ

設定はsettings.jsonに次の1行を足すだけです。

{
  "permissions": {
    "blockReadsOutsideWorkingDirectories": true
  }
}

このキーのスコープは「どの設定ファイルからでも」です。ユーザー設定・プロジェクト設定・ローカル設定・managed settingsのいずれかでtrueが1つでも立っていれば、ブロックは有効になります。リポジトリにチェックインした設定ファイルは、プロジェクトに対してブロックを新たに立てられますが、他のスコープが立てたブロックを外すことはできません。既定値は未設定で、その場合は通常どおり権限モードとルールに従って読み取りが判断されます。

サンドボックスと併用する場合は、同じ設定ファイルに両方のキーをまとめられます。

{
  "sandbox": {
    "enabled": true
  },
  "permissions": {
    "blockReadsOutsideWorkingDirectories": true
  }
}

この構成では、サンドボックス化されたBashコマンドの書き込みは作業ディレクトリ内に限定され、読み取りはblockReadsOutsideWorkingDirectoriesが作業ディレクトリ外を一括で塞ぎます。Claude自身のRead・Grep・Glob・LSPツールも同じ境界に従うため、サンドボックスの内と外で読み取り範囲がずれることもありません。

ブロックが有効でも、Claude Code自身が動作に必要とするファイルは読み取れます。~/.claude/配下のスキル・プラグイン・ルール・サブエージェント・カスタムコマンド、そしてCLAUDE.mdメモリファイルです。作業ディレクトリの範囲は起動したディレクトリが基本ですが、/add-dirで追加したディレクトリも同じ扱いで読み取り可能になります。追加そのものを監査したい場合は、DirectoryAddedフックで/add-dir追加後のディレクトリを監査して取り消すが参考になります。

効果が及ぶ範囲 — ツールとサンドボックスへの影響

permissions.blockReadsOutsideWorkingDirectoriesが塞ぐ範囲は、ツールの種類によって扱いが変わります。

この設定がサンドボックスと組み合うと意味が大きくなります。サンドボックス化されたBashコマンドの既定の読み取り範囲は、いくつかの拒否ディレクトリを除いてコンピューター全体に及びます。~/.aws/credentialsや~/.ssh/のような認証情報ファイルも、既定ではこの広い読み取り範囲に含まれます。書き込みは作業ディレクトリ・追加ディレクトリ・一時ディレクトリに限られる一方、読み取りだけは既定でほぼ無制限に開いている、という非対称な構成です。permissions.blockReadsOutsideWorkingDirectoriesを有効にすると、ホームディレクトリとマウントされたボリュームのルートが、作業ディレクトリ外にある限り読み取り拒否の対象になります。~/.gitconfigのようなツールがホームディレクトリから読むファイルも、他のパスと同じように拒否されます。個別のツールがどうしても必要とする場合は、sandbox.filesystem.allowReadでそのパスだけ再度開けます。サンドボックスとの組み合わせ方はClaude Codeの制限モード(--restricted)の使い方でも扱っています。

サンドボックスが対応していないコマンドは、dangerouslyDisableSandboxを使ってサンドボックス外で再試行されることがあります。再試行はサンドボックスを経由しないため、通常の権限フローに戻ります。permissions.blockReadsOutsideWorkingDirectoriesが有効なときは、この再試行がauto modeの分類器評価に回らず、確認プロンプトに切り替わります。作業ディレクトリ外の読み取りが、サンドボックスの外に出た瞬間だけ無審査で通る、という抜け道を塞ぐ格好です。

denyRead/allowReadで個別に書く場合との使い分け

sandbox.filesystem.denyReadやallowReadは、OSのサンドボックス境界で動く設定です。サンドボックス化されたコマンドが起動するkubectlやterraformのようなサブプロセスの読み取り範囲を、パスの配列で細かく制御します。一方permissions.blockReadsOutsideWorkingDirectoriesは、Claude自身のファイル読み取りツールを直接止める設定で、サンドボックスが有効かどうかに関係なく効きます。

パスごとの例外を管理設定に固定する構成は、Claude CodeのallowManagedReadPathsOnlyで読み取り再許可を管理設定に限定するで扱っています。単純な内外分離だけで足りるなら、permissions.blockReadsOutsideWorkingDirectoriesのほうが設定は少なく済みます。

自動モードの初回プロンプトから有効化する

permissions.blockReadsOutsideWorkingDirectoriesをオフのまま使っていても、auto modeでは作業ディレクトリ外への最初の読み取りで一度だけプロンプトが出ます。ClaudeがRead・Grep・Globのいずれかを作業ディレクトリ外のパスに初めて使ったタイミングです。

選択肢は3つです。「Keep allowing」を選ぶと、以降も同様の読み取りはそのまま実行され、プロンプトは二度と出ません。「Block from now on」を選ぶと、その読み取りは拒否され、Claude Codeはユーザー設定にpermissions.blockReadsOutsideWorkingDirectoriesをtrueとして書き込みます。これ以降のすべてのセッション・すべての権限モードで同じブロックが適用されます。あとで特定のパスを読ませたくなったら、/add-dirでそのディレクトリを追加するか、設定自体を削除します。「Ask again next time」を選ぶと、その読み取りは拒否されますが、次に作業ディレクトリ外を読もうとしたときにまた同じプロンプトが出ます。

バージョンごとの挙動の変化

permissions.blockReadsOutsideWorkingDirectoriesは追加後もいくつかの修正を経ています。

効かない・注意すべき境界

autoMemoryDirectoryがプロジェクトの.claude/settings.json(または信頼済みの.claude/settings.local.json)から来ている場合、そのディレクトリからは自動メモリが読み込まれず、書き込みもされません。ブロックが有効なプロジェクトで自動メモリが動いていないように見えたら、この挙動が原因です。

スコープは「どの設定ファイルからでも」なので、あるスコープでブロックを外そうとしても、他のスコープがtrueを立てていれば無効化できません。逆に言えば、組織のmanaged settingsで一度trueにすれば、開発者側のユーザー設定やプロジェクト設定でこれをfalseに戻すことはできません。

作業ディレクトリに追加できないパスもあります。\\server\shareのようなUNC共有など、ほとんどのネットワークパスは--add-dirで追加できません。パスの存在確認自体がそのホストへの通信を発生させるためです。Windows環境でネットワーク共有を作業ディレクトリに含めたい場合は、共有をドライブレターにマップしたうえで、そのドライブを起動時の--add-dirに渡します。

まとめ

permissions.blockReadsOutsideWorkingDirectoriesは、作業ディレクトリの外を一括で読めなくするBoolean設定です。パスを個別に書くdenyRead/allowReadより設定は簡単ですが、ディレクトリごとの例外は作れません。単純な内外分離で足りるならblockReadsOutsideWorkingDirectories、業務ディレクトリごとに例外を分けたいならdenyRead/allowReadとallowManagedReadPathsOnlyを選びます。v2.1.257以降が必要で、v2.1.271・v2.1.273より前のバージョンではBashコマンド側の検知に抜けがあった点も、アップデート時に確認しておくとよいでしょう。サンドボックスを併用しているチームでは、書き込み側の境界とあわせて読み取り側の境界も、settings.jsonという同じ設定ファイルの中でまとめて管理できます。