policyHelper.path

変更前

Write ツールで既存のディレクトリを対象パスに指定した場合、権限拒否としてサイレントにターンを終了していたため、ユーザーには問題の原因が分からなかった。

変更後

対象パスが既存ディレクトリの場合、Write ツールはターンを黙って終了させる代わりに、明確なエラーを報告する。

ユーザーへの恩恵

既存ディレクトリへの書き込みが拒否された理由がユーザーに明確に伝わるようになる。

変更前

ツール呼び出しのファイルパスに u0000 とエスケープシーケンスで書かれた null バイトが含まれると、「Path contains null bytes」というエラーが発生し、ターンが途中で終了していた

変更後

エスケープ制御文字がリテラルテキストとして扱われ、null バイトを含むパスがあってもターンが正常に続行される

ユーザーへの恩恵

エスケープシーケンスで書かれた null バイトを含むパスでもターンが中断されず、エスケープされた制御文字がリテラルテキストとして扱われるようになる

変更前

作業フォルダのパスが120文字程度以上ある Windows 環境で、Read ツールによる PDF のページ読み取りが失敗していた。

変更後

作業フォルダのパスが120文字程度以上ある場合でも、Windows で PDF のページ読み取りがエラーにならずに完了する。

ユーザーへの恩恵

深い階層に置いた PDF でもページ単位の読み取りができ、長いパス環境での解析作業が途切れなくなる。

変更前

/update-config で Write(path) 形式のパーミッションルールが書き込まれていた。ファイルパーミッションのチェックは Edit(path) ルールのみに対して行われるため、書き込まれた Write(path) ルールはどのチェックにも一致しなかった。

変更後

/update-config で Edit(path) 形式のパーミッションルールが書き込まれる。

ユーザーへの恩恵

設定ファイルに書き込まれたパーミッションルールが実際のファイル編集チェックで正しく機能するようになる。

変更前

ローカルファイルパスのリンクをクリックすると、file:// URI を生成して該当ファイルを開ける。

変更後

VS Code や file:// URI が必要なターミナルで、ローカルファイルパスのリンクをクリックしても動作しない状態だった。

ユーザーへの恩恵

ローカルファイルパスのリンクをクリックするだけで該当ファイルを開けるようになり、パスを手動でたどる手間が省ける。

変更前

XDG_CONFIG_HOME に絶対パスが設定されている環境では、グローバル gitignore の既定が ~/.config/git/ignore になり、設定済みの .claude/settings.local.json 除外が機能しなくなる。

変更後

XDG_CONFIG_HOME に絶対パスが設定されている環境では、グローバル gitignore の既定が ~/.config/git/ignore のままになり、設定済みの .claude/settings.local.json 除外がファイルの移動後に機能しなくなる。

ユーザーへの恩恵

XDG_CONFIG_HOME に絶対パスを設定していても、settings.local.json が確実にコミット対象外になり、手動の gitignore 管理が不要になる。

変更前

macOS では、ファインダーなどからドラッグ&ドロップされたスクリーンショットや、システムが複数のパスで報告するファイルを Read ツールで読もうとすると、権限チェック後にシンボリックリンクの解決結果が変化したと誤判定され、「symlink resolution changed after permission was checked」というエラーで読み込みが拒否されていた。

変更後

シンボリックリンクの解決結果が権限チェック後に変化した場合の再チェックに macOS 特有のパスも考慮するようになり、ドラッグ&ドロップで読み込んだスクリーンショットなど、システムが別パスで報告するファイルも誤って拒否されなくなった。

ユーザーへの恩恵

ドラッグ&ドロップしたスクリーンショットや別パスで報告されるファイルを、追加操作なしにそのまま Claude Code に読み込ませられるようになる。

変更前

Windows で、--add-dir でマップ済みネットワークドライブを追加した場合でも、そのドライブが指す実際の UNC パス(例: net use Z: を使わずに直接アクセスするような UNC パス) に対するネットワークパス権限チェックが正しく適用されない、または逆に不要なプロンプトが発生していました。

変更後

Windows で、--add-dir でマップ済みネットワークドライブを追加した際に、UNC パスに対するネットワークパス権限チェックが改善されました。以前は、ドライブ文字として追加したマップ済みネットワークドライブが実際には UNC パスを指している場合、その背後の UNC パスに対する権限チェックが正しく機能しない、または不要なプロンプトが表示されることがありました。改善後は、マップ済みネットワークドライブ経由で UNC パスにアクセスする際の権限判定がより正確に行われます。

ユーザーへの恩恵

マップ済みネットワークドライブを --add-dir で追加したユーザーが、Windows のネットワークパスに関する権限チェックの挙動をより一貫したものとして体験できます。

変更前

SIGTERM によるドレインの際、ランナーはセッション終了の理由をサーバーに通知する方法を持たず、ホスト単位の計画的なドレインと個別セッションの中断を区別できなかった。

変更後

SIGTERM ドレイン時に --drain-marker-file <path> で指定したパスにファイルが存在する場合、ランナーは自身の終了をホストのドレインとしてサーバーに報告する。報告はテレメトリのみに使われ、動作は変化しない。

ユーザーへの恩恵

Kubernetes のローリング再起動などでの SIGTERM ドレイン時に、運用者はサーバー側のテレメトリでホスト単位のドレインを識別できるようになり、ドレイン起因のセッション中断を正確に把握できる。

変更前

`/add-dir` にパスを入力する際、左右の矢印キーでカーソルを移動できず、Enter を押すとハイライト表示された補完候補も一緒に追加されていた。

変更後

`/add-dir` にパスを入力する際、左右の矢印キーでカーソルを移動できるようになり、Enter キーを押すと入力したパスだけが追加される。以前は矢印キーでカーソルを移動できず、Enter を押すとハイライト表示された補完候補も一緒に追加されていた。

ユーザーへの恩恵

ユーザーは入力途中のパスを自由に修正でき、意図したパスだけを確実に追加できる。

変更前

セッションの一時出力ファイルのパスが 260 文字に達すると、PowerShell コマンドが「Exit code 1」というエラーと空の出力で失敗していた。コマンドの実際の出力はどこにも表示されず、原因を突き止めるのが困難だった。

変更後

セッションの一時出力ファイルのパスが Windows の MAX_PATH 制限(260文字)に達しても、PowerShell コマンドが「Exit code 1」というエラーと空の出力で失敗しなくなった。

ユーザーへの恩恵

出力ファイルのパスが Windows の MAX_PATH(260文字)制限に達しても PowerShell コマンドが失敗しなくなり、エラーの内容を確認できるようになる。

変更前

headersHelperの同意プロンプトには、marketplace.jsonの取得やプラグインのダウンロード先であるURLパスが表示されていた。パスの文字列の見え方によっては、別のホストへのリクエストのように誤読される可能性があった。

変更後

同意プロンプトには、コマンドが発行されたマーケットプレイスURLのホストを含むオリジン全体が表示される。ユーザーは、ヘルパーに渡されるURLが実際にどのサーバーへのリクエスト用なのかをパスから判断する必要がなくなった。

ユーザーへの恩恵

ユーザーは、同意プロンプトを見てヘルパーがどのサーバーと通信するのかを正確に判断し、安心してコマンドを承認できるようになった。

変更前

Windows で @ で始まる名前のフォルダを含む相対パスを持つプラグインでエラーが発生すると、実際のパスの代わりに [redacted URL] というマスク文字列が表示されていた。

変更後

相対パスで参照される Windows のフォルダ名が @ で始まるプラグインでも、エラーメッセージ内のパスがそのままの形で表示されるようになった。以前は Windows のパス解決処理がそのようなフォルダ名を URL と誤認識し、機密情報保護のために [redacted URL] というマスク文字列に置き換えて表示していた。

ユーザーへの恩恵

ユーザーはエラーメッセージから実際のパスを直接読み取れるようになり、@ 付きフォルダ名が原因の問題を調査・解決しやすくなる。

変更前

permission_denials に拒否されたツール名を文字列として並べる。

変更後

permission_denials に、Read、Edit、Write の各ツール呼び出しの拒否結果を 1 件 1 つのオブジェクトとして並べ、tool、input、permission_mode、permission_suggestions、created_at の 5 つのフィールドを持たせる。

ユーザーへの恩恵

permission_denials を解析するスクリプトや jq フィルタが、拒否ツールの特定から入力の再現、モード別の集計、候補提示の判断まで一貫して機械的に処理できる。

変更前

tee が書き込むファイルに対しても Edit() の deny ルールと書き込みパスのチェックが適用されるようになった。Bash(tee:*) の allow ルールは作業ディレクトリ外の宛先をカバーしなくなり、宛先がルールの対象になる。

変更後

Bash の tee コマンドが書き込むファイルに対して、Edit() の deny ルールと書き込みパスのチェックが適用されない状態だった。tee コマンドの実行可否だけが判定され、出力先ファイルの内容は確認されていなかった。

ユーザーへの恩恵

Bash(tee:*) を許可しても、許可されていないファイルパスへの tee による書き込みが拒否されるため、Edit deny ルールと同等の保護が Bash 経由の書き込みにも効くようになる。

変更前

Freeプランのユーザーがclaude.ai/codeを開くと、「組織の管理者によって無効化されています」と表示され、利用できない理由や次のアクションが示されないページに遷移していた。

変更後

Freeプランのユーザーがclaude.ai/codeを開くと、アップグレードへの導線があるプラン選択ページが表示される。

ユーザーへの恩恵

FreeプランのユーザーがClaude Code on the webを使いたい場合に、その場でアップグレード方法を確認して導入へ進めるようになる。

変更前

シンボリックリンクで示されるディレクトリ（macOS の /etc・/tmp・/var、Linux の /bin など）に対する deny ルールと ask ルールが、実体のパスでアクセスされた場合には適用されず、拒否や確認をすべき操作が素通りする可能性があった。また、Bash コマンドではシンボリックリンク経由のパスで記述された deny ルールが無視されていた。

変更後

拒否ルールと確認要求ルールがシンボリックリンクのパスの綴りに基づいて評価されるようになり、実体のパス（/etc、macOS の /tmp・/var、Linux の /bin など）でアクセスされた場合でもルールが適用されるようになった。Bash コマンドもシンボリックリンク経由で記述されたパスのルールを無視しなくなった。

ユーザーへの恩恵

ユーザーはシンボリックリンクのパスの綴りにかかわらず、保護対象ディレクトリへの操作が確実に拒否・確認対象になることを信頼できる。

変更前

ディレクトリ名が「..」で始まるプラグインパスを claude plugin validate に渡すと、実際にはプラグインローダーが受け入れるにもかかわらず、検証が誤って拒否していた。

変更後

「..example-plugin」のようにディレクトリ名が2つのドットで始まるパスでも、claude plugin validate が有効なプラグインとして正しく検証して通すようになった。

ユーザーへの恩恵

「..」から始まるディレクトリ名のプラグインでも、検証で不当に拒否されずにすむ。

変更前

ファイルシステム分離が無効でも、パス一覧などのファイルシステム分離に関する制約が適用されているかのような指示を出していた

変更後

ファイルシステム分離が無効のときは、実効性のないパス一覧を含めず、ネットワーク分離のみが適用される旨を明示する

ユーザーへの恩恵

設定と実際の分離動作の差異に戸惑わず、ファイルシステム分離が無効な場合のサンドボックスの振る舞いを正しく理解できる

変更前

バックスラッシュを含むマーケットプレイスのエントリーパスが、macOSおよびLinuxにおいて、フィッシュされたマーケットプレイスの境界チェックをバイパスする可能性がありました。パス検証の際にパスが正規化されておらず、チェックが不完全でした。

変更後

パスの正規化が導入され、バックスラッシュを含むエントリーパスが境界チェックの対象として正しく評価されるようになりました。その結果、フィッシュされたマーケットプレイスの境界チェックをバイパスすることができなくなりました。

ユーザーへの恩恵

ユーザーは悪意のあるまたは不正なマーケットプレイスのパスがフィッシュされたマーケットプレイスの境界外に存在することを確信できます。

変更前

VSCode 拡張機能では、@-mentionでファイルを参照する際、パスにスペースが含まれるとそのファイルが認識されず、@-mentionの対象から外れていた。

変更後

VSCode 拡張機能では、@-mentionでファイルを参照する際、パスにスペースが含まれるとそのファイルが認識されず、@-mentionの対象から外れていた。この修正により、パスにスペースが含まれるファイルも正しく@-mentionで参照できるようになった。

ユーザーへの恩恵

パスにスペースを含むファイルでも @-mention で確実に参照できるようになり、VSCode でのファイル指定が安心して行えるようになった。

変更前

macOS や Linux で、バックスラッシュを含むプラグインのパスがシンボリックリンクの包含チェックをすり抜けていた。パスの区切り文字の違いにより、プラグインディレクトリ外のファイルを参照するパスが許可されていた。

変更後

パスに含まれるバックスラッシュ(Windows で利用される区切り文字)を考慮してシンボリックリンクの包含チェックが行われ、macOS や Linux 上でもバックスラッシュを含むプラグインのパスがチェックをすり抜けなくなった。

ユーザーへの恩恵

macOS や Linux でも、バックスラッシュを含むパスを使ったプラグインディレクトリ外への参照を防止できるようになり、プラグインの読み込みがより安全になる。

変更前

Claude in Chrome の file_upload ツールをローカル Cowork セッションから呼び出すと、paths パラメーターが undefined として渡り、MCP の入力検証で 'paths: expected array, received undefined' エラーになっていた

変更後

Claude in Chrome の file_upload ツールをローカル Cowork セッションから呼び出すと、paths パラメーターが undefined として渡り、MCP の入力検証で 'paths: expected array, received undefined' エラーになっていた

ユーザーへの恩恵

ユーザーはローカル Cowork セッションでもファイル添付入力を代わりに提供しなくてよくなる

変更前

Read/Edit/Writeの権限ルールのパスに括弧が含まれていると、Bashサンドボックスがそのルールを無効なものとして破棄するか無視していました。その結果、「読み取り専用」のはずのフォルダが書き込み可能なまま残っていました。

変更後

Read/Edit/Write権限ルールでパスに括弧が含まれるものは、Bashサンドボックスによって無効なルールとして破棄または無視されていました。そのため、サンドボックス設定で「読み取り専用」にしたはずのフォルダに実際には書き込みが可能なままになっていました。修正後は括弧を含むパスの権限ルールも正しく認識され、サンドボックスがそれに従って読み取り専用フォルダへの書き込みをブロックします。

ユーザーへの恩恵

サンドボックスの権限ルールに括弧を含むパスを指定しても、読み取り専用フォルダへの意図しない書き込みが起こらなくなる。

変更前

ファイル権限ルールにコンパイル不能なパターン(例:閉じられていない [)が含まれていると、正規表現のコンパイルに失敗し、すべてのファイル編集が Invalid regular expression エラーで失敗していた

変更後

コンパイル不能なパターンを含む拒否ルールは、そのルールが本来守るべきリテラルパスに対してのみ機能するようになる

ユーザーへの恩恵

1つの無効なパターンが原因で他の正常なファイル編集まで失敗することがなくなり、意図したパスのみを確実に保護できる

変更前

Claude Desktop などのホストアプリが URL マーケットプレイスをディレクトリとして保存している場合、そこからプラグインをインストールしようとすると 「marketplace entry path does not stay inside the marketplace directory」 というエラーで失敗していました。

変更後

URL マーケットプレイスから追加したプラグインを、ホストアプリがマーケットプレイスをディレクトリとして保存している場合でもインストールできるようになりました。これまで 「marketplace entry path does not stay inside the marketplace directory」 というエラーでインストールに失敗していました。

ユーザーへの恩恵

ホストアプリ経由でディレクトリとして保存された URL マーケットプレイスのプラグインも、エラーなくインストールできるようになります。

変更前

Glob/Grep では、権限チェックの前に検索パスをディスク上でプローブしていたため、権限が許可されるかどうかが決まる前に「パスが存在しない」ことがユーザーに報告されていた。Read ツールとは異なるタイミングでのエラー報告になっていた。

変更後

変更前は、Glob/Grepが権限チェックよりも先に検索パスをディスク上でプローブ(存在確認)しており、パスが存在しない場合には権限確認の前にエラーが報告されていた。変更後は、Read ツールと同様に、まず権限チェックが行われ、その判断の後にパスの不在が報告される。

ユーザーへの恩恵

Read と同様の順序で権限チェックが先に行われるため、権限承認の判断が情報漏えいに使われることがなくなり、ツール間で一貫した安全な動作になる。

変更前

Edit(C:dir(name)**) のようなルールを設定に書くと、エラーメッセージでは ( がエスケープされた括弧として解釈されていた。そのためパス区切りの意図と食い違い、ユーザーはエラーの原因を誤解しやすい状態だった

変更後

Edit などのルールで (name) のように書かれたパスは、( がエスケープされた括弧ではなくパス区切りとして正しく扱われるようになる

ユーザーへの恩恵

明確な書き方の提案が示されることで、パス区切りとエスケープされた括弧のどちらを意図しているかを区別できるようになる

変更前

プラグインは宣言されたコマンドやスキルなどのパスを通じて、自身のディレクトリ外のファイルにアクセスできていました。特にシンボリックリンクを経由するパスでは、意図せず外部のファイルシステムにアクセスしてしまう可能性がありました。

変更後

プラグインが宣言したコマンドやスキルなどのパスを通じて、自身のディレクトリ外のファイルにアクセスできなくなりました。シンボリックリンクを含むパスは、セキュリティ上の理由からエラーとして拒否されます。

ユーザーへの恩恵

プラグインが意図せず外部のファイルシステムにアクセスするリスクが排除され、プラグインの隔離性とセキュリティが向上します。

変更前

以前は、--add-dir、/add-dir、および additionalDirectories で指定されたディレクトリに対して、ネットワークパス（UNC共有や /net/<host> 自動マウント）も許可されていました。これにより、意図せずネットワーク上のリソースにアクセスしてしまう可能性がありました。

変更後

現在は、これらのオプションでネットワークパスを指定しようとすると、操作を行う前にメッセージを表示して拒否するようになりました。Windows環境では、マップされたドライブレターを使用する必要があります。

ユーザーへの恩恵

意図しないネットワークパスへのアクセスを防ぎ、セキュリティを強化します。

変更前

マーケットプレイスエントリで宣言されたプラグインコマンドがプラグインディレクトリ外を指すことができ、セキュリティリスクがありました。

変更後

プラグインコマンドがプラグインディレクトリ外を指すことを防ぐように修正しました。そのようなパスはパストラバーサルエラーで拒否されます。

ユーザーへの恩恵

プラグインのセキュリティが向上し、悪意のあるパストラバーサル攻撃を防げます。

変更前

シンボリックリンクされた検索パスを経由して到達するファイルに対して、Read(...) 拒否ルールが適用されず、セキュリティリスクがありました。

変更後

シンボリックリンクされた検索パスを経由して到達するファイルに対して、Read(...) 拒否ルールが適用されるように修正しました。これにより、セキュリティリスクが軽減されます。

ユーザーへの恩恵

開発者は、意図しないファイルへのアクセスを防ぐことができます。

変更前

レンダリングされたマークダウン内のターミナルハイパーリンクは、ネットワークパスやオートマウンタパスを指し示す、制御文字を含む、または不可視文字で始まるリンクターゲットでもクリック可能でした。これにより、一部の環境でリンクが正しく機能しない可能性がありました。

変更後

レンダリングされたマークダウン内のターミナルハイパーリンクは、ネットワークパスやオートマウンタパスを指し示す、制御文字を含む、または不可視文字で始まるリンクターゲットは、プレーンテキストとしてレンダリングされるようになりました。

ユーザーへの恩恵

一部の環境でリンクが正しく機能しない問題が解決され、マークダウン内のリンクがより安定して表示されます。

変更前

フックのエラーメッセージに解決されたプラグインパスではなく、リテラルの ${CLAUDE_PLUGIN_ROOT} が表示されていました。

変更後

フックのエラーメッセージに解決されたプラグインパスが正しく表示されるようになりました。

ユーザーへの恩恵

エラーメッセージから正しいパスを確認できるようになります。

変更前

入力したテキストが実際のパスと一致しなくなった後も @ ファイルピッカーが開いたままになっていました。

変更後

入力したテキストが実際のパスと一致しなくなった後も @ ファイルピッカーが開いたままにならないようになりました。

ユーザーへの恩恵

ファイルピッカーが不要な状態で開かなくなります。

変更前

補完トークンまたは作業ディレクトリにヌルバイトが含まれていると、パス補完が失敗していました。

変更後

補完トークンまたは作業ディレクトリにヌルバイトが含まれていても、パス補完が正常に動作するようになりました。

ユーザーへの恩恵

特殊文字を含むパスでも正確に補完できるようになります。

変更前

たとえば my-project と my_project のように、パスに含まれる記号だけが異なる別のフォルダが同一マシン上に存在する場合、セッション履歴の検索パスが部分一致処理により混同され、全く関係のない別ディレクトリの作業履歴が呼び出される問題がありました。

変更後

ディレクトリのパス比較処理が厳密になり、特殊文字や区切り文字を正しく識別して、現在実行しているのと完全に一致する正確なプロジェクトディレクトリのセッションのみを復元するようになります。

ユーザーへの恩恵

名前の似ている別プロジェクトの履歴が誤って混ざり込み、予期しないコンテキストで会話が再開されるのを防げます。

変更前

カレントディレクトリにある実行スクリプトを呼び出すために !./scr まで入力して Tab キーを押すと、自動補完された結果から ./ が消えて単なる script になってしまい、パスが通っていないために実行エラーを引き起こしていました。

変更後

ファイルパス補完が、パスの形式を維持したまま補完を行うように修正され、./ プレフィックスを残した正しい相対ファイルパスとしてプロンプトに補完入力されます。

ユーザーへの恩恵

スクリプト実行パスを補完した後に、わざわざ手動で ./ を先頭に書き直す手間がなくなります。

変更前

リモートセッション中にモバイル端末から画像をアップロードした際、画像の保存先ファイルパス情報が保持されていませんでした。そのため、Claudeが新しく作成するファイルにそれらの画像をコピーして配置することが困難でした。

変更後

モバイル端末からアップロードされた画像にローカルでの保存先ファイルパス情報が自動で付与されるようになります。これにより、Claudeはアップロードされた画像を認識し、自身が生成するファイル構成の中に適切にコピーして配置できます。

ユーザーへの恩恵

リモートセッション中にモバイルからアップロードした画像を、Claudeに指示して作成中のファイルへ手動で配置し直す手間がなくなります。

変更前

4,096 文字以上の URL ではダイアログが空で表示され、権限確認も適切に行えませんでした。

変更後

長い URL でもダイアログが正しく表示され、権限確認の選択肢も見失わなくなります。

ユーザーへの恩恵

複雑な設定や長い URL を扱う MCP サーバーでもストレスなく操作できます。

変更前

複雑すぎる、または処理の重い正規表現パターンで検索を実行した際、プロセスがメモリを大量に消費してフリーズすることがあり、検索マッチ数制限と前後行表示オプションを組み合わせた時に表示される行数が不正確になる問題があった

変更後

負荷の高い検索パターンはメモリが枯渇する前に高速に中断してエラーを返し、検索の最大ヒット数制限と前後の行（Context）表示を同時に指定しても仕様通り正しい行数がターミナルに出力されるようになる

ユーザーへの恩恵

暴走する検索処理によって開発ツール全体がクラッシュするのを防ぎ、正しいコンテキスト情報からコードを素早く探索できるようになる

変更前

Windows 環境下で特定の NT ネームスペース形式のパスを処理する際、事前にユーザーの承認を経ないままファイルアクセスが行われ、ネットワーク共有への不正アクセス等による NTLM 認証情報漏洩のセキュリティリスクが潜在していました。

変更後

Windows の NT ネームスペース（\??\）を含む不審なパスを用いた操作が検出された時点で強制的に拒否され、事前承認前のアカウント情報の漏洩を防ぐ強固なガードレールが適用されます。

ユーザーへの恩恵

悪意あるリポジトリやファイル構成による Windows 特有の資格情報奪取攻撃を回避するための、複雑なセキュリティ設定を個別に施す必要がなくなります。

変更前

Amazon Bedrock や Google Cloud、サードパーティ製プロキシなどを経由した非ストリーミング接続時に、API レスポンスのJSON構造内に特定のフィールドが抜けていると、エラーハンドリングが追いつかずツール全体がクラッシュしていました。

変更後

レスポンス内の thinking や text フィールドが空、あるいはオブジェクト構造として不完全な場合でも、パースエラーを起こさずに堅牢にフォールバック処理を行います。

ユーザーへの恩恵

サードパーティ製プロキシや自社構築のLLMゲートウェイを利用している開発者が、特定の応答パターンでツール自体が突然異常終了する現象に悩まされることがなくなります。

変更前

AI が実行を完了するまでは追加の作業ディレクトリパスを指定したり、ヘルプダイアログやテーマカラー設定を変更するコマンドを入力することができず、並行して別のワークスペースに権限を与えるなどの柔軟な割り込み操作ができませんでした。

変更後

フルスクリーン描画レイヤーが強化され、AI の出力を画面の奥に維持したまま、手前に重ねて安全に設定ダイアログを表示・編集して、現在の処理中のタスクに即座に新しいディレクトリコンテキストを適用できます。

ユーザーへの恩恵

AIが作業中に「別のフォルダにあるリファレンスコードも読んでほしい」と言い出した際、今の対話を中断したり終了させたりせずに、その場でフォルダを追加するだけで済むようになります。

変更前

特定の NT ネームスペースパス表現を使用することで、本来なら検証によりブロックされるはずの外部ネットワーク共有（UNC）パスがセキュリティ検証をすり抜けてしまい、Windows の NTLM 認証情報が外部に漏洩する潜在的な危険性がありました。

変更後

すべての形式のパス記述において UNC パスおよびネットワークロケーションの検証が厳密に行われ、危険なバイパスが確実にブロックされます。

ユーザーへの恩恵

悪意あるファイル構造やパス操作による Windows ネットワーク認証情報の盗難リスクを気にすることなく安全に作業できます。

変更前

GitLabトークン（glrt-やglpat-など）がコマンドの出力やファイル読み込みを通じて、意図せず外部ツールやログに平文のまま露出するリスクがありました。

変更後

サンドボックスで実行されるコマンドに対して、GitLabトークンを検知して自動的にダミー値へマスク処理（redaction）を行い、glabの設定ファイルへの不正な書き込みも遮断します。

ユーザーへの恩恵

GitLab連携コマンドをサンドボックス内で実行する際に、プライベートトークンが不正に読み取られて外部に流出する心配がなくなります。

変更前

Git Bashで使用される一部のシンボリックリンクファイルが、Claudeのパス検証エンジンによって「通常の静的ファイル」と誤判定され、書き込み禁止領域へのリンクであっても直接編集が通ってしまう問題がありました。

変更後

リンクパスの解決処理が修正され、Cygwinスタイルのシンボリックリンクを指す書き込み操作であっても、適切にパーミッション承認プロンプトを介入させます。

ユーザーへの恩恵

Windows上のGitリポジトリ内でシンボリックリンクを経由したファイル改ざんや、システムファイルの不正上書きが防止されます。

変更前

モデルが誤って非文字列の値を引数に指定してツールを呼び出すと、アプリケーション全体が即座にクラッシュし、該当セッションの再開すらできなくなっていました。

変更後

無効な引数型が渡された場合でも、クラッシュを回避してエラーを適切にハンドリングし、セッションの復旧も可能になります。

ユーザーへの恩恵

予期せぬ引数のエラーによって、それまでの対話履歴や進行中のセッションが失われる事態を回避できます。

変更前

Windows 特有の長いパス表現や共有ネットワークフォルダーのパスが含まれていると、パス解析や隔離環境のチェックに失敗してプログラムが強制終了していました。

変更後

拡張長パスやネットワーク上の UNC パスが指定されても、Windows 側でのパスハンドリングが正常に処理されクラッシュしなくなります。

ユーザーへの恩恵

ファイルパスの記述制限を意識することなく、Windows のネットワーク共有上にあるリソースに対してツールを実行できるようになります。

変更前

プロジェクトの絶対パスが非常に長い（200文字超）場合、セッションディレクトリを解決するための内部的な一意名（サニタイズされたプレフィックス）が同一になってしまい、別のプロジェクトの会話履歴やセッションを誤って操作したり、呼び出して再開したりしてしまう可能性がありました。

変更後

パスプレフィックスの衝突処理が改善され、ディレクトリパスがどれだけ長くても別のプロジェクトと確実に識別されるようになります。これにより、セッション履歴の復元や削除が他の無関係なプロジェクトと干渉しなくなります。

ユーザーへの恩恵

深いディレクトリ階層や長いリポジトリパスを使用している開発環境でも、プロジェクト間でセッションデータが混ざることなく安全に履歴の管理を行えます。

変更前

スキルパスの指定が制限されており、定義ミス時の修正が直感的ではありませんでした。

変更後

プラグインルートをスキルパスとして指定可能にし、エラーメッセージで適切な配置を推奨するようにしました。

ユーザーへの恩恵

プラグイン作成時のスキル配置ミスによるエラーを即座に修正できるようになります。

変更前

Git Bashのパス設定が不適切な場合にプロセスが終了してしまうことがあり、ツールが突然利用できなくなる問題がありました。

変更後

不正なパスが検出された場合は無視され、警告メッセージを表示する挙動に変更されました。

ユーザーへの恩恵

設定ミスによってツールが即座にクラッシュすることを避け、適切なエラーメッセージを見て修正を行えます。

変更前

API連携スキルにおいて古いOpus 4.8がデフォルト設定となっており、最新モデルを利用するために手動での変更が必要でした。

変更後

最新のOpus 5が標準となり、必要に応じてスムーズに移行が行える構成になりました。

ユーザーへの恩恵

モデルを手動で書き換えることなく、標準設定のままで最新の高度な推論機能を利用できます。

変更前

Windowsのユーザーパスなどが正しく認識されず、ファイルへのアクセスがブロックされていました。

変更後

パスが正しく解釈されるようになり、該当するファイルへ確実にアクセスできるようになりました。

ユーザーへの恩恵

Windows環境で特定のファイルパスが読み込めずエラーになる事態を防げます。

変更前

エラー発生時に同じリクエストを再試行し続け、セッションが進行不能に陥っていました。

変更後

リクエスト失敗時の挙動が整理され、無駄な再試行が行われなくなりました。

ユーザーへの恩恵

システムエラー発生時にセッションがフリーズせず、継続的に作業を行えます。

変更前

頻繁に確認プロンプトが表示され、自動モードとしての継続的な実行が阻害されていました。

変更後

自動化された安全フィルターが操作を適切に判断し、不要なプロンプトが削減されました。

ユーザーへの恩恵

中断されることなく、連続的なタスク処理を自動化しやすくなります。

変更前

複雑なブレース展開がメモリを過剰消費し、スタートアップ時にCLIが停止していました。

変更後

ブレース展開の予算上限を設定し、過負荷を防止するようにしました。

ユーザーへの恩恵

設定ファイルが複雑になっても、起動時にCLIが固まるリスクを減らせます。

変更前

リンクを辿ってしまい、誤ってリンク先のシステムファイルや別の領域のファイルを変更してしまうリスクがありました。

変更後

リンクをスキップし、対象外のパスがいくつあったかを明示するように安全策が強化されました。

ユーザーへの恩恵

巻き戻し操作を行っても、予期せぬ場所のファイルが変更されるリスクから保護されます。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

shell-config関連のパス設定がディレクトリである場合に、診断ツールがハングしたり表示が消えるバグがありました。

変更後

パスの型がディレクトリであっても、診断処理が正常に継続するように修正されました。

ユーザーへの恩恵

環境設定のパス構成に関わらず、診断ツールが確実に実行できるようになります。

変更前

ポップアップが表示されるとシェル入力がブロックされ、コマンドを実行できませんでした。

変更後

ポップアップの状態に関わらずコマンド実行が正常に機能します。

ユーザーへの恩恵

パス補完を使ってファイル名を指定した直後に、そのままコマンドを実行できるようになります。

変更前

長いパスが原因でUIが崩れ、操作ガイドが読み取りにくい状態でした。

変更後

テキストが適切に配置され、操作ガイドが崩れずに表示されるようになりました。

ユーザーへの恩恵

UIのレイアウト崩れに惑わされず、迷いなくプラン修正を行えます。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

スクリーンショットツールの save_to_disk オプションを指定しても、実際にはファイルが書き出されず何も行われない状態だった

変更後

指定した画像が正しくディスクに保存され、Claude がその保存先のファイルパスを認識できるようになる

ユーザーへの恩恵

ブラウザ上のエラースクリーンショットなどを自動でローカルに保存し、そのまま後続の解析に利用できる

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

設定ファイル内で[a-z]のようなパターンを記述する際に形式が不適切だと、ファイル検索やワークツリーへのファイルコピーが予期せず失敗したり、不完全な結果になったりすることがありました。

変更後

パターンの解析処理が堅牢になり、多少の記述の不備があっても致命的なエラーを避け、正しくファイルが読み込まれるようになりました。

ユーザーへの恩恵

ファイルの除外設定やスキル定義が意図通りに機能するようになり、リポジトリ構成の不整合によるエラーに悩まされることがなくなります。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

ディレクトリの状態異常時にプロセスが無限ループし、CPUを消費し続けていました。

変更後

異常検知時に1度だけ明確なエラーを表示して停止するようになりました。

ユーザーへの恩恵

リソースの浪費を防ぎ、トラブルの原因が特定しやすくなります。

変更前

ファイルパスの解決方法によって、適用されるべきコーディングルールが無視されていました。

変更後

シンボリックリンク解決後も正しくパスを認識し、適切なルールが適用されるようになりました。

ユーザーへの恩恵

複雑なプロジェクト構造や共有リンクを使用している場合でも、統一されたコーディングスタイルを維持できます。

変更前

セッション移動後に異常終了すると、旧ディレクトリの履歴にセッションが残り続ける問題がありました。

変更後

セッション移動が正しく処理され、ディレクトリ間の履歴整合性が維持されます。

ユーザーへの恩恵

セッションの再開時に、混乱なく正しいディレクトリから作業を継続できます。

変更前

特定の設定ファイルで有効化されたプラグインが、パスごとに不必要にインストール同意を求めていました。

変更後

ローダーパスに関わらず、適切な権限管理下で動作するように修正されました。

ユーザーへの恩恵

プラグイン導入時の手間が削減され、スムーズに作業を開始できるようになります。

変更前

シェルモード(!)でコマンドを入力する際、ファイルパスの自動補完が効かず、長いパスを手動で入力する必要がありました。

変更後

通常のプロンプトと同様に、シェルモードでも入力中に適切なファイルパスが提案され、Tabキーなどで補完できるようになります。

ユーザーへの恩恵

ターミナルでの直接的なコマンド実行がよりスムーズになり、入力ミスを減らしながら作業効率を向上させることができます。

変更前

claude agentsのジョブ一覧で、貼り付けた画像のパスがそのまま表示されており、画面が煩雑で見にくい状態でした。

変更後

画像データが簡潔なプレースホルダー「[Image #N]」に置き換わるようになりました。

ユーザーへの恩恵

背景で実行中のエージェントの状態を一覧で確認する際、視認性が向上し、重要な情報に集中しやすくなります。

変更前

ツールパスを指定するフックの条件式で、ワイルドカードや特定のファイル名へのマッチングが正しく動作しないケースがありました。

変更後

ドキュメントに記載されているような glob パターンを用いたパス指定が、意図通りにフックをトリガーします。

ユーザーへの恩恵

「特定のディレクトリ以下の編集時のみ Linter を走らせる」といった、精度の高い自動化ワークフローが確実に動作します。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

一時ディレクトリのパスが長すぎると、一部のツールが内部で使用する通信用ソケットの作成に失敗し、ツールが正常に動かないことがありました。

変更後

パスの長さに依存しない堅牢なソケット管理が行われるようになり、カスタムの一時ディレクトリ設定下でも安定して動作します。

ユーザーへの恩恵

企業のセキュリティポリシーなどで一時ファイルの作成場所を厳格に指定している環境でも、エラーに悩まされることなくツールを利用できるようになります。

変更前

リンク機能をサポートするターミナルで表示されるファイルパスが誤って加工され、クリックしてもファイルを開けない場合がありました。

変更後

Windows特有のファイルパス形式のハンドリングが修正され、クリック可能なハイパーリンクが常に正しく機能します。

ユーザーへの恩恵

ログや回答内のファイルパスからエディタへ、ワンクリックで確実にジャンプできるようになります。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

長期利用により蓄積された履歴を読み込む際、メモリを食いつぶしてCLIがクラッシュしたり動作が極端に重くなったりしていました。

変更後

リソース管理が最適化され、履歴の量に関わらずスムーズに過去の作業を再開できます。

ユーザーへの恩恵

スペックの低いマシンでも長期間安定して Claude Code を使い続けることができます。

変更前

AIが生成したファイル(ビルド成果物など)が、保存したはずなのに見つからないという混乱が生じていました。

変更後

出力先が正しく管理され、意図した場所にファイルが確実に書き込まれるようになります。

ユーザーへの恩恵

AIが作成したファイルが見失われることがなくなり、作業結果の信頼性が向上します。

変更前

OpenTelemetryの設定でスペースを含むパスのスクリプトを指定すると、エラーが表示されずに機能だけが停止するため、原因の特定が困難でした。

変更後

パスにスペースが含まれていても正しく実行されるようになり、万が一エラーが発生した際も/doctorコマンドで診断結果が表示されます。

ユーザーへの恩恵

監視設定のトラブルシューティングが容易になり、不具合に気づかないまま運用してしまうリスクを軽減できます。

変更前

プラグインの詳細画面で、実際の数よりも多くのスキルやエージェントが存在するように表示されることがあり、混乱を招いていました。

変更後

重複排除が正しく行われ、プラグインの内容が正確な数値で表示されるようになります。

ユーザーへの恩恵

インストールしている拡張機能の状態を正確に把握でき、管理がしやすくなります。

変更前

Homebrew 等でツールをアップデートした際、バックグラウンドで動作中のエージェントが削除済みの古いパスを参照し続け、クラッシュと再起動を繰り返すことがありました。

変更後

アップデート後のデーモン終了処理が改善され、実行中のエージェントが新しいパスへ適切に移行できるようになりました。

ユーザーへの恩恵

ツール本体を更新しても進行中のバックグラウンドタスクが中断されず、長時間かかる作業を安心して任せられます。

変更前

カレントディレクトリをスキルの参照先として指定すると、プラグインディレクトリ外への不正アクセスとして誤認され、エラーが発生する場合がありました。

変更後

ルートパス指定の検証ロジックが修正され、適切なスキル読み込みが可能になりました。

ユーザーへの恩恵

プラグイン開発時のディレクトリ構成の自由度が高まり、構成エラーに悩まされることがなくなります。

変更前

claude agentsを実行すると、すべてのプロジェクトのセッションが混在して表示されるため、特定のプロジェクトに関連するセッションを見つけるのが不便な場合がありました。

変更後

--cwdフラグでパスを指定することで、そのディレクトリに関連するバックグラウンドセッションのみをフィルタリングしてダッシュボードに表示できます。

ユーザーへの恩恵

大規模な開発環境で複数のプロジェクトを並行して進めている際に、作業中のリポジトリに集中してエージェントの状態を管理できます。

変更前

EnterWorktreeイベントで作業ディレクトリが移動した後、フックに渡されるセッション履歴ファイルへのパスが古いままで、実在しないファイルを指すことがありました。

変更後

ディレクトリ移動後も、最新の正しいtranscript_pathがフックの入力JSONに反映されるようになります。

ユーザーへの恩恵

作業の自動化スクリプトや監視フックが、ワークツリー環境下でも途切れることなく確実に会話履歴へアクセスできるようになります。

変更前

フックにファイルパスを渡す際、名前にスペースが含まれているとシェルで適切にパースされず、煩雑なエスケープやクオート処理が必要でした。

変更後

args配列形式で指定することでOSが直接引数を渡すため、パスにスペースがあっても安全かつ確実にコマンドを実行できます。

ユーザーへの恩恵

フック設定の記述がシンプルになり、パス操作に起因する予期せぬ実行エラーやセキュリティリスクを排除できます。

変更前

パスに特殊文字が含まれるディレクトリでセッションを管理する際、IDの照合に失敗して過去の会話履歴を読み込むことができませんでした。

変更後

セッションのパス解決ロジックが修正され、アンダースコアを含むディレクトリ名でも確実に過去のセッションを特定・再開できるようになりました。

ユーザーへの恩恵

ディレクトリ名の命名規則に関わらず、いつでも確実に前回の続きから作業を再開できます。

変更前

プラグイン設定の記述方法によって意図せずスキルが読み込まれなかったり、指定ミスがあってもエラーが出ずに無反応だったりするため、デバッグが困難でした。

変更後

スキルの自動検出ロジックが整理され、設定ミスがある場合にはサイレントに失敗するのではなく、明確なエラーメッセージが表示されるようになりました。

ユーザーへの恩恵

プラグイン開発時のミスに気づきやすくなり、カスタムスキルの導入がより確実になります。

変更前

設定ファイルの記述が間違っている際に、どのファイルのどの項目が原因でエラーになっているのか情報が不足しており、修正が困難でした。

変更後

詳細な診断レポートが出力されるようになり、問題が発生しているファイル名と特定のフィールド名が明示されるようになりました。

ユーザーへの恩恵

設定の誤りを即座に特定して修正できるため、環境構築の手間を減らせます。

変更前

Windows環境でVS Code拡張機能を使用しようとすると、SDK内のパス指定が適切でないために読み込みに失敗し、拡張機能が正常に起動しないことがありました。

変更後

パスの解決方法が修正され、Windowsユーザーも問題なくVS CodeのネイティブなグラフィカルインターフェースからClaude Codeを利用できるようになりました。

ユーザーへの恩恵

セットアップ時のトラブルが解消され、Windowsの開発環境でもVS Code上でのインライン編集やプラン作成などの便利な機能をすぐに使い始めることができます。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

特定のプロジェクトに関する会話履歴やタスク、ファイル変更のチェックポイントなどの状態をまとめて削除する専用のコマンドがありませんでした。

変更後

claude project purgeにより、特定のパスまたは全プロジェクトの状態を一括でクリーンアップできるようになりました。ドライランやインタラクティブモードもサポートしています。

ユーザーへの恩恵

不要になった古い会話データや一時的なタスク情報を安全かつ確実に消去し、プライバシーの保護やディスク容量の節約を簡単に行えます。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

自動更新は DISABLE_AUTOUPDATER でオフにできましたが、手動コマンドによる更新を完全に制限することはできず、特定のバージョンを厳格に固定したいエンタープライズ環境などで意図しない更新が防げない可能性がありました。

変更後

DISABLE_UPDATES を設定することで、バックグラウンドでの自動チェックだけでなく、明示的な手動更新コマンドも拒否されるようになり、管理者が承認した特定のバージョンを確実に使い続けることができます。

ユーザーへの恩恵

企業のIT管理者は、検証済みの安定版からユーザーが勝手にアップデートすることを防げるため、開発チーム全体でツールの一貫性とセキュリティを保証しやすくなります。

変更前

フルパスでのファイル参照を入力しようとした際、コマンドの自動補完機能が誤ってコマンドとして解釈し、エラーを出すことがありました。

変更後

ファイルパスの入力を正しく認識し、コマンドと混同しないように改善されました。

ユーザーへの恩恵

ファイルパスのコピペがスムーズになり、AI への指示出しがより快適になります。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

カスタム設定ディレクトリを使用している場合にパス表示が正しくなかったり、再設定時に以前選択したモデルが引き継がれず、設定の手間が大きくなっていました。

変更後

設定ウィザードが現在の環境をより正確に反映し、大規模なコードベースに必要な1Mコンテキストの有効化も簡単に行えるようになりました。

ユーザーへの恩恵

クラウドプロバイダー経由での利用開始や設定変更がより迅速かつ確実になり、特に大規模プロジェクトでのセットアップが楽になります。

変更前

「C:\」と「c:\」が別々の場所として誤認され、パーミッション設定が正しく適用されない、あるいはファイルの状態が不整合になるリスクがありました。

変更後

Windows固有のパス形式が厳密に処理され、権限チェックの信頼性が向上しました。

ユーザーへの恩恵

Windows環境での意図しない権限エラーが解消され、パーミッション設定が常に期待通りに機能するようになります。

変更前

ワークツリー機能を利用する際、既に存在するワークツリーディレクトリへの直接的な切り替えや再利用が容易ではありませんでした。

変更後

EnterWorktreeツールでpathパラメータを指定できるようになり、既存のワークツリーへの移動がスムーズに行えるようになりました。

ユーザーへの恩恵

複数の作業ブランチをワークツリーで並行管理している場合に、既存の環境を即座に再利用できるため、作業の切り替えが高速化されます。

変更前

過去のセッションを再開する際、一部のツール実行結果に特定のデータが不足していると、ツール自体が異常終了してしまうケースがありました。

変更後

不完全な履歴データがある場合でも、適切にエラーを回避してセッションを復元できるようになります。

ユーザーへの恩恵

予期せぬエラーによるセッションの消失を防ぎ、安定して過去の作業を継続できます。

変更前

VS Code拡張機能の自動更新後などに、内蔵の検索エンジンの場所が見失われ、コード検索が一時的に利用できなくなることがありました。

変更後

エラーを検知するとシステム側の rg コマンドへの切り替えを自動で行い、セッション中に自己修復します。

ユーザーへの恩恵

ツールの内部的な整合性を気にすることなく、常に安定したコード検索機能を利用できます。

変更前

全許可モードで実行している際でも、特定の警告を承認した拍子に「毎回確認を求めるモード」へ意図せず設定が戻ってしまう挙動がありました。

変更後

承認フラグの状態が正しく維持され、一度設定した実行モードが勝手に変わることはありません。

ユーザーへの恩恵

自動化されたスクリプト実行中に、予期せぬ確認プロンプトによって処理が止まってしまうのを防ぐことができます。

変更前

特定のフォルダに保存しようとしても、意図しない場所に意図しない名前で保存されてしまうことがありました。

変更後

指定したパスとファイル名が正確に使用され、マークダウン形式(.md)など好みの形式でエクスポートできるようになりました。

ユーザーへの恩恵

AIとの対話記録を、ドキュメント作成や共有のために思い通りの場所に整理して保存できます。

変更前

全承認モード(Bypass permissions)で実行していても、セキュリティ上保護されたディレクトリへの書き込みで一度許可を出すと、以降の操作で再度確認が求められるモードに勝手に切り替わってしまう挙動がありました。

変更後

保護されたパスへの個別承認後も、元の「全承認モード」が正しく維持されるようになりました。

ユーザーへの恩恵

信頼できる隔離環境などで自動化スクリプトを実行する際、意図しない対話プロンプトによる中断が発生しなくなります。

変更前

許可ルールの判定時にパスを解決し、リンク先の実パスも含めて //path/** などのパターンに一致するかを検証するようになったため、シンボリックリンク経由であっても許可パターンの範囲外のパスへのアクセスは許可されなくなった。

変更後

シンボリックリンクを // や / で始まるパスパターン(Edit(//path/**) や Read(//path/**))で許可したとき、要求されたパスそのものだけを見て許可を判断していたため、リンク先が許可ディレクトリの外でも要求パスがパターンに一致すればアクセスが許可される状態だった。

ユーザーへの恩恵

シンボリックリンクを使ったパスの偽装による意図しないファイルアクセスを防ぎ、許可ルールをより正確に信頼して設定できるようになった。

変更前

Write/Edit/Read ツール実行時、PreToolUse/PostToolUse フックに渡される file_path が相対パスになることがあり、フックスクリプト側でパス判定が正しく動かないケースがあった。

変更後

Write/Edit/Read ツール実行時、PreToolUse/PostToolUse フックの入力の file_path が絶対パスとして渡されるようになった。

ユーザーへの恩恵

拡張後の file_path を前提にして書かれた公式ドキュメントやガイドのフックスクリプトが、意図どおりに動くようになる。

変更前

10,000文字を超えるフック出力は、その全文がコンテキストに直接注入されていた

変更後

10,000文字を超えるフック出力はコンテキストに直接注入されず、ディスクに保存され、そのファイルパスと2,000文字のプレビューだけが渡される

ユーザーへの恩恵

巨大なフック出力がコンテキストを圧迫しなくなり、Claudeが必要な部分だけをファイルから読み取れるようになる

変更前

フック機能でファイルの変更を監視・処理する際、ファイルパスが相対パスで渡されることがあり、実行ディレクトリが異なると正しいファイルを特定できないリスクがありました。

変更後

常にルートからの絶対パスが渡されるようになり、どのディレクトリから実行しても確実に対象ファイルを処理できるようになりました。

ユーザーへの恩恵

自動フォーマットやバリデーションなどのフックの信頼性が高まり、複雑なプロジェクト構造でも誤作動の心配なく自動化を任せられます。

変更前

WorktreeCreate フックをHTTP経由で実行した際、フックによって作成されたgitワークツリーのパスをClaude Code側に正確に伝える標準的な方法がありませんでした。

変更後

HTTPフックのレスポンスJSON内の hookSpecificOutput.worktreePath フィールドを通じて、作成されたパスを返せるようになりました。

ユーザーへの恩恵

独自のサーバーで管理している複雑なワークツリー作成フローをClaude Codeとシームレスに統合でき、並行作業の自動化がより強固になります。

変更前

スキルの適用範囲やプロジェクトルールを特定のパスに制限する paths: フィールドにおいて、単一のパターンしか記述できない、またはリスト形式の処理が不十分な場合がありました。

変更後

YAMLのリスト形式で複数のグロブパターンを指定できるようになり、より柔軟な適用範囲の設定が可能になりました。

ユーザーへの恩恵

フロントエンドとバックエンドの特定ディレクトリなど、関連する複数のパスに対して一つのルールを効率的に適用でき、コンテキストの管理が容易になります。

変更前

バックグラウンドタスクの結果を確認するために専用の TaskOutput ツールを使用していましたが、これは標準的なファイル読み込みツールとは異なる挙動をするため、管理が複雑でした。

変更後

バックグラウンドタスクの出力が通常のファイルとして扱えるようになり、実績のある Read ツールで透過的にアクセスできるようになりました。

ユーザーへの恩恵

Claude がより一貫した方法でタスク結果を分析できるようになり、実行結果の取得や加工の精度が向上します。

変更前

コンテナ環境などでプラグインを事前配置するためのシードディレクトリは1つしか指定できませんでした。

変更後

Unix系では :、Windowsでは ; を使うことで、複数のディレクトリからプラグインを読み込めるようになりました。

ユーザーへの恩恵

共通のプラグインセットとプロジェクト固有のセットを組み合わせて配置するなど、環境構築の柔軟性が高まります。

変更前

サンドボックス環境での書き込み許可パスを指定する際、常に // 接頭辞が必要であり、通常の絶対パス指定が機能しませんでした。

変更後

標準的な絶対パスによる指定が可能になり、設定ファイルの記述がより直感的になりました。

ユーザーへの恩恵

環境構築時の設定ミスが減り、サンドボックス機能をより簡単に導入できるようになります。

変更前

チャット履歴のエクスポート完了時にファイル名しか表示されなかったため、実際にどのディレクトリに保存されたかを確認する手間がありました。

変更後

成功メッセージに絶対パスが表示されるようになり、保存場所を一目で確認できるようになりました。

ユーザーへの恩恵

エクスポートしたファイルを他のツールで開いたり共有したりする際のアクションが迅速になります。

変更前

--plugin-dir path1 path2のように指定していましたが、将来的な拡張において曖昧さが生じる可能性がありました。

変更後

--plugin-dir path1 --plugin-dir path2のように、1つのフラグに1つのパスを指定する標準的な形式に統一されました。

ユーザーへの恩恵

CLIの動作が予測可能になり、スクリプトなどでのプラグイン管理がより安全に行えるようになります。

変更前

処理が途中で中断された場合にAPIレスポンスのメモリが適切に解放されず、ツールを使い続けるほどPCのメモリ消費量が増大し続けていました。

変更後

ジェネレーターが終了した際にバッファが確実に解放されるようになり、長時間使用してもメモリ消費が安定するようになります。

ユーザーへの恩恵

大規模な開発作業でも動作が不安定にならず、システムのパフォーマンス低下を気にせずに安心して利用できます。

変更前

レジュームしたセッションで履歴パスが誤っていたり、非同期フックで read -r が動作しないなど、高度なカスタマイズを行うフック機能においていくつかの不安定な挙動がありました。

変更後

セッション管理とフック実行エンジンの修正により、自作の自動化スクリプトがより正確に動作するようになりました。

ユーザーへの恩恵

自作のフックを用いた高度なワークフロー自動化を、予期せぬエラーに悩まされることなく構築できます。

変更前

Windows の Git Bash などを使用している際、パス形式の差異によって Claude が自身のカレントディレクトリを誤認し、既に許可済みのコマンドでも再確認を求めてくることがありました。

変更後

OS ごとのパス形式の差異が吸収され、不要なパーミッション確認が行われなくなりました。

ユーザーへの恩恵

Windows 環境での開発体験が向上し、無意味なプロンプトによる中断がなくなります。

変更前

並行作業のためにGitワークツリー(--worktree)を使用している際、ステータスバーからは現在の作業場所の詳細が分かりませんでした。

変更後

ステータスラインをカスタマイズして、どのワークツリーで作業中かを常に表示できるようになりました。

ユーザーへの恩恵

複数のワークツリーを使い分けている時に、誤った場所で変更を行ってしまうミスを防ぎ、コンテキストの把握を助けます。

変更前

ローカルディレクトリからプラグインを読み込む際、許可された特定のディレクトリ以外からの読み込みを厳格に制限することができませんでした。

変更後

ネットワーク経由のホスト制限だけでなく、ファイルシステム上のパスに基づいた読み込み制限が可能になりました。

ユーザーへの恩恵

管理者側で、社内の標準ディレクトリ以外からのプラグインインストールを禁止するなど、より強力なセキュリティ制御が可能になります。

変更前

Git ワークツリーを使用して並行セッションを実行している際、ステータスバーなどのカスタム表示において、現在のワークツリーに関する詳細情報を表示する直接的な手段がありませんでした。

変更後

ステータスライン構築用の JSON データにワークツリーの詳細が含まれるようになり、現在の作業環境がどのブランチ・どのディレクトリなのかを常に画面下に表示できるようになりました。

ユーザーへの恩恵

複数のワークツリーを使い分けて並行開発を行う際に、自分が今どこで作業しているのかを混同するリスクを大幅に減らせます。

変更前

組織で管理設定(Managed Settings)を導入している場合、特定のディレクトリにあるプラグインのみを許可するといった、ファイルパスに基づいた厳格な制限をかけることができませんでした。

変更後

正規表現によるパスのパターンマッチングが可能になったため、社内の承認済みディレクトリからのみプラグインのインストールを許可するといった運用が可能になりました。

ユーザーへの恩恵

企業利用におけるセキュリティガバナンスが強化され、信頼できない場所からの意図しないコード実行を未然に防ぐことができます。

変更前

オートメモリのデータは常にデフォルトのディレクトリに保存されるため、特定のプロジェクトだけメモリを別の場所に隔離したり、ネットワークドライブなどで共有したりすることが不便でした。

変更後

環境変数一つで保存先を自由に変更できるようになったため、プロジェクトの要件に合わせた柔軟なデータ管理が可能になりました。

ユーザーへの恩恵

メモリデータのバックアップや共有、プロジェクトごとの厳格な分離が容易になり、ワークフローに合わせたデータ管理が実現します。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

CLI を自動化スクリプト等で使用する非対話モードにおいて、プロジェクトの細かいルールやサブディレクトリ内の指示が無視されてしまい、対話モードと同じような賢い挙動が得られないことがありました。

変更後

プリントモードでも対話モードと同様にすべての指示ファイルが正しく探索・ロードされるようになり、一貫したルール適用が保証されるようになりました。

ユーザーへの恩恵

CI/CD などの自動化環境においても、プロジェクト独自のコーディング規約を Claude に確実に守らせることができます。

変更前

作業ディレクトリにシンボリックリンクが含まれる場合、セッションの復旧時に表示されないことがありました。SSH接続中にセッションデータが失われる可能性もありました。

変更後

シンボリックリンクが含まれる作業ディレクトリでもセッションが正しく表示されるようになり、SSH切断時にもセッションデータが失われなくなりました。

ユーザーへの恩恵

セッションの可視性と信頼性が向上し、開発者は中断した作業を確実に再開できるようになります。データ損失のリスクも軽減され、安心して利用できます。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

Windows環境において、ドライブレターの大文字・小文字の表記が異なる場合、同じCLAUDE.mdファイルが二重にロードされてしまう問題がありました。

変更後

Windows環境でドライブレターの大文字・小文字が異なる場合でも、同じCLAUDE.mdファイルが二重にロードされる問題が修正されました。

ユーザーへの恩恵

Windows環境でのCLAUDE.mdファイルのロードが正確になり、ドライブレター表記の違いによる意図しない挙動を防ぎました。これにより、設定の一貫性が保たれます。

変更前

claude CLIツールをプロジェクトのサブディレクトリから実行した際、@を用いたファイル補完機能が誤った相対パスを表示することがありました。これにより、意図したファイルを正確に参照するのが困難になる場合がありました。

変更後

サブディレクトリからの実行時でも、@ファイル補完が常に正しい相対パスを表示するようになりました。これにより、どのディレクトリからコマンドを実行しても、正確なファイル参照が可能になります。

ユーザーへの恩恵

どのディレクトリから作業していても、ファイルの参照がより正確かつスムーズに行えるようになり、特に複雑なプロジェクト構造を持つ環境での開発体験が向上します。誤ったファイルパスによるミスが減り、作業の中断も軽減されます。

変更前

ストリーミングAPIを使用する際、temperatureOverride設定をしても実際には適用されず、常にデフォルトの温度(1)でAIが応答を生成していました。これにより、モデルの創造性や一貫性を意図通りに制御できませんでした。

変更後

ストリーミングAPIリクエストにおいてもtemperatureOverrideが正しく適用されるようになり、ユーザーが設定したモデルの温度(創造性)がストリーミング応答に反映されるようになりました。

ユーザーへの恩恵

ストリーミング生成においても、より細かくモデルの振る舞いを制御できるようになり、ユーザーの意図に沿った創造的な応答や、より一貫性のある応答を期待できるようになりました。

変更前

Windows 環境で、一時ディレクトリのパスに特定の文字が含まれていると、bash コマンドが正しく解釈されずに失敗していました。

変更後

一時ディレクトリのパスに含まれる文字の解釈に関する問題を修正し、Windows 上での bash コマンドの実行安定性を向上させました。

ユーザーへの恩恵

Windows 環境での開発作業において、bash コマンドの実行がより安定し、予期せぬエラーに悩まされることがなくなります。

変更前

ビルドログやテスト結果が極端に長い場合、その全内容が Claude の脳(コンテキスト)に送られ、記憶容量を圧迫したりエラーを引き起こしたりしていました。

変更後

出力が一定量を超えると重要な部分のみを要約・切り詰めし、完全な内容はファイルとして保存して Claude にその場所を教えるようになりました。

ユーザーへの恩恵

大量のログが出るタスクを実行しても Claude が混乱せず、スマートに要点だけを把握して作業を続けられます。

変更前

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

変更後

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

ユーザーへの恩恵

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