Claude Codeの「読み取り専用」設定が効いていなかった不具合｜v2.1.260の修正内容と確認すべき対策【2026年9月】

Claude Codeを企業や個人開発の現場で使う際、settings.jsonに「このフォルダは読み取り専用」「このディレクトリへの書き込みは禁止」といった権限ルール（deny/allowルール）を設定している方は少なくありません。ところが2026年9月3日にリリースされたClaude Code v2.1.260で、こうした権限ルールの一部が実際には機能していなかったという不具合が修正されました。原因は、ファイルパスに括弧()が含まれている場合に、そのルール自体が無効な設定として破棄されるか、Bashサンドボックスから無視されてしまうというものです。結果として「読み取り専用のはず」だったフォルダが、実際には書き込み可能な状態になっていました。

この記事では、公式チェンジログをもとに何が起きていたのかを整理したうえで、なぜこの種の不具合が繰り返し起こるのか、そして企業・個人が今すぐ確認すべき対策を具体的なチェックリストとして解説します。結論を先に言うと、v2.1.260以降へのアップデートに加えて、自分のsettings.json・.claude/settings.local.jsonに括弧を含むパスの権限ルールがないかを一度は必ず確認することをおすすめします。

Contents

何が起きていたのか：v2.1.260で修正された権限ルールの不具合
- 括弧を含むパスの権限ルールが無効化されていた
- 影響範囲はEdit・Write・Readとサンドボックスの両方
なぜ危険なのか：単発のバグではなく繰り返されてきた問題
- Before / After で見る影響
- Claude Codeの権限モデルはこれまでも指摘が続いてきた
今すぐ確認すべきこと：企業・個人向けチェックリスト
あわせて確認したいv2.1.260のその他の重要な修正
関連記事：Claude Codeの安全な運用を深掘りする
疑問点
まとめ
参考・引用元

何が起きていたのか：v2.1.260で修正された権限ルールの不具合

括弧を含むパスの権限ルールが無効化されていた

Anthropicが公開している公式チェンジログによると、v2.1.260では次の不具合が修正されました。

Fixed Edit/Write/Read permission rules whose path contains parentheses being dropped as invalid or ignored by the Bash sandbox, which left “read-only” folders writable.
（括弧を含むパスを指定したEdit/Write/Readの権限ルールが、無効な設定として破棄されるか、Bashサンドボックスから無視されており、「読み取り専用」のはずのフォルダが書き込み可能な状態になっていた）

Claude Codeの権限ルールは、Edit(path)やRead(path)のように「ツール名＋括弧内のパターン」という形式で記述します。この仕組み上、ルールの文字列は内部的に正規表現へとコンパイルされますが、パス自体に括弧が含まれていると、それが正規表現の「グルーピング」として解釈されてしまい、ルール全体が不正な設定と判定される、またはBashサンドボックス側の検査で無視されるという状態が起きていました。

たとえば、Windows環境でよくあるC:\projects\(archive)\**のようなパスや、プロジェクト名に括弧を使っているディレクトリをdenyルールで保護しようとしていた場合、そのルールが実質的に「存在しないもの」として扱われ、本来ブロックされるはずの編集・書き込み・読み取りが素通りしてしまう可能性がありました。

影響範囲はEdit・Write・Readとサンドボックスの両方

今回の不具合が厄介なのは、影響範囲が権限ルールのパーサーだけでなく、Bashサンドボックス側の判定ロジックにも及んでいた点です。つまり、Claude Codeの標準ツール（ファイル編集・書き込み・読み取り）だけでなく、Bashコマンド実行時のサンドボックス保護においても、括弧を含むパスの保護が期待通りに働いていなかったことになります。企業で「特定のディレクトリだけは絶対に触らせない」という運用をしている場合、この不具合は設定ミスに気づかないまま長期間放置されるリスクがある点で影響が大きいといえます。

なお、同じv2.1.260では関連するもう一つの修正も入っています。

Changed permission rules with text after the closing parenthesis (e.g. Bash(ls) x), which never matched anything, to be reported as invalid settings instead of being silently ignored.

閉じ括弧の後に余計な文字列が付いたルール（Bash(ls) xなど）は、これまで「何にもマッチしない」まま黙って無視されていましたが、v2.1.260からは明示的に「無効な設定」としてエラー表示されるようになりました。サイレントに無視されるより、エラーとして気づける方が安全という設計思想の表れです。

なぜ危険なのか：単発のバグではなく繰り返されてきた問題

Before / After で見る影響

項目	v2.1.259以前	v2.1.260以降
括弧を含むパスのdeny/allowルール	無効判定または無視され、実質機能しない	正しくパスとして解釈され、ルールが機能する
閉じ括弧の後に文字列があるルール	サイレントに無視される（気づけない）	無効な設定としてエラー表示される
「読み取り専用」のつもりのフォルダ	実際には書き込み可能なケースがあった	意図通り保護される

Claude Codeの権限モデルはこれまでも指摘が続いてきた

今回の不具合は単発の出来事ではありません。Claude CodeのGitHub Issueには、以前から権限まわりの信頼性を疑問視する報告が複数上がっています。たとえば「Permission Deny Configuration Not Enforced for Read/Write Tools」（Issue #6631）や「Critical Security Bug: deny permissions in settings.json are not enforced」（Issue #6699）といった報告があり、また過去にはシンボリックリンク経由でdenyルールを回避できてしまう脆弱性（CVE-2026-25724）も報告・修正されています。海外の技術ブログでも「Claude Code’s broken permission model（壊れているClaude Codeの権限モデル）」のようなタイトルで、deny設定が期待通りに動かないケースが繰り返し取り上げられてきました。

Claude Codeの権限ルールは「一度設定したら安心」という性質のものではなく、バージョンアップのたびに実際の挙動を確認する運用が必要なツールだと考えたほうが安全です。特に、社内の機密ディレクトリや本番環境の設定ファイルへのアクセスを制限する目的でClaude Codeの権限機能に依存している場合は注意が必要です。

今すぐ確認すべきこと：企業・個人向けチェックリスト

1. バージョンを確認し、v2.1.260以降にアップデートする

まずは手元のClaude Codeのバージョンを確認しましょう。ターミナルでclaude --versionを実行するか、Claude Code内で/statusを実行すると、現在のバージョンと設定の読み込み状況が確認できます。v2.1.260より古い場合は、通常のアップデート手順（npm update -g @anthropic-ai/claude-codeなど、導入方法に応じた手順）でアップデートしてください。

2. settings.jsonに括弧を含むパスのルールがないか洗い出す

~/.claude/settings.json（ユーザー設定）、.claude/settings.json（プロジェクト設定）、.claude/settings.local.json（個人のローカル設定）の3つのファイルを確認し、permissions.deny・permissions.allow・permissions.askに登録されているパターンの中に、次のようなパスが含まれていないか確認してください。

ディレクトリ名やファイル名に半角括弧()が含まれるパス（例：Edit(./projects/(archive)/**)）
Windows環境でProgram Files (x86)のようにOS標準で括弧が入るパスを指定しているルール
閉じ括弧のあとに余計な文字列が続いているルール（例：Bash(ls) xのような書き損じ）

3. 括弧を避けた代替の書き方を検討する

該当するルールが見つかった場合は、可能であればディレクトリ名から括弧を取り除く、あるいは括弧をエスケープする代わりに、括弧を含まない別のパス表現（シンボリックリンクを別名で用意する、上位ディレクトリごと保護するなど）に置き換えることを検討してください。なお、公式チェンジログでは、\(のようなエスケープ表記がパス区切りではなく「エスケープされた括弧」として解釈されてしまう曖昧な設定に対して、より分かりやすいエラーメッセージを出すようにする改善も同時に行われたと案内されています。

4. 実際にルールが機能しているかテストする

設定を直しただけで安心せず、実際に保護対象のファイルへ書き込み・編集を試みるプロンプトをClaude Codeに与え、意図通りブロック（またはask確認）されるかを手動でテストすることをおすすめします。/doctorコマンドでの設定診断とあわせて、「本当にルールが効いているか」を目視で確認する習慣が、今回のような不具合の再発に備える最も確実な方法です。

あわせて確認したいv2.1.260のその他の重要な修正

権限・サンドボックス関連では、以下の修正も同じリリースに含まれています。企業でセキュリティ設定を細かく管理している場合は、あわせて確認しておくとよいでしょう。

不正な正規表現パターン（閉じられていない[など）を含む権限ルールが1つあるだけで、すべてのファイル編集がInvalid regular expressionエラーで失敗していた不具合を修正。該当ルールは以後、パターンではなく文字列そのものとして扱われるように変更されています。
zshのREPORTTIME・REPORTMEMORY・DIRSTACKSIZEへの代入文の中にコマンド置換を隠す手口で、Bashの権限チェックが自動承認してしまっていた不具合を修正。これらは今後、承認プロンプトが表示されるようになります。
v2.1.259で導入された「Read()のdenyルールをBashの引数にも適用する」変更は、npm run buildのような通常コマンドまで誤ってブロックしてしまう副作用があったため、v2.1.260で一旦ロールバックされています。v2.1.259で「急にコマンドが拒否されるようになった」場合は、v2.1.260へのアップデートで解消します。

疑問点

Q. すぐにアップデートすべきか。
A. 特にsettings.jsonでdeny/allowルールを使って機密ディレクトリを保護している場合は、優先してv2.1.260以降へアップデートし、設定内容を再確認することをおすすめします。

Q. 括弧を含むパス名は今後も使えなくなるか。
A. 修正後は括弧を含むパスも正しく権限ルールとして解釈されるようになりました。ただし曖昧なエスケープ表記についてはエラーメッセージで注意喚起されるようになったため、指摘された場合は表記を見直してください。

Q. 個人利用でもこの不具合は関係あるか。
A. 個人開発でも、機密情報を含むディレクトリ（.envファイルのあるフォルダなど）をdenyルールで保護している場合は影響を受ける可能性があります。バージョン確認とルールの見直しをおすすめします。

まとめ

Claude Code v2.1.260では、括弧を含むパスの権限ルールがEdit・Write・Read、そしてBashサンドボックスの両方で無効化・無視されてしまい、「読み取り専用」のつもりのフォルダが実際には書き込み可能になっていた不具合が修正されました。この種の権限まわりの不具合はGitHub Issueやセキュリティ研究者の報告でも繰り返し指摘されてきたテーマであり、今回の修正を機に、自分のsettings.json・.claude/settings.local.jsonに登録している権限ルールを一度棚卸しすることをおすすめします。バージョンのアップデート、括弧を含むパスの洗い出し、そして実際の動作テストという3ステップを踏むことで、意図しない書き込みアクセスのリスクを減らすことができます。