Claude Code Permissions

変更前

ツール呼び出し中に処理が中断されると、誤った中断通知が表示されたり、本来完了していないツール使用の記録が対話履歴に残ってしまっていました。

変更後

中断が発生しても不要な警告メッセージが表示されなくなり、対話履歴には整合性の取れた状態のみが記録されるようになりました。

ユーザーへの恩恵

ツールの中断後に履歴の整合性を手動で修正したり、誤ったエラーメッセージを無視したりする必要がなくなります。

変更前

信頼されていない場所からでもフックスクリプトが実行され、セキュリティ上のリスクがありました。

変更後

ワークスペースの信頼確認を経てからフックが許可されるようになり、安全性が高まりました。

ユーザーへの恩恵

外部からダウンロードしたプロジェクト等で未知のコードが勝手に実行されるのを防げます。

変更前

安全と判断できる操作に対しても、すべてのBashコマンドで確認ダイアログが表示されていました。

変更後

自動分類器が読み取り専用操作を検出し、プロンプトなしで安全に実行します。

ユーザーへの恩恵

タスクの調査フェーズで不要な確認手順を省いて効率的に進められます。

変更前

&& リストの中にリダイレクトがあると、実行許可の判定が正しく機能せずプロンプトが表示される不具合がありました。

変更後

複合コマンド内の個々のリダイレクト条件を正確に解析し、許可設定に応じたプロンプト表示が可能になりました。

ユーザーへの恩恵

正当なコマンドに対しても、毎回パーミッションの確認画面が出るストレスが解消されます。

変更前

ユーザーが明示的に中断した操作も「拒否」としてカウントされ、統計データが正確ではありませんでした。

変更後

失敗した権限要求と、ユーザーによる能動的な中断操作を区別して報告するように改善されました。

ユーザーへの恩恵

自分の作業状況に対する統計情報が、ユーザーの意図を正確に反映したものになります。

変更前

PowerShell でコマンドを実行する際、引数の解析に制限があり複雑な git コマンドが失敗することがありました。

変更後

PowerShell 実行環境における引数の検証ロジックを強化し、より多様なコマンドを安全に扱えるようにしました。

ユーザーへの恩恵

Windows 環境でも、PowerShell ツール経由で git コマンドを制限なく活用できるようになります。

変更前

単一階層の指定（Edit(src/**)など）が、指定した親ディレクトリ内だけでなく、ツリー内のどこにあるネストされたディレクトリに対しても自動的に許可されていました。

変更後

指定した階層に合致するディレクトリ内のみが許可対象となるよう制限が正しく適用されるようになりました。

ユーザーへの恩恵

意図しないディレクトリへの書き込みが自動承認されるリスクを避けられます。

変更前

helpやmanコマンドが一部の文脈で自動承認されており、悪意のあるオプション実行などが許容される可能性がありました。

変更後

コマンド置換やバックスラッシュを含むパスなど、安全でないオプションや引数を持つhelpやmanコマンドが自動承認されなくなりました。

ユーザーへの恩恵

不審なコマンド実行を意図せず許可してしまうリスクが減ります。

変更前

Podmanのリモートモードや特定のデーモン接続フラグを含むdockerコマンドが、プロンプトなしで実行可能な状態でした。

変更後

デーモン接続先を操作するフラグが含まれるdockerコマンドは、必ず権限プロンプトの確認を経るようになりました。

ユーザーへの恩恵

外部のDockerデーモンや予期しない環境への接続を意図せず実行する事態を防げます。

変更前

エラーメッセージが抽象的で、どこで信頼設定が保存されるのかが不明確でした。

変更後

ホームディレクトリは信頼設定の保存対象外であることを伝え、プロジェクト内での実行を推奨するメッセージに変更しました。

ユーザーへの恩恵

なぜ信頼設定が求められているのか、どこで作業すべきかが直感的に分かります。

変更前

dir/**という指定が、意図せず任意の階層を対象としてしまうケースがあり、混乱を招いていました。

変更後

単一階層指定の場合は直下のディレクトリのみを対象とする挙動に統一しました。

ユーザーへの恩恵

フックの適用範囲が予測しやすくなり、誤適用を防げます。

変更前

fileコマンドは一括で読み取り専用として自動許可されていました。

変更後

magic-fileなどの高度な指定を含むfileコマンドは、実行時に権限の確認が必要になりました。

ユーザーへの恩恵

fileコマンドを介した不正なファイルパス指定や予期しない処理を未然に防げます。

変更前

ツール入力に含まれる特殊な制御文字や類似文字がそのまま中継されていたため、承認メッセージの見た目を意図的に操作される可能性がありました。承認者がツールの実行内容を誤認するリスクがありました。

変更後

これらの特殊文字や不可視文字、類似文字をサニタイズしてから中継するように改善されました。これにより、ツールの入力値によって承認画面のテキストが書き換えられるのを防ぎます。

ユーザーへの恩恵

チャット経由でリモート承認を行う際に、ツールの実行内容を常に正しく把握できるようになる。

変更前

オートモード(auto mode)では、フックがユーザーへの確認(ask)を求めた場合でも、分類器が安全だと判断するとプロンプトを出さずにサイレントで承認してしまうことがありました。フックによる明示的な制限が無視される場面がありました。

変更後

フックが「ask」を返した場合、オートモードであっても必ずユーザーにプロンプトを表示するように変更されました。分類器は拒否(deny)することはできますが、フックの要求を無視して勝手に承認することはできなくなります。

ユーザーへの恩恵

セキュリティや検証のために設定したフックによる確認要求が、オートモードでも確実に守られるようになる。

変更前

手動でディレクトリを消したりgit worktree pruneが行われたりして、gitから見たワークツリーの情報が壊れると、エージェントビュー(claude agents)からジョブを削除しようとしても無言で失敗し、行が残り続けていました。

変更後

gitが認識できない状態でもジョブの削除が成功するようになりました。削除できなかった場合も、単に再表示されるのではなく、なぜ削除が拒否されたかの理由(未プッシュのコミットがある等)が表示されます。

ユーザーへの恩恵

不要になったバックグラウンドタスクの行がリストに居座り続けることがなくなり、エージェントビューを常にクリーンに保てる。

変更前

「はい、今後表示しない」を選択した際の承認は、コマンドを実行したディレクトリに保存されていました。そのため、サブディレクトリや別のワークツリーで同じコマンドを使うと、再度許可を求められていました。

変更後

リポジトリのルートにある.claude/settings.local.jsonにルールが保存されるようになりました。一度許可すれば、リポジトリ内のどこで作業していても、また新しいワークツリーを作っても承認が引き継がれます。

ユーザーへの恩恵

同じリポジトリ内であれば、作業場所を変えても同じコマンドに対して何度も許可を求められる煩わしさがなくなる。

変更前

ブラウザ拡張機能を通じたローカルファイルのアップロードにおいて、パスの整合性チェックが不十分でセキュリティ上の懸念があった

変更後

セッションの読み取り権限ルールに基づいた厳格なパス検証が実行され、許可されたファイルのみがブラウザに送信されるようになる

ユーザーへの恩恵

ブラウザ操作の自動化中に、意図しない機密ファイルが外部のWebサイトにアップロードされるのを防げる

変更前

パーミッション設定で Write(path) や Glob(path) などの古い形式が使用されていても、より適切な Edit(path) や Read(path) への移行を促す仕組みがなかった。

変更後

起動時にこれらの古いルールを検出すると、推奨される新しいツール名への置き換えを促す警告が表示されるようになる。

ユーザーへの恩恵

最新のセキュリティモデルに合わせた正しいパーミッション設定への修正が容易になります。

変更前

isolation: 'worktree' を設定したサブエージェントが、隔離された環境内ではなく、誤ってメインのチェックアウトディレクトリに対して git 操作を行ってしまうリスクがあった。

変更後

サブエージェントが実行する git コマンドが、必ず自身に割り当てられた隔離ワークツリー内で動作するように厳格化された。

ユーザーへの恩恵

並列作業中のサブエージェントがメイン作業中のファイルを誤って書き換えてしまう心配がなくなります。

変更前

GitHub アプリ経由などでリレーされたコメント内に ultracode という文字列が含まれていると、ユーザーが意図していなくても高コストなワークフローが自動的に開始されてしまうことがあった。

変更後

ultracode によるワークフローの自動オプトインは、ターミナルからの直接入力などの人間による明示的な操作に限定されるようになる。

ユーザーへの恩恵

自動化されたコメントなどによって意図せずトークンを大量消費してしまう事態を防げます。

変更前

大量の検索結果を分割して表示（ページネーション）している際、最後のページを読み飛ばそうとすると、実際には結果が存在するのに「一致するファイルが見つかりません」という紛らわしいメッセージが表示されていた。

変更後

結果の終端に達したことが正確に通知され、検索自体の失敗と混同されないようになった。

ユーザーへの恩恵

検索結果が本当に存在しないのか、単に表示が終わっただけなのかを正確に判断できるようになります。

変更前

セッション開始後に作成された .claude フォルダ内のシンボリックリンクが、サンドボックスの保護対象として認識されず、誤って書き換えられてしまうリスクがあった。

変更後

シンボリックリンクの変更を動的に検知し、サンドボックスの書き込み制限をリアルタイムに更新するようになった。

ユーザーへの恩恵

設定ファイルや管理データに対する意図せぬ上書きをより確実に防ぐことができます。

変更前

オートモードでの権限判定（クラスシファイア）に使用されるモデルが外部セッションにおいて固定されておらず、セッションごとに検証が必要でした。また、特定のプロバイダーや環境では判定の安定性にばらつきがありました。

変更後

外部セッションの権限判定モデルとしてデフォルトで Sonnet 5 が使用されるようになり、セッションの最初の要求で検証された後はそのセッション中固定されます。これにより、安定した権限判定が維持されるようになります。

ユーザーへの恩恵

オートモード使用時に、どのモデルが権限判定を行っているかを気にしたり、判定の不安定さに煩わされたりすることがなくなります。

変更前

スクリーンリーダーモードを使用中、Shift+Tab キーでパーミッションモード（Manual, Plan, Autoなど）を切り替えても、現在のモードが何に変わったのかが音声で通知されませんでした。ユーザーは現在の動作モードを確認するために別の操作を行う必要がありました。

変更後

モードが切り替わるたびに、スクリーンリーダーが新しいモード名を即座に読み上げるようになります。これにより、視覚的なフィードバックがなくてもキー操作だけで確実にモード変更を把握できます。

ユーザーへの恩恵

パーミッションモードを切り替えるたびに、現在の設定が正しく反映されたかを手動で確認しなくてよくなります。

変更前

フルスクリーンレンダリングモードでは、基本的なマウスクリックはサポートされていたが、一部の複雑な複数選択メニューや自由入力欄ではキーボード操作が必要だった。

変更後

権限プロンプトなどのダイアログに表示される選択肢や自由記述欄を直接マウスでクリックして操作できる。これにより、ターミナル上での GUI 的な操作体験が一貫したものになる。

ユーザーへの恩恵

キーボード入力を待たずに、直感的なクリック操作だけで複雑なメニュー選択を済ませられるようになります。

変更前

Claude がファイルを読み込んだ後、その変更を適用するまでの間にディスク上でファイルが更新されると、たとえ編集箇所の内容が変わっていなくても安全策として編集が拒否されていた。

変更後

編集対象の文字列がファイル内で依然として一意に見つかる場合に限り、外部での変更を許容して編集を継続する。これにより、小さな外部更新による編集の競合エラーが減少した。

ユーザーへの恩恵

自分でファイルを微調整しながら Claude に指示を出しても、読み込みの不整合エラーでやり直しになることが減ります。

変更前

空ファイルを読み込むとオフセットエラーになったり、正規表現のミスが単なる「見つかりません」と表示されるなど、Claude がエラーの原因を正しく理解できない場合があった。

変更後

各ツールがより正確なステータスとエラーを返すようになった。特に Glob はヌルバイト等の不正な文字が含まれていても適切にエラーを報告し、クラッシュを回避する。

ユーザーへの恩恵

Claude がツールのエラーを正しく認識できるようになり、自己修復や原因の報告がより正確になります。

変更前

設定ファイルやマネージド設定で数千件規模の Bash 拒否リストなどを運用していると、Claude が何かアクションを起こすたびにルールの全件検索が走り、レスポンスが目に見えて遅くなっていた。

変更後

ルールの評価ロジックが高速化（プリコンパイル）された。どれほど複雑なセキュリティポリシーを適用していても、AI の回答生成が終わった直後にサッとツールが実行される。

ユーザーへの恩恵

セキュリティ設定を厳格にしている環境でも、AI のレスポンスを待たされるストレスがなくなります。

変更前

「rm -rf ~」などの致命的なコマンドも、バッククォートや変数を介した形式だとバイパスモードや自動モードでプロンプトなしに実行されるリスクがあった。

変更後

複雑な記述形式であってもホームディレクトリ等の削除を検知し、安全装置として必ずユーザーに確認を求めるようになる。

ユーザーへの恩恵

AIが誤って重要なシステムファイルを削除してしまう事故を、強力な権限設定下でも防げるようになる。

変更前

Amazon BedrockやGoogle Cloud Vertex AIなどの外部プロバイダーを利用する場合、オートモードを有効にするにはCLAUDE_CODE_ENABLE_AUTO_MODE=1という環境変数を明示的に設定する必要がありました。このオプトインがない限り、Shift+Tabでのモード切り替え候補にオートモードが表示されませんでした。

変更後

環境変数の設定なしで、デフォルトでオートモードが利用可能になりました。これにより、セットアップの手間が省け、すぐに自律的な実行モードを開始できます。無効にしたい場合は、設定ファイルでdisableAutoModeを指定することで制御可能です。

ユーザーへの恩恵

追加の設定なしで強力なオートモードを使い始められるようになり、プロバイダーを問わず一貫した利便性が得られます。

変更前

-pフラグを使用した際やSDK経由の実行ではセキュリティダイアログがスキップされるため、管理設定で配信された強力な設定（シェルコマンド実行など）がユーザーの明示的な確認なしに「同意済み」としてキャッシュに記録されてしまうリスクがありました。

変更後

非インタラクティブ実行時であっても、適切な確認ステップを踏まずにセキュリティ上の懸念がある設定が永続的に承諾されることがなくなりました。

ユーザーへの恩恵

組織のポリシー管理機能を利用する際、意図しない設定変更が勝手に行われることを防ぎ、セキュリティの透明性が向上します。

変更前

プロジェクトローカルな.claude/settings.local.jsonにオートモードの信頼設定を記述できましたが、これはリポジトリ間で設定の管理が分散する原因になっていました。

変更後

オートモードに関する個人設定は、ホームディレクトリの共通設定ファイル（~/.claude/settings.json）に集約されるようになりました。

ユーザーへの恩恵

リポジトリごとにオートモードの設定を書き直す必要がなくなり、自分の信頼設定を一箇所で一元管理できるようになります。

変更前

/cd コマンドを使用する際、/add-dir のようなディレクトリパスのサジェスト機能がありませんでした。

変更後

/cd でも /add-dir と同じ挙動でパスの候補が表示されるようになり、移動先を素早く選択できます。

ユーザーへの恩恵

長いパスを正確に手入力する手間が省け、プロジェクト間のディレクトリ移動がよりスムーズになります。

変更前

プッシュ先が origin 以外の場合、コマンド実行中にプッシュの許可を求めるプロンプトが表示されることがありました。

変更後

Git 設定で定義されたデフォルトのプッシュ先リモートが信頼済みとして扱われ、追加の承認なしでプッシュが進行します。

ユーザーへの恩恵

独自のワークフローや複数のリモートを使用している環境でも、PR 作成までの流れが中断されず迅速になります。

変更前

ワークツリーの場所に関わらず AI が自動的に移動できていたため、予期せぬディレクトリへの操作のリスクがありました。

変更後

標準的な隔離場所以外のワークツリーにアクセスする際はユーザーに確認を求めるステップが追加されました。

ユーザーへの恩恵

AI による不透明なディレクトリ移動を防ぎ、開発環境の安全性が高まります。

変更前

コールドスタート時に MCP サーバーの起動が間に合わず、許可プロンプト用ツールが見つからずにクラッシュしていました。

変更後

サーバーの接続を待機してからツールを呼び出すようになり、起動時の安定性が向上しました。

ユーザーへの恩恵

自動化されたスクリプトや CI 上での Claude Code 実行がより確実になります。

変更前

セッション記録用トランスクリプトファイルに対する不適切な操作が、自動モード（auto mode）のセキュリティ制御外で行われる可能性がありました。

変更後

トランスクリプトファイルへの改ざんを防ぐための明示的なルールがauto modeに導入されました。

ユーザーへの恩恵

セッション履歴の整合性が保たれ、自動エージェントの操作がより安全かつ信頼できるものになります。

変更前

auto modeにおいて、コンテキストから解決できない変数を対象としたrm -rfコマンドが自動実行されるリスクがありました。

変更後

解決不可な変数を含む削除コマンドに対して、実行前に必ずユーザーの確認を求めるようになりました。

ユーザーへの恩恵

意図しないファイル削除を未然に防ぐことができ、自動エージェント運用の安全性が大幅に高まります。

変更前

通知が人間からの入力がない場合でも「承認」を意味する文脈で表示されることがあり、誤解を招く可能性がありました。

変更後

通知内容に「人間からの入力がない」旨を明記するようにし、トランスクリプト上の自動的な承認動作を制限しました。

ユーザーへの恩恵

エージェントの自律的な動作を人間が誤って承認済みとみなす事故を防止できます。

変更前

OAuthトークンの有効期限が切れると、バックグラウンドセッションが予期せず中断されることがありました。

変更後

有効期限が近づくと通知が表示され、中断前に手動で再認証を行えるようになりました。

ユーザーへの恩恵

セッションの不意な切断を防ぎ、作業を中断させずに継続できるようになります。

変更前

現在のパーミッション設定モードが一目で分からない場合がありました。

変更後

フッターにステータスバッジが追加され、手動モードであることを視覚的に確認できます。

ユーザーへの恩恵

誤って予期しないツール実行を許可してしまうリスクを減らし、安全な作業環境を維持できます。

変更前

パーミッションモードのデフォルト設定が「default」という名称でした。

変更後

「Manual」が標準となり、従来の指定も引き続き受け入れられます。

ユーザーへの恩恵

権限管理の動作が名称からより直感的に理解できるようになり、運用の混乱を防げます。

変更前

SSL関連のエラーが発生すると、解決策が示されないまま何度も無駄なリトライが繰り返されていました。

変更後

接続エラーを検知すると、即座に停止して適切な修正ヒントを提示するようになりました。

ユーザーへの恩恵

不毛な待ち時間が減り、環境設定やネットワーク上の問題を即座に特定して解決できます。

変更前

--dangerously-skip-permissions フラグ付きで daemon サブコマンドを実行すると、CLIがこれを引数ではなく対話プロンプトとして誤解していました。

変更後

コマンドとオプションが正しくパースされ、期待通りの処理が実行されるようになりました。

ユーザーへの恩恵

権限スキップ設定を利用した自動化スクリプトやパイプラインが正しく動作するようになります。

変更前

プランモード中にブラウザツールを使用しようとした際、安全上の確認なしに動作したり、正しく制御できない状況がありました。

変更後

変更を伴う操作に対しては適切に許可を求め、読み取り専用処理は自動的に進むよう最適化されました。

ユーザーへの恩恵

調査や計画段階での安全性が向上し、不必要な確認を減らすことで作業効率が改善されます。

変更前

プランモード移行後に読み取り専用の確認ステップが挟まり、操作を中断されることがありました。

変更後

プランモードの特性に合わせて、読み取り系のアクションは許可されるようになり、シームレスな調査が可能です。

ユーザーへの恩恵

調査と計画のフェーズで過度な確認プロンプトを抑制でき、テンポ良く進められます。

変更前

特定フラグを付けて起動しても設定が正しく反映されず、意図せず安全モードで動作することがありました。

変更後

指定したパーミッション回避モードが正確に適用されるようになりました。

ユーザーへの恩恵

パーミッション設定を回避して作業したい場合に、意図通りの制御で確実にエージェントを起動できます。

変更前

デフォルトでは特定の危険なパターン(任意のコード実行など)のみが分類器でチェックされ、その他のコマンドは通常の権限確認プロセスに従っていました。

変更後

この設定を有効にすると、すべてのシェルコマンドが分類器を通過するようになり、一貫した自動承認判定が可能になります。

ユーザーへの恩恵

安全性を維持しつつ、信頼できる環境での定型的なシェル操作に対する手動承認の頻度をさらに減らすことができます。

変更前

Autoモードで操作が拒否された際、なぜ分類器がそのアクションをブロックしたのかという具体的な理由がユーザーに明示されていませんでした。

変更後

拒否理由がログやUIに表示されるようになり、/permissions コマンドから最近の拒否理由を詳しく確認できるようになりました。

ユーザーへの恩恵

拒否された原因(信頼されていないドメインへのアクセスなど)が明確になるため、設定の修正や例外ルールの追加を迅速に行えるようになります。

変更前

ログイン直後、古いセッション情報やデフォルト設定がキャッシュされたままになり、モデル選択などのUIが正しく更新されないことがありました。

変更後

ログイン完了と同時にクライアントデータが適切にリフレッシュされ、最新の利用可能なモデルや設定が即座に反映されるようになります。

ユーザーへの恩恵

ログイン後の再起動などが不要になり、アカウントに紐づく最新の機能をすぐに使い始めることができます。

変更前

承認操作を行っても設定が保存されず、終了後に再度拒否状態に戻ってしまうことがありました。

変更後

承認した操作は設定として確実に永続化されるようになりました。

ユーザーへの恩恵

権限管理画面での承認操作が一度で済み、作業の妨げとなる繰り返しプロンプトを確実に抑制できます。

変更前

サンドボックス環境下で実行されるコマンドに対して、ローカルの認証情報ファイルや機密性の高い環境変数へのアクセスを制限する詳細な設定が不足していました。

変更後

新しく導入された sandbox.credentials 設定により、サンドボックス内のコマンドが特定の認証ファイルや秘密の環境変数を読み取ることを明示的にブロックできるようになりました。

ユーザーへの恩恵

セキュリティが強化され、エージェントにコマンド実行を許可した際でも、意図せず重要な認証情報が読み取られるリスクを低減できます。

変更前

組織のポリシーで使用が禁止されているモデルであっても、CLI上のモデルピッカーや --model フラグなどで選択できてしまう可能性がありました。

変更後

組織で構成されたモデル制限が反映されるようになり、制限されたモデルを選択した際には「組織の設定により制限されています」というメッセージが表示されます。

ユーザーへの恩恵

管理者が意図した通りのモデル利用を徹底でき、誤って高コストなモデルや未承認のモデルを使用してしまうことを防げます。

変更前

管理者やユーザーが設定したサブエージェントの使用制限ルールが、特定の名前を指定して起動されたサブエージェントに対して機能しない場合がありました。

変更後

あらゆるサブエージェントの起動において、設定された権限ルールが厳格にチェックされるようになりました。

ユーザーへの恩恵

組織のポリシーに基づいた安全なエージェント利用が保証され、意図しないツールの実行を確実に防止できます。

変更前

起動直後の非常に短いタイミングで、制限されているはずのツールが一時的に有効になってしまう脆弱性がありました。

変更後

フラグの読み込みとツールの有効化順序が厳密に管理され、起動の瞬間から制限が確実に適用されるようになりました。

ユーザーへの恩恵

セキュリティポリシーが常に遵守され、制限されたツールが意図せず実行されるリスクが排除されます。

変更前

オートモード(auto mode)では、モデルの判断でコマンドが実行されますが、ローカル作業の破棄を意図していない場合でも、誤って破壊的な操作が行われるリスクがありました。

変更後

意図的な指示がない限り、git reset --hardなどの破壊的なGit操作や、terraform destroyなどのスタック削除コマンドを自動で実行しないようブロックします。

ユーザーへの恩恵

予期しないコードの喪失や、本番環境のインフラ消失といった重大な事故を未然に防ぎ、安心してエージェントに作業を任せられるようになります。

変更前

Linuxのサンドボックス設定で広範なディレクトリにアクセス制限(denyRead/allowRead)をかけると、Bashツールの権限リストが膨大な文字列としてLLMに渡されていました。

変更後

ファイルパスの評価とツール記述の生成プロセスが最適化され、複雑なディレクトリ階層での権限設定があってもセッションの安定性が維持されるようになりました。

ユーザーへの恩恵

セキュリティのために厳格なファイルアクセス制限を適用しても、CLIの動作が重くなったりクラッシュしたりすることなく、安全に開発を継続できます。

変更前

パーミッションの設定では、ツール名全体を許可または禁止することしかできず、特定のモデルの使用や特定の引数での実行を細かく制限することが困難でした。

変更後

Agent(model:opus) のようにツール名とパラメータを組み合わせた指定が可能になりました。ワイルドカード(*)もサポートされており、より柔軟なアクセス制御が実現します。

ユーザーへの恩恵

「Opus モデルのサブエージェントだけを禁止する」といった高度なセキュリティポリシーやコスト管理ルールを、環境に合わせて精密に設定できるようになります。

変更前

自動化スクリプトなどで -p フラグを使用して実行する際、ネストされたスキルが「ディレクトリ名付きの名前」を持つと、権限確認が入り実行が中断されることがありました。

変更後

非インタラクティブな実行時でも、ディレクトリ修飾されたスキルが適切に権限チェックを通過し、スムーズに実行されるようになりました。

ユーザーへの恩恵

CI/CD やバッチ処理などの自動化ワークフローにおいて、複雑なスキル構成であっても途中で止まることなくタスクを完遂できます。

変更前

サブエージェントの定義ファイルで disallowedTools を使用して特定のMCPサーバー全体(例：mcp__github)を拒否しようとしても、その設定が静かに無視されていました。その結果、サブエージェントが本来禁止されるべきMCPツールにアクセスできてしまう可能性がありました。

変更後

サブエージェントのフロントマターにおける disallowedTools フィールドで、mcp__* 形式のワイルドカードやサーバー名による指定が正しく認識されるようになりました。

ユーザーへの恩恵

サブエージェントに許可するツールの制限をより確実に、かつサーバー単位で一括して行えるようになり、セキュリティと制御の精度が向上します。

変更前

管理者がモデルを制限していても、特定の環境変数の操作や高速モードの切り替えによって制限を回避できる可能性がありました。

変更後

許可リスト(availableModels)のチェックが厳格化され、あらゆる経路からの未許可モデルの使用がブロックされます。

ユーザーへの恩恵

組織のポリシーやコスト管理に沿ったモデル運用を確実に徹底できるようになります。

変更前

以前は、管理者が availableModels で利用可能なモデルを制限していても、「デフォルト(Default)」設定のモデルはこの制限を受けず、サブスクリプションに応じた最新モデルが使用される場合がありました。また、ユーザーやプロジェクト単位の設定で、管理者が定めた許可リストにモデルを自由に追加できてしまうという課題もありました。

変更後

新しい enforceAvailableModels を有効にすると、デフォルトモデルも許可リストに従うよう制限されます。不許可のモデルがデフォルトに指定されている場合はリスト内の最初の許可モデルにフォールバックされるほか、ユーザー側での許可リストの拡張も禁止されます。

ユーザーへの恩恵

組織の管理者は、開発者が使用できる AI モデルを厳格に制御できるようになります。これにより、特定のモデル以外の利用を禁止するコンプライアンス要件の遵守や、想定外のモデル利用によるコスト発生を確実に防ぐことが可能です。

変更前

管理ポリシーなどで特定のモデルの使用が制限されていても、UI 上で制限対象のモデルがデフォルトのアドバイザーとして選択された状態になり、エラーの原因となっていました。

変更後

ダイアログを開く際に、許可リストと保存済み設定を照合し、利用可能なモデルのみが選択候補として適切に扱われるようになりました。

ユーザーへの恩恵

組織のポリシーに反するモデルを誤って使用しようとしてエラーに遭遇する手間が省け、スムーズにアドバイザー機能を活用できます。

変更前

管理者が availableModels 設定で使用可能なモデルを制限していても、一部の機能経由では制限対象外のモデルが指定できてしまう漏れがありました。

変更後

サブエージェントやアドバイザー機能を含むすべての箇所で allowlist が厳格に適用されるようになり、ポリシー遵守が徹底されます。

ユーザーへの恩恵

企業のコンプライアンスやコスト管理の観点から特定のモデルに限定して利用させたい場合、設定が確実に機能するようになります。

変更前

*.example.com のようなルールが下位ドメインにマッチしなかったり、ディレクトリ構造の途中にワイルドカードを入れたパス指定がエラーになったりしていました。

変更後

ネットワークおよびファイルのパーミッション規則におけるワイルドカードの解釈が柔軟になり、意図した範囲のアクセス制御が正確に行えるようになりました。

ユーザーへの恩恵

柔軟なアクセス許可設定が可能になり、複数のサブドメインや動的なディレクトリ構造を持つプロジェクトでの運用がスムーズになります。

変更前

VS Code上でPowerShellを使用した際、ツール呼び出しが未加工のJSON形式で表示され、適切なコマンド確認や承認ダイアログが正しく機能していませんでした。また、出力結果に制御文字(ANSIエスケープコード)が混入し、可読性が低下していました。

変更後

PowerShellのツール呼び出しが他のシェルと同様に適切なUIで表示され、承認ダイアログを通じて安全に実行を確認できるようになりました。出力から不要なエスケープコードが取り除かれ、クリーンなテキストが表示されます。

ユーザーへの恩恵

VS CodeでのPowerShell利用時の視認性と安全性が大幅に向上します。実行内容を正確に把握した上で承認できるようになり、デバッグ時のログ確認もスムーズになります。

変更前

管理者が特定の MCP サーバーの使用を制限していても、IDE の連携や起動フラグの組み合わせによって制限を回避できてしまうセキュリティ上の懸念がありました。

変更後

あらゆる経路(再接続、IDE 入力、初回起動フラグ、リモート設定ロード前)において、管理ポリシーが常に最優先で強制適用されるようガードが強化されました。

ユーザーへの恩恵

組織のセキュリティポリシーを例外なく徹底でき、管理の信頼性が向上します。

変更前

悪意のあるプロジェクトを Claude Code で開いた際、ローカルの証明書ファイルを意図しない場所に送信される等のリスクがありました。

変更後

重要なネットワーク監視設定(OTEL 証明書)を変更しようとする場合、ユーザーへの信頼確認が必須となりました。

ユーザーへの恩恵

オープンソースプロジェクトのコードを調査する際など、未知のレポジトリをより安全に扱えるようになります。

変更前

AI が本来編集すべきでない場所を書き換えようとして拒否され、手番(トークン)を無駄にしてしまうことがありました。

変更後

AI は「まず EnterWorktree で作業場所を確保する必要がある」ことを事前に理解するため、無駄な試行を避けて正しい手順を即座に踏むようになります。

ユーザーへの恩恵

特にマルチタスク実行時における AI の動作効率が上がり、トークン消費の無駄を抑えられます。

変更前

拒否ルールで複数のツールを制限する場合、個別にツール名を記述する必要がありました。

変更後

グロブパターンがサポートされ、特定のパターンに一致するツール名や、全てのツールを一括で制限できるようになります。また、起動時に未知のツール名があれば警告が表示されます。

ユーザーへの恩恵

セキュリティポリシーの設定がより簡潔かつ柔軟になり、誤設定も未然に防げるようになります。

変更前

他のセッションから転送されたメッセージが、元のユーザー権限を引き継いでツールを実行できる可能性がありました。

変更後

転送されたメッセージは明示的にユーザー権限がないものとして扱われ、受信側のセッションは転送された権限要求を拒否します。

ユーザーへの恩恵

クロスセッション攻撃などのリスクが低減され、マルチエージェント環境での安全性が大幅に向上します。

変更前

パスの記述方法(チルダと環境変数)の差異を利用して、制限されたディレクトリへのアクセスを許してしまう不備がありました。

変更後

パスの正規化が強化され、異なる表現を使っても同一のディレクトリに対する操作は一貫して制限されます。

ユーザーへの恩恵

組織やプロジェクトで設定したアクセス権限ルールがより正確に適用され、機密データの保護が強化されます。

変更前

一部のドメインが事前に承認されていたため、ユーザーが明示的に「拒否」や「常に確認」のルールを設定しても、それが無視されて自動的にアクセスが許可されてしまうケースがありました。

変更後

ユーザーが設定した個別のドメインルールが最優先されるようになり、事前承認済みのホストに対しても厳格な制御が可能になりました。

ユーザーへの恩恵

セキュリティポリシーをより詳細に制御できるようになり、特定のドメインへのアクセスを確実に制限・監視できる安心感が向上します。

変更前

Windows 特有のパス区切り文字(\)や、ファイルの読み取りを拒否しているにもかかわらず Glob/Grep の検索結果にはファイル名が表示されてしまうといった不具合がありました。

変更後

パスの記述方法に関わらずルールが正確に照合されるようになり、拒否されたファイルは検索結果からも完全に隠されるようになりました。

ユーザーへの恩恵

Windows 環境でのセキュリティ設定の信頼性が高まり、機密ファイルが誤って Claude の視界に入ることを確実に防げます。

変更前

コード定義を検索するための LSP ツールにおいて、ワークスペース全体のシンボル(関数名やクラス名など)を検索しようとしても、クエリが正しく渡されず結果が空になっていました。

変更後

検索キーワードが適切にバックエンドの言語サーバーに伝わるようになり、大規模なプロジェクト内でも目的のシンボルを正確に見つけられるようになりました。

ユーザーへの恩恵

広範囲なコードベースの理解とナビゲーションが正確になり、Claude が関連するコードを見落とす可能性が大幅に減少します。

変更前

組織限定ログインを強制する設定を有効にすると、本来影響を受けないはずの Bedrock などの外部クラウドプロバイダー経由のセッションまで起動できなくなっていました。

変更後

組織ピン留めポリシーを適用しつつ、サードパーティプロバイダーを併用する環境でも正常にセッションを開始できるようになりました。

ユーザーへの恩恵

エンタープライズ環境のセキュリティ設定を維持したまま、業務に必要な様々な AI インフラを柔軟に活用できるようになります。

変更前

エージェントがシェルの起動設定ファイルやGitのグローバル設定を直接書き換えることができ、悪意のある命令が混入した場合にユーザーが気づかず実行してしまうリスクがありました。

変更後

これらの重要なシステム設定ファイルへの変更が行われる前に、ユーザーに対して明示的な承認を求めるプロンプトが表示されるようになります。

ユーザーへの恩恵

セキュリティが強化され、エージェントによる自動的な設定変更がシステムの安全性や意図しない動作に繋がることを未然に防げます。

変更前

acceptEditsモードでは、ファイル編集が自動承認されるため、実行権限を付与するような設定ファイル(.npmrc内のスクリプトなど)が意図せず改ざんされる懸念がありました。

変更後

.npmrc、.yarnrc、.bazelrc、.devcontainerなどの、セキュリティ上重要なビルド・開発環境設定ファイルの編集時に確認プロンプトが表示されます。

ユーザーへの恩恵

利便性を維持しつつ、プロジェクトのビルドプロセスを悪用したコード実行攻撃に対する防御力が向上します。

変更前

Bedrock等でオートモードが無効な際、モデル自体が非対応であるかのような誤解を招くエラーメッセージが表示されていました。

変更後

CLAUDE_CODE_ENABLE_AUTO_MODE 環境変数による明示的なオプトインが必要であることを正しく案内するように変更されました。

ユーザーへの恩恵

設定方法が明確になり、使い慣れたクラウド環境でオートモードを有効にするまでの手順に迷わなくなります。

変更前

Bedrock や Vertex AI などのクラウドプラットフォーム経由で Claude Code を利用する場合、ツールの実行ごとにユーザーの承認が必要な「標準モード」に限定されており、作業が中断されやすい状態でした。

変更後

特定のクラウドプロバイダーを利用している場合でも、分類モデルが安全性を判断して自動でツールを実行する「オートモード」が利用可能になりました。

ユーザーへの恩恵

頻繁な承認作業から解放され、ファイル編集やコマンド実行を伴う複雑なタスクを、より自律的かつスムーズに Claude に任せることができるようになります。

変更前

権限を自動承認する設定にしているにもかかわらず、サンドボックス内でのネットワーク接続時に不要な承認プロンプトが表示されていました。

変更後

設定されたパーミッションモードが正しく尊重され、自動化されたワークフローを妨げる不要なプロンプトが表示されなくなります。

ユーザーへの恩恵

完全なハンズフリー操作が可能になり、エージェントによる一連の作業がよりスムーズに進むようになります。

変更前

/simplifyを実行すると、内部的に/code-review --fixが呼び出されており、単純なコードの簡素化を望んでいる場合でも、バグハンティングを含む重いレビュープロセスが実行されていました。

変更後

/simplifyはクリーンアップ(共通化、効率化など)に特化したレビューとして独立しました。バグの探索は行わず、コードの可読性や効率の改善のみを迅速に行います。

ユーザーへの恩恵

意図しないロジック変更のリスクを減らしつつ、リファクタリングやコードの整理をより高速かつ確実に行えるようになります。

変更前

プロジェクト固有のMCP設定ファイルが含まれているリポジトリで、中身を十分に確認する前にツールが自動的に承認・接続してしまう可能性があり、セキュリティ上の懸念がありました。

変更後

未承認のサーバーは明示的に「保留中」としてリストに表示され、ユーザーの同意なしに接続されることがなくなりました。

ユーザーへの恩恵

信頼できない可能性のある外部リポジトリのコードを扱う際、意図しないローカルプロセスの実行やデータアクセスを確実にブロックでき、安全性が向上します。

変更前

危険なコマンドの実行を防ぐガード機能がありましたが、パスの末尾に/があるといった些細な表記の違いによって、一部の破壊的な操作が検知をすり抜けてしまうリスクがありました。

変更後

パスの正規化が改善され、表記の揺れに関わらずホームディレクトリなどの重要な場所に対する削除操作が確実にブロックされます。

ユーザーへの恩恵

Claudeが誤ってシステムを破壊するようなコマンドを実行してしまうリスクがさらに低減し、安心して強力な権限を任せられます。

変更前

メインセッションで厳格な制限(--bare等)をかけていても、サブエージェント経由で未許可のツールが読み込まれる可能性がありました。

変更後

すべてのサブエージェントが、親セッションのセキュリティポリシーと管理者の設定を正しく継承するようになります。

ユーザーへの恩恵

組織全体のセキュリティコンプライアンスが強化され、AIの自律的な動作をより安全に管理できます。

変更前

ツール自身の管理用フォルダへの書き込みに対して、ユーザーに都度パーミッションの承認を求めるノイズが発生していました。

変更後

内部的な管理操作が適切に識別され、不要な警告で作業が中断されることがなくなります。

ユーザーへの恩恵

パーミッション承認の回数が減り、より「全自動」に近いスムーズな動作を体感できます。

変更前

作業の分離のためにワークツリーに入ろうとしても、特定の条件を満たすまでツールが呼び出せず、AIのステップが無駄に増えていました。

変更後

セッション開始直後から、AIが判断すればすぐにワークツリーを作成して作業を開始できます。

ユーザーへの恩恵

タスクの完了までのステップ数が減り、実行速度の向上とコストの削減につながります。

変更前

スキル実行中に、意図しないツールの使用(例：特定の操作中にファイル削除ツールを呼ばせないなど)をきめ細かく制御することが困難でした。

変更後

スキルごとに利用可能なツールのセットを制限できるため、モデルが特定のワークフローに集中し、より安全かつ正確に動作するように定義できます。

ユーザーへの恩恵

カスタムコマンドの挙動をより厳密に制御でき、エージェントによる誤操作や不要なツール呼び出しのリスクを軽減できます。

変更前

PowerShellで「cd..」や「cd\」などの組み込みエイリアスを使って移動した場合、Claude Codeがカレントディレクトリの変化を正しく追跡できず、本来制限されるべきワークスペース外へのアクセスが許されてしまうリスクがありました。

変更後

あらゆる形式のディレクトリ移動コマンドが正確に監視されるようになり、移動後のパーミッション検証が厳格に適用されます。

ユーザーへの恩恵

意図しないディレクトリ移動によるセキュリティ上の脆弱性が排除され、Windows環境でもより安全にツールを使用できます。

変更前

git worktree内で作業している際、Claudeが誤ってメインリポジトリ全体の書き込み権限を持ってしまい、サンドボックスの隔離が不十分でした。

変更後

書き込み許可範囲が、ワークツリーで共有が必要な.gitディレクトリの一部のみに厳密に絞り込まれ、hooksやconfigへの不正な書き込みもブロックされるようになりました。

ユーザーへの恩恵

複数のワークツリーを並行して使用する際の安全性が向上し、メインのプロジェクト設定を誤って変更される心配がなくなります。

変更前

PowerShell向けに特定のコマンド(例：dotnet.exe)をワイルドカードで許可設定していても、実際の実行時に再度承認を求められる場合がありました。

変更後

ワイルドカードを含む許可ルールがネイティブの実行ファイルやスクリプトに対しても正しく適用されるよう、パーミッションエンジンの解析を改善しました。

ユーザーへの恩恵

一度許可した開発コマンドがスムーズに実行されるようになり、頻繁な承認プロンプトによる作業の中断が減ります。

変更前

ディレクトリ移動コマンドを連続して実行した際、Claude Codeが古いディレクトリ情報の変数値を参照してしまい、パーミッション判定を誤る可能性がありました。

変更後

ディレクトリスタックや現在のパスに関する変数が移動のたびに最新の状態に更新・検証されるようになり、常に正確なパスに基づいた権限管理が行われます。

ユーザーへの恩恵

複雑なディレクトリ操作を伴うタスクにおいても、セキュリティポリシーが常に一貫して適用されます。

変更前

管理者設定で特定の組織へのログインを強制していても、サードパーティ提供のモデルやAPIキーを介したアクセスではその制限を回避できる可能性がありました。

変更後

あらゆる接続方法において管理者が定義したログイン・組織ポリシーが厳格に適用され、セキュリティガバナンスが強化されます。

ユーザーへの恩恵

組織全体のセキュリティポリシーが一貫して適用されるため、管理者はアクセス権限をより確実に制御でき、企業のコンプライアンス維持に役立ちます。

変更前

自動承認設定にしていても、重要な確認事項がある際にClaudeがユーザーに質問できず、作業が止まったり誤った判断をしたりする可能性がありました。

変更後

オートモード中でも必要な時には適切に質問が届くようになり、ユーザーの回答を踏まえた安全な自律実行が継続されます。

ユーザーへの恩恵

「基本は自動、必要なときだけ相談」という理想的な自律動作が実現し、安心して複雑な作業を任せられるようになります。

変更前

UIパーツが重なったり、余白が不自然だったりして、一部の画面で情報が見づらい箇所がありました。

変更後

各設定画面のレイアウトが整理され、視認性と操作性が向上します。

ユーザーへの恩恵

設定の確認や権限の管理などの管理作業を、より快適な画面でミスなく行えるようになります。

変更前

Auto mode では、バックグラウンドの分類モデルがユーザーへの確認プロンプトを自動的に処理・抑制しますが、その過程で必要な多肢選択式の質問(AskUserQuestion)まで表示されなくなることがありました。

変更後

ユーザーが直接質問を求めた場合や、スキルの実行フローにおいて AskUserQuestion が明示的に呼び出された場合は、Auto mode であっても質問が表示され、ユーザーが対話できるようになりました。

ユーザーへの恩恵

自動化されたワークフローの途中で要件の曖昧さを解消するための質問を Claude が行えるようになり、意図しないコード生成や作業の中断を防ぐことができます。

変更前

ファイルの一部だけを確認して編集しようとした際に「ファイルをまだ読んでいない」と判定されたり、検索でヒットがないだけで「エラー」と表示されたりと、挙動が過剰に厳格でした。

変更後

部分的な読み取りでも編集の準備ができていると判断されるようになり、また「ヒットなし」は正常な検索結果として扱われるように緩和されました。

ユーザーへの恩恵

AI が不必要な「再読み取り」や「検索失敗への謝罪」を繰り返すことが減り、よりスムーズで意図に沿ったレスポンスが得られるようになります。

変更前

企業のセキュリティポリシーで特定の組織へのログインを強制している環境において、クラウド上のセッション(--remote)を利用しようとすると認証エラーが発生していました。

変更後

組織制限のポリシーとリモートセッションの認証プロセスが正しく共存できるようになり、組織内の開発者が安全にクラウド機能を利用できるようになりました。

ユーザーへの恩恵

エンタープライズユーザーが会社のガバナンスを維持したまま、全ての Claude Code 機能を利用できるようになります。

変更前

対話セッション中に一時的に追加した別の作業ディレクトリの情報が、バックグラウンドセッションへ移行する(デタッチ)タイミングでリセットされてしまっていました。

変更後

デタッチしてバックグラウンドに回した後でも、AI は最初に追加された全てのディレクトリへ引き続きアクセス可能です。

ユーザーへの恩恵

複数ディレクトリにまたがる大規模なタスクを、途中でバックグラウンドに切り替えても AI の作業継続に支障が出なくなります。

変更前

バックグラウンドで開始されるエージェントの権限モードやモデル、努力レベルを一括で制御する手段が不足していました。

変更後

--permission-mode, --model, --effort, --dangerously-skip-permissions がエージェントビューでも有効になりました。

ユーザーへの恩恵

大量のタスクを投入する際に、一度のフラグ指定で全セッションの挙動(承認の有無や賢さ)を統一できます。

変更前

バックグラウンドセッションが一度アイドル状態から復帰すると、スキップフラグが消えてしまい、承認プロンプトで作業が止まってしまうことがありました。

変更後

一度「バイパスモード」で開始したバックグラウンドタスクは、再開後もその権限設定を保持し続けます。

ユーザーへの恩恵

無人での自動実行を期待しているバックグラウンド作業が、途中で止まることなく最後まで完遂されます。

変更前

エージェントビューからタスクを開始すると、ユーザー設定を無視して常に「auto」モードで開始されるなどの不整合がありました。

変更後

プロジェクトやユーザー設定で定義したデフォルトの権限モードが、バックグラウンド起動時にも正しく適用されます。

ユーザーへの恩恵

自分の好みの承認ワークフロー(planモードなど)を、バックグラウンド作業でも一貫して利用できます。

変更前

セッションをバックグラウンドに移動させたり一覧に戻したりすると、特定の権限モードを許可するフラグ情報が引き継がれず、再度モード変更が必要になる場合がありました。

変更後

フォークされたバックグラウンドワーカーでもフラグが維持されるため、Shift+Tab キーの切り替えサイクルの中で常に「パーミッションのスキップ」モードが選択可能な状態になります。

ユーザーへの恩恵

信頼できる環境での作業中に、セッションの切り替えを行っても権限設定をやり直す手間が省け、スムーズに開発を継続できます。

変更前

フラグを指定すると、最初から「全承認スキップ」という危険な状態でセッションが始まってしまうことがありました。

変更後

フラグの意味通り「スキップモードを選択可能にする」状態になり、意図的に選ばない限りは安全なモードで開始されます。

ユーザーへの恩恵

安全性を保ちつつ、必要なときだけ高度な権限モードへスムーズに切り替えられる柔軟性が得られます。

変更前

バックグラウンドで動作するエージェントセッションを開始する際、ディレクトリの追加指定や詳細な MCP 設定、パーミッションモードなどをコマンドラインから個別に制御することが困難でした。

変更後

claude agents コマンドに --settings や --mcp-config、--permission-mode などの豊富なフラグが追加され、起動時にセッションの挙動を細かくカスタマイズできるようになりました。

ユーザーへの恩恵

メインセッションと同様の柔軟な設定をバックグラウンドタスクにも適用できるため、複雑なプロジェクト環境での並列作業がよりスムーズになります。

変更前

パーミッション確認をスキップする設定でエージェントを動かしていても、セッションの中断・再開後にその設定が消失し、再度承認が必要になることがありました。

変更後

バックグラウンドタスクの権限設定が永続化され、再開後も一貫して自動実行が継続されます。

ユーザーへの恩恵

長時間放置する自動化タスクにおいて、知らない間に承認待ちで停止してしまう事態を防げます。

変更前

複数のワークスペースをカバーするアイデンティティ連携ルールを使用している場合、発行されたトークンの適用範囲を特定のワークスペースに絞り込むことが困難でした。

変更後

ANTHROPIC_WORKSPACE_IDを指定することで、ミントされたトークンのスコープを明示的に一つのワークスペースに固定できるようになります。

ユーザーへの恩恵

企業レベルでの権限管理において、最小権限の原則に基づいたよりセキュアな認証運用が可能になります。

変更前

Autoモードで許可プロンプトが表示された際、それが組み込みの安全チェックによるものか、ユーザーが自分で設定したカスタムルールによるものかが判別できませんでした。

変更後

権限ダイアログ内に、どのpermissions.askルールがトリガーとなったかの説明が表示されるようになります。

ユーザーへの恩恵

自分が設定したカスタムルールの動作を正確に把握でき、意図通りのガードレールが機能しているかを確認しやすくなります。

変更前

IDE(VS Code/JetBrains)を接続している状態でも、パーミッションプロンプトから直接IDEの強力な差分ビューアーを呼び出せなくなっていました。

変更後

IDEが接続されている場合、ファイル編集の承認前にIDE上の使い慣れたUIで変更箇所を詳細に確認できるオプションが再提供されます。

ユーザーへの恩恵

ターミナル上の簡素な差分表示だけでなく、IDEの高度な比較機能を使って、 Claudeの変更をより慎重かつ迅速にレビューできます。

変更前

対話型セッションをバックグラウンドに移行させると、それまで設定していたパーミッションモード(PlanモードやAutoモードなど)がリセットされ、デフォルトに戻ってしまっていました。

変更後

バックグラウンドへの移行後も、現在のセッションで選択されている権限設定がそのまま引き継がれます。

ユーザーへの恩恵

移行のたびにモードを再設定する手間が省け、特定の権限レベルが必要な長時間タスクも一貫した挙動で任せることができます。

変更前

Claude.aiログインとAPIキー(Console)の設定が混在している場合、一部の機能がどちらの権限で動作しているか曖昧になることがありました。

変更後

明示的にAPIキー( Console認証等)が設定されている場合は、それに基づく動作に限定され、意図しない課金や動作の混乱を防ぎます。

ユーザーへの恩恵

認証方式による機能の挙動が明確になり、セキュアで予測可能な利用環境が保証されます。

変更前

$VAR や $(cmd) を含むコマンドは、内容が安全であってもサンドボックス内での自動承認対象から外れ、毎回許可を求められていました。

変更後

これらのシェル拡張を含むコマンドも、サンドボックスの保護下で適切に自動承認されるようになります。

ユーザーへの恩恵

複雑なスクリプトやコマンドを実行する際の承認プロンプトが減り、作業のテンポが改善されます。

変更前

スキルの権限設定でワイルドカードを使っても、意図した通りのプレフィックス一致が行われない場合がありました。

変更後

Bashコマンドと同様のルールでワイルドカードが動作し、特定のプラグイン配下のスキルを一括で許可するなどの設定が確実に反映されます。

ユーザーへの恩恵

きめ細やかな権限管理を少ない記述で確実に行えるようになります。

変更前

オートモードの判定において、ユーザーの意図や特定の例外設定に関わらず、組織のポリシーとして絶対に禁止したい操作を厳密に制御する手段が不足していました。

変更後

settings.autoMode.hard_deny を設定することで、指定されたルールに抵触する操作をオートモードの分類器が無条件でブロックするようになります。

ユーザーへの恩恵

デプロイや権限変更などの重要な操作を確実にガードし、AIによる意図しない高リスクな操作を未然に防ぐことができます。

変更前

本来はコードを変更しないはずのプランモードにおいて、設定ファイルで許可されたパスに対しては、モデルが誤って直接書き込みを行ってしまう場合がありました。

変更後

プランモードのガードレールが強化され、どのような許可設定があってもプランニング中はファイルの変更が確実に抑制されるようになりました。

ユーザーへの恩恵

安心してコードベースの調査をAIに任せることができ、不用意にソースコードが書き換えられる心配がなくなります。

変更前

Linux環境でサンドボックス機能を使用する際、bubblewrap などのバイナリが標準以外のパスにインストールされていると、正常に動作させることが困難でした。

変更後

管理設定でカスタムパスを指定できるようになったため、特殊な環境やセキュリティ制限のあるシステムでもサンドボックスを正しく利用できます。

ユーザーへの恩恵

OS標準のパッケージ管理以外でツールを導入している環境でも、安全な隔離実行環境を維持できるようになります。

変更前

ファイルアクセスの許可範囲をドライブ直下に設定している場合、正しいルールであっても認識に失敗し、都度ユーザーの承認を求められていました。

変更後

ルートディレクトリに対する許可ルールのマッチングロジックが修正され、設定した権限が正しく適用されるようになりました。

ユーザーへの恩恵

広い範囲に書き込み許可を与えている設定において、不要なプロンプトによる中断がなくなり、作業効率が向上します。

変更前

追加ディレクトリとして指定したパスがネットワーク上のマップされたドライブにある場合、Read/Write/Edit 権限が正しく認識されずアクセス拒否される場合がありました。

変更後

ネットワークドライブ上のパスに対する権限判定が改善され、ローカルドライブと同様にシームレスなファイル操作が可能になりました。

ユーザーへの恩恵

共有サーバーや外部ストレージ上にプロジェクト資産がある場合でも、Claude Code を制限なく利用できるようになります。

変更前

プランモードのセッションを再開する際、指定したパーミッション設定が反映されなかったり、一度モードを抜けると期待通りにプランニングに戻れなかったりする不整合がありました。

変更後

再開時やモード切り替え時の挙動が修正され、常に指定した権限モードで一貫した操作ができるようになりました。

ユーザーへの恩恵

プランニングから実行への移行や、非対話モードでの継続的なタスク実行において、意図した権限レベル(Permission Mode)が確実に維持されるようになります。

変更前

ポリシーによって操作が拒否された際、詳細な調査に必要なリクエストIDが表示されず、サポートへの問い合わせが困難でした。

変更後

エラーメッセージにAPIリクエストIDが直接表示されるようになり、問題発生時のトレーサビリティが向上します。

ユーザーへの恩恵

組織での導入時にトラブルが発生しても、管理者が迅速に原因を特定し、Anthropicのサポートを受けやすくなります。

変更前

プロジェクト内のディレクトリ作成やファイル生成を許可するルールを設定していても、正しく認識されず毎回承認を求められることがありました。

変更後

プロジェクト内部のパスに対する標準的なファイルシステム操作の許可ルールが、期待通りに動作するようになります。

ユーザーへの恩恵

ディレクトリ作成などの定型的な操作において、煩わしい承認プロンプトを減らし、開発のテンポを維持できます。

変更前

SDK 経由で利用している際、ツール実行を「常に許可」しても設定がプロジェクトファイルに適切に保存されず、繰り返し承認を求められることがありました。

変更後

「常に許可」の選択がローカル設定ファイルに反映されるよう促され、永続的に承認をスキップできるようになります。

ユーザーへの恩恵

繰り返しのパーミッション確認を自動化設定へと簡単に移行でき、開発のテンポを損ないません。

変更前

オートモードが負荷などで判断を下せなかった場合、単にエラーが表示されるだけで、ユーザーが次に何をすべきか不明確でした。

変更後

エラーメッセージとともに、再試行やコンテキストの圧縮などの具体的な解決策が提示されます。

ユーザーへの恩恵

エラー発生時も作業を中断せず、適切な対処をすぐに行えるようになり、自己解決のスピードが向上します。

変更前

--dangerously-skip-permissions(権限確認スキップ)を指定していても、設定ファイルやGit管理ディレクトリなどの重要なパスへの書き込みには個別の承認プロンプトが表示されていました。

変更後

重要なシステムパスや設定ディレクトリへの書き込みもスキップ対象に含まれるようになりました(ただし、致命的な削除コマンドなどは引き続き安全策として確認が表示されます)。

ユーザーへの恩恵

CI環境や信頼できるサンドボックス内での自動実行において、不要な中断をさらに減らし、よりスムーズな自動ワークフローを実現できます。

変更前

複数の管理設定ファイルがある際、最優先のソースにsandbox設定の記述がないと、他の設定ファイルで定義されたドメイン制限や読み取り制限が適用されない不備がありました。

変更後

設定の優先順位に関わらず、複数の管理設定ソースから提供されるサンドボックスの制限が正しくマージされ、適用されるようになりました。

ユーザーへの恩恵

組織の管理者によって定義されたセキュリティ制限が漏れなく適用されるようになり、意図しないドメインへのアクセスやファイル読み取りをより確実に防止できます。

変更前

Windows環境において、クリップボードへのコピー内容がコマンドライン引数として渡されていたため、EDRやSIEMなどの監視ツールに機密内容が記録されるセキュリティリスクがありました。また、大容量(22KB以上)のテキストをコピーしようとすると失敗する制限も存在していました。

変更後

クリップボードの操作がより安全な方法に変更され、監視ツールへの露出がなくなると同時に、大規模なファイル内容も確実にコピーできるようになりました。

ユーザーへの恩恵

機密コードの取り扱いにおけるセキュリティが向上し、かつ長大なドキュメントやコードベースのコピーもエラーなく実行できるため、開発作業の安全性が高まります。

変更前

/rewind で履歴を操作したセッションから /branch を行うと、内部的なIDの不整合が起き、フォークされたセッションがエラーで動作しないことがありました。

変更後

タイムラインが操作された複雑な履歴を持つセッションからでも、正しく整合性を保った状態で新しいブランチ(フォーク)を作成できるようになりました。

ユーザーへの恩恵

試行錯誤を繰り返した長い会話からでも、エラーを気にせず安全に新しい作業枝を切り出すことができます。

変更前

「パーミッション確認をスキップする」設定にしていても、Claude Code 自身の構成ファイルが格納される特定のディレクトリへの書き込みには、安全上の理由から追加の確認が求められていました。

変更後

スキルやエージェントの定義ディレクトリへの書き込みが自動承認の対象に含まれました。これにより、Claude に自身のスキルを自律的に追加・修正させる際のフローが中断されなくなります。

ユーザーへの恩恵

Claude に自身の機能を拡張させる自動化タスクにおいて、ユーザーが手動で承認ボタンを押す手間が省け、完全な自律動作を実現できます。

変更前

詳細なコードレビューを行う /ultrareview は CLI 内の対話型セッションからしか起動できず、CI パイプラインや外部スクリプトへの組み込みが困難でした。

変更後

claude ultrareview サブコマンドにより、対話なしでレビューを実行し、結果を stdout や JSON 形式で受け取れるようになりました。

ユーザーへの恩恵

GitHub Actions 等の CI 上で、マージ前に AI による検証済みのバグ発見プロセスを自動化でき、品質管理の効率が大幅に向上します。

変更前

PR に関連付けられたセッションを再開する機能が標準の GitHub.com にのみ限定されていました。

変更後

主要なコードホスティングプラットフォーム(GitLab、Bitbucket)や企業向け GitHub インスタンスの URL にも対応しました。

ユーザーへの恩恵

業務で GitHub 以外を使用している開発者も、ブラウザ上の PR URL をそのまま CLI に貼り付けるだけで、関連する作業コンテキストを即座に復元できます。

変更前

スクリプトなどから -p フラグで実行する際、カスタムエージェントの設定で禁止したツールが無視されて使用されてしまう可能性がありました。

変更後

非対話モードでもフロントマターの設定が厳密に守られ、エージェントが使用できるツールの制限が対話モードと完全に同期されました。

ユーザーへの恩恵

CI/CD パイプラインなどの自動実行環境においても、意図しないツールの実行を防ぎ、セキュリティと動作の予測可能性を高めることができます。

変更前

組み込みエージェント(Explore や Plan など)を明示的に呼び出した際、そのエージェントに定義されている推奨パーミッションモードが反映されないことがありました。

変更後

エージェントごとに設定された最適なパーミッションモード(例：読み取り専用、または自動承認)が自動的に適用されます。

ユーザーへの恩恵

タスクに合わせて最適な安全レベルや自動化レベルが設定済みのエージェントを、手間なく安全に利用開始できます。

変更前

フックからツールの実行時間を把握することが難しく、どの操作に時間がかかっているかの正確な計測が困難でした。

変更後

フックへの入力データにミリ秒単位の duration_ms が追加され、ユーザーの承認待ち時間を除いた純粋な処理時間を取得できるようになりました。

ユーザーへの恩恵

独自のメトリクス収集や、処理の重いツール呼び出しの検知など、開発プロセスの分析と最適化がより精緻に行えるようになります。

変更前

管理設定で特定のマーケットプレイスをブロックするために hostPattern や pathPattern を指定しても、一部の条件下で強制力が不十分であったり、正しく評価されなかったりする可能性がありました。

変更後

設定された正規表現パターンに基づいてホストやファイルパスが厳密にチェックされ、ネットワーク通信やファイル操作の前にブロック対象かどうかが正しく判断されるようになりました。

ユーザーへの恩恵

組織の管理者が信頼できないプラグインソースをより確実に制限できるようになり、開発環境のセキュリティガバナンスを強化できます。

変更前

オートモードの信頼済みドメインや禁止ルールをカスタマイズしようとすると、既存のデフォルト設定がすべて上書きされてしまうため、標準の安全な設定をすべて手動でコピーして再定義しなければなりませんでした。

変更後

"$defaults" プレースホルダーを使用することで、標準設定を維持したまま、自社独自の追加ルールだけを差分として簡単に記述できるようになりました。

ユーザーへの恩恵

デフォルトの強力な安全策を損なうことなく、最小限の設定で独自の環境に合わせた最適化が行えるため、オートモードの導入がより安全かつスムーズになります。

変更前

権限を完全にスキップする設定で起動していても、UI上の表示がオートモードのままになり、現在の権限状態を誤解させる可能性がありました。

変更後

設定に合わせて「Bypass permissions(パーミッションのバイパス)」が正しく表示されるようになりました。

ユーザーへの恩恵

現在のセキュリティ設定を正しく把握でき、意図した通りの権限レベルで作業を行っていることを確認できます。

変更前

会話を分岐(フォーク)させるたびに全履歴が重複して保存され、ディスク容量を不必要に消費していました。

変更後

親セッションへのポインタのみを記録し、読み込み時に履歴を復元する方式に変更されました。

ユーザーへの恩恵

大量のフォークを作成してもストレージの消費を最小限に抑えられ、動作も高速になります。

変更前

ファイル検索や文字列検索の際、独立したツールを呼び出すために AI エージェントとのやり取りが複数回発生し、オーバーヘッドが生じていました。

変更後

Bash 経由で最適化されたバイナリが直接実行されるため、大規模なコードベースでの検索が劇的に高速化されます。

ユーザーへの恩恵

数千ファイルを超えるプロジェクトでも、待機時間を最小限に抑えて目的のコードを瞬時に見つけることができます。

変更前

巨大なドキュメントサイトなどを読み込もうとすると、HTML から Markdown への変換処理でリソースを過剰に消費し、アプリが反応しなくなることがありました。

変更後

処理可能なサイズに自動的に調整されるため、ハングすることなくページの主要な内容を取得できます。

ユーザーへの恩恵

外部ドキュメントの参照がより安定し、不安定な挙動に悩まされることがなくなります。

変更前

サンドボックス環境で動作している際、本来保護されるべきルートディレクトリやホームディレクトリへの削除操作が、自動承認設定によって誤って許可されてしまう可能性がありました。

変更後

重要なシステムディレクトリに対する破壊的なコマンド操作については、たとえ自動承認設定であっても、既存の厳格な危険パスチェックを必ず通るようにセキュリティが強化されました。

ユーザーへの恩恵

意図しないファイル削除やシステムへの致命的な損傷のリスクが軽減され、AI へのコマンド実行許可をより安全に管理できます。

変更前

実質的なディレクトリ移動が発生しない cd コマンドであっても、複合コマンドの一部として許可を求められていました。

変更後

現在のディレクトリへの cd 操作が「何も行わない(no-op)」と判断され、不必要な確認ダイアログがスキップされるようになりました。

ユーザーへの恩恵

頻繁に発生する確認プロンプトが減り、開発のリズムを妨げずに作業を継続できます。

変更前

削除コマンド(rm)を許可している場合、誤ってmacOSの重要なシステムディレクトリを削除対象に含めてしまうリスクがありました。

変更後

システム保護のため、特定の重要ディレクトリを「危険なターゲット」として識別し、保護を強化しました。

ユーザーへの恩恵

万が一の誤操作や誤認識による、OSの動作不能を引き起こすような破壊的変更からPCを守ります。

変更前

特定のコマンドを拒否していても、sudo や env などのラッパー経由で呼び出されると、拒否ルールを回避できる可能性がありました。

変更後

主要な実行ラッパー(sudo, env, watch, ionice等)を解析し、その内部で実行されるコマンドに対しても拒否ルールが機能するようになりました。

ユーザーへの恩恵

より強固な権限管理が可能になり、意図しない特権実行やコマンドの実行を確実に阻止できます。

変更前

「ファイル検索(find)」を許可していると、検索結果をそのまま削除したり外部コマンドを実行したりする危険なオプションも自動承認されていました。

変更後

破壊的な操作を伴う find コマンドのオプションに対しては、検索許可に関わらず必ずユーザーの確認を求めるようになりました。

ユーザーへの恩恵

検索のつもりが一括削除されてしまうような、取り返しのつかない事故を未然に防ぐことができます。

変更前

サンドボックスを無効化して実行する(危険な)操作が、ユーザーの最終確認なしに行われてしまう可能性がありました。

変更後

サンドボックス無効化時には、通常のパーミッションフローが強制され、必ず明示的な許可を求めるようになりました。

ユーザーへの恩恵

システムの保護層を外す重要な操作に対して常に監視の目が届くようになり、安全性が向上します。