ブログ

Claude Code 2.1.268:denyルールとMCPで何が修正されたか

Markdown

Claude Code 2.1.268~2.1.269では、4件の権限に関する問題と、/mcpでのシークレット漏えいが修正されました。影響を受けるユーザー、更新方法、ルールの確認方法を説明します。

記事の全文を読む

Claude Codeバージョン2.1.268は2026年9月10日にリリースされ、翌日に2.1.269がリリースされました。すぐに更新してください。2つのケースで、エージェントが.envやサービスのフォルダーにアクセスするのを防ぐために使っているdenyルールが、ひそかに機能していませんでした。さらに、/mcpコマンドによって、設定ファイル内のシークレットがターミナルに表示される可能性がありました。

以下の内容は、資料の基準日である2026年9月17日時点のAnthropic公式変更履歴とドキュメントに基づいています。その日時点での最新バージョンは2.1.274でした。各項目の記載に基づいて問題の仕組みを説明します。脆弱なバージョンでバイパスを再現したわけではありません。

Ailootの使い方に関する追加の説明は、ドキュメントをご覧ください。

Claude Code 2.1.268と2.1.269では何が修正されましたか?

重要なポイント

権限に関する4つの問題が修正されました。シンボリックリンク経由のパスではdenyルールとaskルールが機能せず、env -Cやevalを含む行ではReadまたはEditに対するdenyが失敗することがありました。「!」を含むルールは、設定ファイルの範囲を超えて適用されていました。teeコマンドはEditに対するdenyでブロックされずにファイルを書き込んでいました。さらに、/mcpとclaude mcp listは設定ファイル内のシークレットを表示し、プラグインのエラーはGit URLのトークンを表示していました。

権限ルールに関係する修正は4つあります。

  1. シンボリックリンクに対する拒否が機能していませんでした。 シンボリックリンクのディレクトリ(macOSの/etc、/tmp、/var、Linuxの/bin)に設定したdenyルールとaskルールは、パスを実際の場所で指定すると発動しませんでした。Bashコマンドも、シンボリックリンク経由のパスに設定されたdenyルールを無視していました。
  2. 読み取りと編集に対する拒否は、env -Cやevalと同時に使うと失敗していました。 同じコマンド行に権限チェックで解析できない構文が含まれていると、ReadまたはEditに対するdenyが発動しないことがありました。
  3. 「!」を含むルールが意図した範囲を超えて適用されていました。 !で始まるdenyルールまたはaskルールは、記述された設定ファイルの範囲を超えて適用されていました。現在はそのルールのソース内でのみ適用され、単独の否定!は無視されます。
  4. teeが拒否を回避して書き込んでいました。 Edit()のdenyルールと書き込みパスのチェックは、Bashのteeコマンドで作成されたファイルには適用されていませんでした。Bash(tee:*)権限は、作業ディレクトリ外への書き込みをカバーしなくなりました。

これらのバージョンでは、シークレットの露出に関する問題も2つ修正されました。WebFetchは、接続を開いたままにするサーバーからの応答を無期限に待たなくなりました。リクエストは300秒後に失敗するようになり、CLAUDE_CODE_WEBFETCH_DEADLINE_MS変数でタイムアウトを設定できます。また、長時間のアイドルセッションでCPU使用率が高い状態が続く問題も解消されました。

Claude Codeでは拒否ルールはどのように機能しますか?

重要なポイント

ルールはsettings.jsonのpermissionsブロックに記述します。denyはブロックし、askは確認を求め、allowは確認なしで操作を許可します。チェックはdeny、ask、allowの順に行われます。ルールの形式はToolまたはTool(detail)です。たとえばRead(./.env)です。

Claude Codeには3種類のルールリストがあります。deny(常に禁止)、ask(操作の前に確認を求める)、allow(確認なしで許可)です。エージェントが何かを実行しようとすると、ルールは厳密にこの順でチェックされます。一致するdenyは、同じ操作に対するallowを無効にします。許可ルールを使って拒否を例外扱いにはできません。

ルールは3か所に保存されます。ユーザールールは~/.claude/settings.json、プロジェクトルールはリポジトリ内の.claude/settings.json、ローカルルールは.claude/settings.local.jsonです。キーを含むファイルの読み取りを拒否する設定例を示します。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(rm *)"
    ]
  }
}

セッションで/permissionsを実行すると、すべての有効なルールと、それぞれのルールの出所であるファイルを確認できます。ルールが読み取りをブロックすると、拒否のメッセージにそのルール名が表示されます。後述の確認で役立ちます。

拒否ルールとルールの適用範囲にはどのような問題がありましたか?

問題はパスやコマンドのチェックだけでなく、異なる設定ファイルに記述されたルールの適用範囲にも影響していました。

1つ目のケース:シンボリックリンク。 macOSでは/etc、/tmp、/varは/private配下の実際のフォルダーを指すシンボリックリンクです。Linuxでは、/binが同様のシンボリックリンクであることが一般的です。パスのある表記に対してdenyルールを設定し、エージェントが別の表記(たとえばシンボリックリンクではなく実際の場所)でアクセスした場合、ルールは発動しませんでした。Bashコマンドも、シンボリックリンク経由のパスに設定された拒否を無視していました。2.1.268では両方の問題が修正され、パスのどちらの表記を使ってもルールが適用されるようになりました。

2つ目のケース:同じ行にあるenv -Cとeval。 権限チェックは、コマンドがどのファイルにアクセスするかを調べるためにコマンドを解析します。env -Cやevalなどの構文は解析できません。これらの構文が行に含まれていると、ReadまたはEditに対するdenyが適用されないことがあるのが問題でした。その結果、コマンドが保護されたファイルの読み取りや編集に対する拒否を回避できる可能性がありました。

3つ目のケース:「!」を含むルールが適用範囲を超えていました。 !で始まるルールは、それが記述された設定ファイル内でのみ適用されるはずです。2.1.269より前は、他の設定ソースにも適用されていました。現在は適用範囲が自身のファイル内に限定され、単独の!からなるルールは無視されます。

4つ目のケース:tee経由の書き込み。 Bashのteeコマンドはファイルに書き込めます。書き込みパスのチェックとEdit()のdenyルールは、そのファイルに適用されていませんでした。同時に、Bash(tee:*)権限は作業ディレクトリ外への書き込みもカバーしていました。2.1.269では、これらのチェックがtee経由の書き込みにも適用されるようになりました。ファイルに対する拒否が有効になり、Bash(tee:*)がカバーするのは作業ディレクトリ内だけになりました。

.env、いくつかのサービスフォルダー、危険なコマンドなどをブロックするために対象を限定した拒否ルールを使っている場合は、それらも確認してください。手順は以下のとおりです。

/mcpでキーが表示されることがあったのはなぜですか?

重要なポイント

MCP設定ファイルのキーは、多くの場合${VAR}変数を介して渡されます。/mcp、/plugin、claude mcp list、claude mcp getコマンドとMCPのログインエラーは、置換後の値、つまりキーそのものを表示していました。2.1.268では出力がマスキングされます。

MCPサーバーの設定ファイルでは、キーを環境変数に保存し、${VAR}を介して参照するのが一般的です。こうすると、シークレットそのものを含めずにファイルをリポジトリに保存できます。問題は、表示コマンド(/mcp、/plugin、claude mcp list、claude mcp get)とMCPのログインエラーメッセージが、値をすでに置換した状態の設定を表示していたことです。画面にはキーそのものが表示されていました。

別の修正では、プラグインとマーケットプレイスのエラーに、ソースGit URLに含まれるトークンやパスワードが表示される問題にも対処しています。

古いバージョンでの/mcpまたはclaude mcp listの出力が、ストリーム、スクリーンショット、同僚へのメッセージ、または自動送信を含め、マシンの外部に出るログに含まれていた場合は、MCP設定ファイルのキーが漏えいしたものとみなし、ローテーションしてください。出力がマシンの外部に出ていない場合は、更新すれば十分です。MCPサーバーとすぐに使える設定については、別のガイドをご覧ください:Claude CodeのMCPサーバー。

これらのバージョンでのその他の変更

WebFetchとアーティファクト。 以前は、denyまたはaskに詳細を指定せずに設定したWebFetchルールが、公開済みアーティファクトの読み取りと変更にも適用されていました。2.1.268以降、このルールはアーティファクトには適用されなくなりました。アーティファクトをブロックするには、別のArtifactルール、またはWebFetch(domain:claude.ai)のようなドメインルールが必要です。アーティファクトの読み取りを防ぐために一般的なWebFetch拒否に頼っていた場合は、設定を再確認してください。以前のルールでは、これらの操作をブロックできなくなりました。

WebFetchにタイムアウトが設定されました。 接続を開いたままにし、応答を完了しないサーバーへのリクエストは、300秒後に失敗するようになりました。以前は、そのようなリクエストが無期限にハングすることがありました。動作はCLAUDE_CODE_WEBFETCH_DEADLINE_MS変数で設定できます。0に設定すると、タイムアウトが無効になります。

アイドルセッション中にCPU使用率が高い状態が続く問題が解消されました。 長時間のアイドルセッションでは、Claude CodeのアイドルループによってCPU使用率が高い状態が続くことがありました。このバグは2.1.268で修正されました。セッションを1日中開いたままにしているユーザーにも影響する可能性がありました。

最新バージョンをインストールしてください。 2.1.269では新しいバグが発生しました。セッションを長時間実行した後、データを読み取るだけのBash Gitコマンドが権限を求めるようになりました。この問題は2.1.270で修正されました。したがって、最新バージョンに更新してください(2026年9月17日時点では2.1.274でした)。2.1.268や2.1.269で更新を止めないでください。

更新して拒否ルールが機能することを確認する方法

重要なポイント

claude --versionでバージョンを確認し、最新リリースに更新してください。次に、シークレットのない安全なファイルを使ってテストします。そのファイルにdenyルールを追加し、エージェントにファイルを読ませ、拒否のメッセージに自分のルールが示されることを確認します。

  1. 現在のバージョンを確認します。 ターミナルでclaude --versionを実行してください。上記の問題に対する修正は2.1.268と2.1.269でリリースされました。バージョン番号が2.1.268より小さい場合、まだこれらの修正は含まれていません。ただし、各問題の影響を受けるかどうかは、使用するパス、コマンド、ルールによって異なります。
  2. 更新します。 Claude Codeを最新バージョンに更新する方法のガイドに、手順とトラブルシューティングが記載されています。最新バージョンを選び、2.1.268で更新を止めないでください。
  3. 拒否ルールをテストします。 実際の.envでルールをテストしないでください。拒否が失敗すると、エージェントに実際のキーが見えてしまいます。テストファイルを作成します。たとえばsecret-test.txtに「これはテストです」のような任意のテキストを入れます。プロジェクトの.claude/settings.jsonにあるdenyリストに"Read(./secret-test.txt)"ルールを追加し、セッションを再起動して、「secret-test.txtファイルを読んで、中身を教えて」と依頼します。期待される動作は、ルール名を示す拒否です。エージェントがファイルを読んだ場合、このテストでは拒否が機能しませんでした。まず、上記のセクションで構文を確認し、/permissionsを開いて有効なルールと、それぞれの読み込み元ファイルを確認してください。テスト結果だけでは原因を特定できません。1つの拒否で確認できるのは、そのファイルに対するルールが機能することだけです。他のルールについては何もわからないため、同じ方法で1つずつ確認してください。
  4. 該当するパスを使っている場合は、シンボリックリンクのケースを確認します。 macOSの/tmp、/etc、/varまたはLinuxの/binに対する拒否ルールがある場合は、更新後にこれらのパスでテストを繰り返してください。
  5. 「!」を含むルールを確認します。 使用していた場合は、それぞれのルールが意図した適用先のファイルに記述されていることを確認してください。

拒否が機能しているのにClaude Codeが必要なファイルを参照できない場合は、別の説明をご覧ください:Claude Codeがプロジェクトファイルを参照できない理由。

今すぐ更新できない場合

更新を延期しなければならないこともあります。環境を変更できない、会社所有のマシンを使っている、または現在の作業を完了する必要がある、といった場合です。更新するまでの間、次の方法でリスクを減らせます。

  • パスの両方の表記、つまりシンボリックリンクと実際の場所に対してdenyルールを設定します(macOSでは実際のパスは/private配下です)。
  • 1行に複数のコマンドを組み合わせず、エージェントに実行させるコマンドではenv -Cとevalを避けます。
  • /mcp、/plugin、claude mcp list、claude mcp getの出力を誰にも見せず、MCP設定ファイルのキーが他人の手に渡った可能性がある場合はローテーションします。
  • teeはEditに対するdenyを回避して書き込むことを念頭に置き、Bashが許可されている場合、ファイルが保護されているとは考えないでください。

これらの対策は特定のバイパスが起きる可能性を下げますが、修正の代わりにはなりません。できるだけ早く更新し、前のセクションのテストを実行してください。

簡単なまとめ

バージョン2.1.268と2.1.269では、Claude Codeの権限に関する4つの問題、すなわちシンボリックリンク、env -Cとevalを含む行、自身のファイルを超えて適用される「!」を含むルール、tee経由の書き込みが修正されました。これとは別に、/mcpの出力でシークレットが露出する問題と、プラグインのエラーにトークンが表示される問題も修正されました。バージョン番号を確認して最新リリースに更新し、上記のセクションにあるテストファイルでテストしてください。ルール名を示す拒否があれば、このテストで拒否が機能したことを確認できます。設定にルールが存在するだけでは、機能することを確認できません。

出典

モデルを使った作業を続けるには、Ailootにアクセスしてください。

詳細を見る

Claude Code 2.1.268:denyルールとMCPで何が修正されたか:よくある質問

本物の秘密情報を見せずにdenyルールをテストするには?

無害なテキストを入れたファイルを作り、そのファイルへのReadを拒否します。セッションを再起動して読み取りを依頼し、設定したルールを示す拒否が返るか確認してください。失敗する可能性があるテストに、本物の.envを使ってはいけません。

1回拒否されれば、権限設定全体が安全だといえますか?

いいえ。確認できるのは、そのファイルとアクセス経路だけです。/permissionsで有効なルールを確認し、必要に応じてシンボリックリンク経由のパス表記など、頼りにしている別の経路や条件もテストしてください。

すべての記事