Claude Code Permissions

変更前

ユーザーに質問を投げるためのツールが「許可済み」リストに入っていると、プロンプトを出さずに空の回答で処理が進んでしまい、Claude が必要な情報を得られないまま暴走することがありました。

変更後

対話が必要なツールについては、リストに含まれていても必ずユーザーの入力を待つように修正されました。

ユーザーへの恩恵

Claude との認識の相違が減り、重要な確認事項が見逃されることなく、対話に基づいた正確なタスク遂行が期待できるようになります。

変更前

ディレクトリ移動を伴うコマンドを実行する際、セキュリティ確認のメッセージが「読み取り許可」としか表示されず、実際にはファイル削除などの破壊的変更が行われようとしていることに気づきにくい問題がありました。

変更後

承認画面において、チェインされた（&& で繋がれた）実際の変更コマンドが具体的に表示されるようになり、ユーザーがリスクを正確に判断できるようになりました。

ユーザーへの恩恵

意図しないファイル削除や移動を未然に防ぐことができ、AI による自動操作の安全性が向上します。

変更前

ディレクトリを跨いだコマンド実行の際、プロンプトの記述が不十分で、Claude がワークスペース外で何を実行しようとしているのかの全容が把握しづらい状況でした。

変更後

移動先のディレクトリ情報だけでなく、そこで実行される具体的なコマンドまで明示されるようになったため、ユーザーの確認作業がより確実になります。

ユーザーへの恩恵

AI の挙動をより透明に把握でき、不用意な承認によるセキュリティリスクを軽減できます。

変更前

自動承認が行われるインタラクティブなパーミッション処理中に、リスナーが解放されずメモリリークが発生していました。

変更後

インタラクティブなパーミッションハンドラーでのリスナーリークが修正され、リソースが適切に管理されるようになりました。

ユーザーへの恩恵

パーミッション関連の操作における安定性が向上し、メモリリークによるパフォーマンス低下を防ぎます。

変更前

以前は、安全チェックによって権限の承認が必要になった場合でも、SDKの利用者はClaude Codeが何を許可してほしいのか、どのような選択肢があるのかをプログラム的に取得するのが困難でした。これにより、カスタムUIや自動化フローでユーザーに権限オプションを提示することができませんでした。

変更後

今回の変更により、安全チェックが「ask」応答をトリガーすると、関連する権限の提案(例: どのファイルへの書き込みを許可するか、どのコマンド実行を許可するかなど)がSDKのモデル情報に含まれるようになりました。これにより、SDK利用者はこれらの提案をプログラム的に取得し、ユーザーフレンドリーな形式で表示することが可能になります。

ユーザーへの恩恵

Claude Codeを組み込んだSDKやカスタムアプリケーションのユーザーインターフェースで、より詳細で具体的な権限承認オプションを提供できるようになります。これにより、ユーザーはClaude Codeの動作をより正確に理解し、安心して必要な権限を付与できるようになり、透明性と信頼性が向上します。

変更前

以前は、Claude Codeがファイルパスへのアクセスや作業ディレクトリの変更を試みた際に、セキュリティ上の制限に遭遇すると、具体的な理由が不明瞭なまま「許可しますか？」といった抽象的な権限プロンプトが表示されていました。これにより、ユーザーは何を許可するのか、なぜ制限されているのかが分からず、判断が困難でした。

変更後

今回の改善により、パスの安全性や作業ディレクトリのブロックに関する権限プロンプトに、具体的な制限理由(例: 「このパスへの書き込みはセキュリティポリシーによって許可されていません」)が表示されるようになりました。これにより、ユーザーはより明確なコンテキストに基づいて権限を承認または拒否できます。

ユーザーへの恩恵

開発者は、Claude Codeの権限要求に対して、より情報に基づいた適切な判断を下せるようになります。セキュリティ上の理由やポリシーによる制限が明確に示されるため、安心して作業を進め、意図しないリスクを回避できるようになります。

変更前

bashパーミッション分類器において、入力ルールに対応していない、誤ったマッチ記述が生成される可能性があり、これが意図しないパーミッションの付与につながる可能性がありました。

変更後

bashパーミッション分類器の精度が向上しました。返されるマッチ記述が実際の入力ルールと一致するかどうかを検証するようになり、誤ったパーミッション付与を防ぐようになりました。

ユーザーへの恩恵

bashコマンドのパーミッション管理がより正確になり、意図しないコマンド実行を防ぐことで、セキュリティと信頼性が向上しました。

変更前

複数行のBashコマンドに対して「常に許可」を設定すると、無効なパーミッションパターンが生成され、設定ファイルが破損してしまう問題がありました。

変更後

複数行Bashコマンドでの「常に許可」設定が、無効なパーミッションパターンを作成せず、設定を破損させないように修正されました。

ユーザーへの恩恵

複数行Bashコマンドのパーミッション設定が安全になり、設定ファイルの破損を防ぎつつ、意図したコマンド実行を許可できるようになりました。

変更前

これまでは、Claude CodeがAWS認証情報の更新を試みる際に、何らかの問題が発生するとプロセスが無期限に停止してしまうことがありました。これにより、認証が完了せず、Claude Codeの操作が中断される可能性がありました。

変更後

今回の修正により、AWS認証情報のリフレッシュ処理に3分のタイムアウトが設定されました。これにより、認証プロセスがハングした場合でも、最大3分で処理が終了し、Claude Codeが応答しなくなることを防ぎます。

ユーザーへの恩恵

AWS Bedrockを利用しているユーザーは、認証情報のリフレッシュ時にプロセスが停止する心配がなくなり、より安定してClaude Codeを使用できるようになります。問題が発生しても、タイムアウトによって操作がブロックされ続けることがなくなります。

変更前

以前は、サンドボックス機能を使って自動承認されるように設定されたBashコマンドの一部が、意図せず権限の要求なしに実行される可能性がありました。これは、特定のコマンドがサンドボックスから除外されるように設定されている場合に発生し、セキュリティ上の脆弱性となる恐れがありました。

変更後

今回の修正により、autoAllowBashIfSandboxed 設定が有効な環境でも、サンドボックスから除外されたコマンドは適切にBashの権限要求ルールに従うようになりました。これにより、除外設定されたコマンドであっても、ユーザーの許可なく勝手に実行されることはありません。

ユーザーへの恩恵

この修正により、サンドボックスのセキュリティモデルが強化され、より安心してClaude Codeを利用できるようになります。意図しないコマンドの実行を防ぎ、システムへのアクセスを厳密に制御できるため、セキュリティリスクが低減されます。

変更前

テキスト入力中にパーミッションダイアログが表示されると、ダイアログがアクティブな入力フィールドのフォーカスを奪い、ユーザーの入力を妨げていました。

変更後

パーミッションダイアログが表示されても、アクティブな入力フィールドのフォーカスが奪われなくなりました。

ユーザーへの恩恵

入力中の作業が中断されることなく、スムーズにパーミッションの確認や承認を行えるようになりました。

変更前

以前は、特定のBashコマンドを許可する際に、Bash(*)のようなワイルドカードを含むルールが、すべてのBashコマンドを指すBashルールと完全に同等に扱われないことがありました。これにより、パーミッション設定の意図が正しく解釈されない可能性がありました。

変更後

Bash(*)というパーミッションルールは、すべてのBashコマンドを許可するBashルールと全く同じ意味として解釈されるようになりました。これにより、ワイルドカードを使用した場合でも、より予測可能なパーミッションの挙動が保証されます。

ユーザーへの恩恵

開発者は、パーミッションルールを記述する際に、BashとBash(*)のどちらを使用しても同じ効果が得られるようになり、設定の一貫性が向上します。これにより、セキュリティ設定の記述が簡素化され、誤解のリスクが低減します。

変更前

到達不能なパーミッションルールがあっても、ユーザーに通知されず、問題が潜在化していました。

変更後

到達不能なパーミッションルールが自動的に検出され、/doctor コマンド実行時やルール保存時に警告が表示されるようになりました。警告には、問題のあるルールのソースと、それを解決するための具体的なガイダンスが含まれます。

ユーザーへの恩恵

開発者は、設定ミスや意図しないパーミッション設定を早期に発見し、修正できるようになり、セキュリティとツールの信頼性が向上します。

変更前

パーミッション設定でのパターンマッチングが制限されており、前方一致以外の柔軟なコマンド指定が困難でした。

変更後

コマンドの途中や末尾にワイルドカードを自由に配置でき、よりきめ細かな、あるいは汎用的な許可設定が可能になりました。

ユーザーへの恩恵

セキュリティを維持しつつ、承認プロンプトの頻度を減らして作業を効率化できます。

変更前

特定のサブエージェント(例：Explore や Plan)の使用を制限したい場合、ツール全体の実行を止めるしかなく、個別に禁止することができませんでした。

変更後

特定の性質を持つエージェント(エージェントがエージェントを呼ぶ挙動など)を名前指定で明示的に禁止できるようになりました。

ユーザーへの恩恵

企業ポリシーに合わせた制約の適用や、コスト管理のために特定の高負荷なサブタスクを制限するといった制御が可能です。

変更前

承認プロンプトが表示される際、操作説明が画面中央を占有したり、選択肢が単なる「Yes/No」で具体的に何を許可しようとしているか直感的に分かりにくい部分がありました。

変更後

「はい、このプロジェクトで npm を許可します」といった具体的なアクションを示すラベルが表示され、より安全かつ直感的に判断できるようになりました。

ユーザーへの恩恵

誤操作のリスクを減らしつつ、何に同意しようとしているかを一瞬で把握できるため、開発の手を止める時間を最小限にできます。

変更前

フックでツール入力を変更した場合、即座に実行を許可(allow)するか拒否(deny)するかの二択になり、変更後の内容をユーザーに確認させることができませんでした。

変更後

安全のために特定の引数を修正しつつ、「この内容で実行して良いですか？」というプロンプトをユーザーに表示する高度な制御が可能になりました。

ユーザーへの恩恵

不適切なコマンド引数を自動補正しながら最終判断は人間に委ねるという、安全性と柔軟性を両立した高度なガードレールを構築できます。

変更前

メインセッションで設定したクロスリージョン推論のオプションが、新しく起動したサブエージェントに正しく引き継がれず、特定のリージョンに制限された権限環境でエラーになっていました。

変更後

すべてのサブエージェントが親セッションの推論設定を正しく共有するようになり、分散リージョン環境でも安定して動作します。

ユーザーへの恩恵

グローバルな AWS インフラを利用しているエンタープライズユーザーも、サブエージェント機能を確実に利用できます。

変更前

オプションが含まれる複雑なコマンドの際、本来のコマンド(この場合は git log)が正しく認識されず、パーミッションの許可ルールに合致しないことがありました。

変更後

コマンドライン引数をより賢く解析し、正しいサブコマンドに対して実行可否を判定できるようになりました。

ユーザーへの恩恵

カレントディレクトリ以外を対象とするコマンドなど、実戦的なオプション指定時でもパーミッション設定が期待通りに機能します。