Claude Code Hooks

変更前

ハイフンを含む識別子（例: code-reviewer, mcp__brave-search）を使用すると、意図しないサブストリングマッチングが発生していました。

変更後

識別子が完全一致するように変更されました。なお、ハイフンを含むMCPサーバーの全ツールを指定する場合は、「mcp__brave-search__.*」を使用してください。

ユーザーへの恩恵

フックの設定がより直感的かつ正確になり、意図しないフックの起動を防ぐことができます。

変更前

カンマ区切りで複数の条件を指定した場合、条件が正しくパースされず、フックが黙って無視されていました。

変更後

指定した複数の matcher が正しく評価されるようになり、定義したフックが確実に動作します。

ユーザーへの恩恵

フックの設定漏れや予期せぬ動作を回避でき、自動化処理の信頼性が高まります。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

セッション終了時に未コミットの作業をスナップショットとして保存したり、ログを外部へエクスポートしたりするタイミングがありませんでした。

変更後

新設された post-session ホックを利用して、ワークスペースが破棄される直前に必要なデータの退避やログ出力のクリーンアップ処理を自動化できます。

ユーザーへの恩恵

自動実行環境において、エラー発生時の詳細なデバッグ情報の収集や、実行結果の永続化をより確実に行えるようになります。

変更前

特定のプラグインやフックが原因で Claude Code が正常に動作しない場合、原因を特定するために設定ファイルを個別に書き換える必要がありました。

変更後

原因不明の挙動が発生した際、--safe-mode を使うことで純粋な Claude Code の状態で起動し、カスタマイズによる影響かどうかを即座に切り分けられます。

ユーザーへの恩恵

複雑な設定を維持したまま、問題発生時の原因究明を迅速に行えるようになります。

変更前

フックが特定の出力を返すとフックエラーとして処理され、エージェントの動作が意図せず中断されることがありました。

変更後

フックから Claude へ追加の文脈を直接渡せるようになり、エラーを発生させずに処理を継続させることができます。

ユーザーへの恩恵

特定のタスク終了時にカスタムの指示やフィードバックを自動で挿入できるため、より高度な自動化ワークフローが実現します。

変更前

セッション再開時、MCP サーバーが起動時の古いセッション ID を保持し続け、他のツールとの一貫性が失われる場合がありました。

変更後

すべてのサブプロセスが共通の現在のセッション ID を参照できるようになります。

ユーザーへの恩恵

外部ツールやログの相関分析を行う際に、MCP サーバーの動作を正確に現在のセッションに紐付けることができます。

変更前

$() や ` `` の中に含まれる Bash コマンドがフックの条件判定をすり抜けて実行される可能性がありました。

変更後

コマンドのネスト構造を深く解析し、変数展開やサブシェル内の記述も含めて正確にフィルタリングします。

ユーザーへの恩恵

セキュリティやガードレールのためのフック設定がより堅牢になり、意図しないコマンド実行を確実に阻止できます。

変更前

Windows 上で Linux 形式のパスを指定して bash スクリプトを実行しようとすると、パスの解決に失敗してフックが正常に動作しませんでした。

変更後

Windows 環境でも、bash を介したスクリプトの実行が適切にハンドルされるようになりました。

ユーザーへの恩恵

マルチプラットフォームで共有されているプロジェクトにおいて、Windows ユーザーでも共通のフックスクリプトをそのまま利用できるようになります。

変更前

セッション開始時のフックで新しいスキルをセットアップしても、モデルがそれらを認識するのは次のセッションからになるというタイムラグがありました。

変更後

フックの実行完了と同時にスキルの再読み込みが行われるため、動的に追加されたコマンドも初回から即座に使用可能になります。

ユーザーへの恩恵

環境構築スクリプトなどをフックに組み込んだ際、自動セットアップされたツールをすぐに Claude に使わせることができます。

変更前

セッションのタイトルは自動生成されるか手動で変更する必要があり、フックの処理結果に基づいた動的な命名はできませんでした。

変更後

フックが特定のブランチ名やタスク内容に基づいてセッションタイトルを決定し、/resume 一覧やターミナルのタイトルに反映させることができます。

ユーザーへの恩恵

多数のバックグラウンドセッションを並行して実行している場合でも、各セッションの目的を識別しやすくなります。

変更前

特定の引数を持つPowerShellコマンドのみをトリガーにするような、精度の高い自動化設定が正常に動作しませんでした。

変更後

特定のコマンドパターン（例：git pushを含むものだけ）に絞ったフックが正しく発火するようになり、より柔軟な自動化が可能になります。

ユーザーへの恩恵

不要なタイミングでの自動処理実行を避け、特定の操作にだけ反応する賢いワークフローを構築できます。

変更前

プラグインにどのような機能(コマンドやスキルなど)が含まれているかを確認するには、実際にインストールしてみるまで詳細が不明でした。

変更後

インストール前の詳細画面で、プラグインが提供する具体的なコンポーネント(スキルやフックの種類、MCPサーバー構成など)がすべて表示されます。

ユーザーへの恩恵

自分のニーズに合ったプラグインかどうかを事前に判断できるため、不要なプラグインのインストールを避け、安心して機能を拡張できます。

変更前

セッション終了時のフックにおいて、そのセッションで実行されていたバックグラウンドタスクや定期実行タスクの状態にアクセスする手段がありませんでした。

変更後

フックに渡されるJSONコンテキストに、バックグラウンドタスクとスケジュールドタスク(cron)の情報が含まれるようになりました。

ユーザーへの恩恵

セッション終了時に未完了のタスクを確認して通知を送ったり、クリーンアップ処理を自動化したりするなど、より高度な自動化スクリプトが作成可能になります。

変更前

git 以外のバージョン管理システム（SVN や Perforce など）を使っている場合、バックグラウンド実行時の「作業コピーを壊さないための隔離」がうまく機能しない可能性がありました。

変更後

フックを通じてカスタムワークツリーを作成している環境でも、メインの作業場所とバックグラウンド作業の隔離が正しく強制されるようになりました。

ユーザーへの恩恵

どのような開発環境でも、バックグラウンドでの AI の作業が自分の手元の作業を誤って上書きしてしまうリスクが解消されます。

変更前

フックの設定を間違えた際、どこが悪いのかは教えてくれるものの、どう書くのが正解なのかまでは示されていませんでした。

変更後

診断結果の中に「こう書くべきです」という具体的なコード例が表示されるようになりました。

ユーザーへの恩恵

ドキュメントを読み返さなくても、診断画面の指示に従うだけで設定ミスを修正でき、学習コストを抑えられます。

変更前

Stopフックの設定によっては、Claudeが無限ループに陥り、APIコストが無駄にかかり続けてしまうリスクがありました。

変更後

連続ブロック回数に上限（デフォルト8回、CLAUDE_CODE_STOP_HOOK_BLOCK_CAPで変更可）が設けられ、ループが自動検知されます。

ユーザーへの恩恵

バグのあるフックスクリプトによる意図しない課金の発生を防ぎ、安全に自動化を運用できます。

変更前

SessionStart などのイベントにプロンプト型やエージェント型のフックを誤って設定した際、原因の分かりにくいエラーが発生していました。

変更後

「代わりにコマンド型（command-type）フックを使用してください」という明確な解決策を提示するメッセージが表示されるようになりました。

ユーザーへの恩恵

フック機能の高度なカスタマイズを行う際に、設定ミスを迅速に自己解決できるようになります。

変更前

フックがデスクトップ通知やターミナルのタイトル更新、ベル通知を行うには、制御用のターミナルに直接アクセスする必要がありました。

変更後

フックから出力されるJSONにterminalSequenceフィールドが含まれるようになり、ターミナルがない環境下でもこれらの通知シーケンスを安全にエミットできます。

ユーザーへの恩恵

CI環境やバックグラウンドプロセスなどの非対話型環境で実行されるフックでも、ユーザーのデスクトップに対して重要なステータス通知を届けられるようになります。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

フック機能が制限されている環境で /goal を実行すると、進行インジケーターが表示されたまま解決されず、暗黙的にハングアップした状態になっていました。

変更後

設定により機能が制限されている場合には、処理が止まるのではなく、ユーザーに対して明確なエラーや説明メッセージが表示されるようになりました。

ユーザーへの恩恵

管理者設定などによって特定の機能が使えない状況でも、原因が即座に分かるため、ユーザーの混乱を防げます。

変更前

設定ファイルをシンボリックリンクで管理している場合、ファイル変更の検知が正しく行われず、意図しないタイミングで設定変更フックが実行されることがありました。

変更後

リンク先の変更を正しく属性付けできるようになり、実際に設定が更新された時のみ正確にフックが動作するように復旧しました。

ユーザーへの恩恵

設定管理の柔軟性を保ちつつ、自動化スクリプトの誤作動を回避して安定したワークフローを維持できます。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

フックがツール実行をブロックした場合、そこでプロセスが中断されてしまい、Claudeがその理由を理解して別の方法を試すことができませんでした。

変更後

拒否理由をClaudeへのフィードバックとして返せるため、Claudeは「なぜ拒否されたか」を理解し、修正案を提示するなど作業を継続できます。

ユーザーへの恩恵

自動化されたルールチェックとAIの柔軟な対応を組み合わせることができ、ワークフローの停止を最小限に抑えられます。

変更前

インストール済みプラグインの情報表示が煩雑で、どのフックやサーバーが提供されているか視認しにくい状態でした。

変更後

各コンポーネントが整理された形式で表示されるため、プラグインがシステムに与える影響を一目で理解できます。

ユーザーへの恩恵

プラグインの管理が容易になり、特定の機能(フックやツール)がどこから提供されているかの混乱を防げます。

変更前

長時間のセッション中、バックグラウンドでクリーンアップ処理が走ると、現在実行中のフックが必要とするプラグイン資産まで削除され、エラーが発生することがありました。

変更後

実行中のセッションで使用されているプラグインバージョンのロック管理が改善され、フック実行中に必要なファイルが消失しないようになりました。

ユーザーへの恩恵

バックグラウンドのメンテナンス処理を気にすることなく、安定してプラグインや自動化フックを利用し続けることができます。

変更前

セッションを跨いで環境変数を維持するための仕組みが、リセットや再開コマンドによって上書き・消失してしまい、都度手動での再設定が必要でした。

変更後

環境変数の永続化管理が修正され、セッションの再開やリセットを行ってもフックで設定した環境が正しく維持されるようになりました。

ユーザーへの恩恵

ツール実行に必要な環境変数を一度設定すれば、セッションの状態が変わっても一貫して使い続けることができます。

変更前

フックスクリプトやBashコマンドは、メインセッションで設定されている思考レベル（low, high等）を検知する手段がありませんでした。

変更後

JSON入力の effort.level フィールドや $CLAUDE_EFFORT 環境変数を通じて現在のレベルを取得でき、Bashツールからも参照可能です。

ユーザーへの恩恵

思考レベルに応じてフックの挙動を変えたり、ログに記録したりするなど、コンテキストに応じた柔軟な自動化が可能になります。

変更前

Bash ツールで実行されるスクリプトやコマンドから、現在の Claude Code セッションを一意に識別する ID を直接参照する標準的な方法がありませんでした。

変更後

Bash ツールの実行環境に CLAUDE_CODE_SESSION_ID が自動的にセットされるようになり、フック（Hooks）に渡される JSON コンテキスト内の ID と同じ値をスクリプト内で利用できます。

ユーザーへの恩恵

セッションごとにログを分けたり、フックで開始した外部プロセスと Bash ツールでの操作を紐付けたりする自動化ワークフローがより確実かつ簡単に構築できるようになります。

変更前

設定ファイルのごく一部に記述ミスがあるだけで、他の正常な設定（パーミッションや環境変数など）まで全て読み込まれなくなっていました。

変更後

記述が不正なフック項目のみを個別に無視し、それ以外の正常な設定は可能な限り維持するように改善されました。

ユーザーへの恩恵

設定ミスによるツールの動作不能を防ぎ、一部のエラーがあっても安全にツールを使い続けることができます。

変更前

ツールの実行結果をフックで加工して Claude に渡す機能は、MCP サーバー経由のツールに限定されていました。Bash やファイル操作などの組み込みツールの出力を動的にフィルタリングしたり修正したりすることは困難でした。

変更後

すべての種類のツールで実行後の出力置換がサポートされました。フックスクリプトから updatedToolOutput を返すことで、Claude に渡される最終的なレスポンスを自在に制御できます。

ユーザーへの恩恵

秘匿情報のマスキングや、巨大なログ出力の要約など、Claude に渡す情報をフックでインテリジェントに制御し、コンテキストの質を高めることができます。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

バックグラウンドで動作するフック（通知のみを行う場合など）を実行すると、履歴の中に何も表示されない不要な行が増えていきました。

変更後

レスポンスのないフック実行は履歴を汚さないよう適切に処理されます。

ユーザーへの恩恵

/resume などで会話履歴を見返す際、不要な空白が排除され、本来の会話内容が読みやすくなります。

変更前

セッションの開始時やツールの実行前後（フック）で特定の処理を行いたい場合、シェルスクリプトやHTTPリクエストなど外部の仕組みを介してツールを実行する必要がありました。

変更後

フック構成内で直接MCPツールを呼び出せるようになり、例えば「特定のツール実行前にJiraチケットを更新する」といった自動化フローをよりシンプルに構築できます。

ユーザーへの恩恵

複雑なスクリプトを書かずにAIと既存のツールの連携を自動化できるため、開発ワークフローの自動化設定がより簡単かつ強力になります。

変更前

SubagentStart などのイベントに対してエージェント型フックを適用しようとすると、必要なデータ構造が不足しているというエラーで動作しませんでした。

変更後

より多くのイベントに対してエージェント型フックを正しく設定・実行できるようになりました。

ユーザーへの恩恵

特定のライフサイクルイベントにおいて、エージェントによる高度な自動検証を柔軟に組み込めるようになります。

変更前

フックの中で動くエージェントの動作そのものがフックを再発火させてしまい、無限ループのような不要な処理が発生していました。

変更後

検証用のサブエージェントによるアクションは、外部のフック発火対象から適切に除外されるようになりました。

ユーザーへの恩恵

フックの実行コスト（トークン使用量）が最適化され、意図しないフックの連鎖を防げます。

変更前

サブエージェントの設定ファイルで定義したフック (hooks:) は、サブエージェントとして呼び出された時しか機能せず、--agent で直接起動した場合には実行されませんでした。

変更後

--agent を使って特定のロールでセッションを開始した場合でも、そのエージェントの定義に含まれるフックが正しくトリガーされるようになりました。

ユーザーへの恩恵

特定の役割（セキュリティ担当やレビュアーなど）を担うエージェントを直接起動した際も、自動フォーマットなどのカスタムワークフローが期待通りに動作します。

変更前

Windows環境ではこれらが機能しておらず、仮想環境の自動有効化やカスタム環境変数の永続化が動作していませんでした。

変更後

Linux/macOSと同様の動作がサポートされ、フックを利用した高度なワークフロー構築が可能になりました。

ユーザーへの恩恵

Windows開発者も、プロジェクト開始時にPythonの仮想環境を自動でアクティベートするといった効率化の恩恵を受けられます。

変更前

フック機能で入力を書き換えた際、禁止ルールをすり抜けてしまう可能性がありました。また、管理ポリシーで禁止されている場合でも、フックから「バイパスモード」へ移行できてしまうセキュリティ上の懸念がありました。

変更後

更新された入力に対して再度厳格な権限チェックが行われ、管理者設定による「バイパス禁止」も常に尊重されるようになりました。

ユーザーへの恩恵

組織で設定したセキュリティポリシーをバイパスされるリスクが解消され、フック機能を安心して業務に組み込めます。

変更前

フックを使ってAIに補足情報を与えていても、その直後のツール実行が一度失敗すると、せっかくの補足情報が消えてしまい、AIが状況を正しくリトライできないことがありました。

変更後

ツール実行の成否にかかわらず、フックによって注入されたコンテキストが正しく保持され、AIに共有され続けるようになりました。

ユーザーへの恩恵

失敗の原因をAIがフックの情報を元に深く理解し、より的確に再試行できるようになるため、エラーからの自己復旧率が高まります。

変更前

コンテキストの圧縮（コンパクション）が発生する際、ユーザーがその実行をプログラムで制御したり、特定の条件下で阻止したりする手段がありませんでした。

変更後

PreCompactフックにより、スクリプトがコード2で終了するか「decision:block」を返すことで、圧縮の実行を一時的に止めることが可能になりました。

ユーザーへの恩恵

重要な会話の文脈が自動圧縮で失われるのを防ぎたい自動化スクリプトや、特定のワークフローにおいて、コンテキストの整合性を維持しやすくなります。

変更前

将来のアップデートで追加されたフック名やタイポが1箇所でもあると、settings.json の設定全体が無効化されてしまう問題がありました。

変更後

認識できない個別の設定のみがスキップされるようになり、他の有効な設定は正しく読み込まれます。

ユーザーへの恩恵

設定ミスによるツール全体の機能不全を防ぎ、より安全にカスタマイズを行えるようになります。

変更前

組織のポリシーでユーザーによるフックの追加を制限していると、IT管理者が配布したプラグイン内の必要なフックまでブロックされてしまうことがありました。

変更後

管理者が承認したプラグイン由来のフックは、制限下でも適切に実行されるようになります。

ユーザーへの恩恵

セキュリティを確保しつつ、組織で推奨される自動化ツールを確実に動作させることができます。

変更前

設定ファイルで特定のコマンドを「拒否（deny）」していても、フックの設定によってはユーザーに「確認（ask）」を求めてしまい、拒否ルールをバイパスできてしまう場合がありました。

変更後

「拒否」ルールが常に最優先されるようになり、フックによって承認待ちにダウングレードされることがなくなります。

ユーザーへの恩恵

セキュリティ設定の優先順位が明確になり、意図しないツールの実行をより確実に防止できます。

変更前

前回のセッションが正常に終了せず、一時的な作業ツリー（ワークツリー）のディレクトリが残っていると、同じ名前で作業を開始できないことがありました。

変更後

古い残存ディレクトリを適切に処理し、新しいセッションをスムーズに開始できるようになります。

ユーザーへの恩恵

クラッシュ後の再開や、同一名での繰り返し作業におけるワークフローの停止を防げます。

変更前

RemoteTriggerツールを使用してリモートでコマンドを実行しようとした際、リクエストボディが空の状態で送信されていました。

変更後

runアクション実行時に正しいデータが送信されるようになり、サーバー側でリクエストが正常に受理されるようになりました。

ユーザーへの恩恵

リモート環境でのフックや自動化ワークフローの実行が失敗することなく、安定して動作するようになります。

変更前

会話が長くなるとフックが動かなくなったり、エラーが発生しても原因が分からず「JSONバリデーション失敗」という曖昧な表示が出るだけでした。

変更後

長時間のセッションでもフックが安定して動作し、エラー発生時には API からの実際のメッセージが表示されるため、自己診断が可能になりました。

ユーザーへの恩恵

ワークフローの自動化や検証をフックで行っている場合、その信頼性とメンテナンス性が大幅に向上します。

変更前

フックが失敗しても「エラーが発生しました」と表示されるだけで、具体的にスクリプトのどこが間違っているのかを特定するために詳細ログを追う必要がありました。

変更後

失敗の理由（「ファイルが見つからない」「権限がない」等）が直接履歴に表示されるようになります。

ユーザーへの恩恵

フックの微調整が格段に楽になり、自動化設定のメンテナンス時間を短縮できます。

変更前

セッションが長くなると終了時の自動処理（フック）が動かなくなったり、フックの不具合時に原因が分からないエラーメッセージが表示されることがありました。

変更後

長大セッションでもフックが安定動作し、エラー発生時も具体的な原因が表示されるようになったため、デバッグが容易になりました。

ユーザーへの恩恵

自動化された後処理や通知が確実に実行されるようになり、開発ワークフローの信頼性が向上します。

変更前

セッションのタイトルはAIによって自動生成されるか手動で変更する必要があり、ユーザーのプロンプト入力に基づいて外部スクリプトなどから動的にタイトルを制御する手段がありませんでした。

変更後

ユーザーがプロンプトを送信した直後に実行されるフックから、JSON形式でセッションタイトルを指定して上書きできるようになりました。

ユーザーへの恩恵

独自の命名規則に従ってセッションを自動整理したり、特定のキーワードが含まれる場合にタイトルを即座に変更したりといった自動化が可能になります。

変更前

スキルファイル（SKILL.md）のフロントマテリアル内にフックを定義しても、システムに認識されず動作しない不具合がありました。

変更後

スキル定義内のフックが正しく読み込まれ、指定したイベントに応じて実行されるようになりました。

ユーザーへの恩恵

スキルのライフサイクルに合わせたカスタム動作を確実に行えるようになり、より高度なプラグイン開発が可能になります。

変更前

プラグインのインストール環境によっては CLAUDE_PLUGIN_ROOT 変数が正しく解決されず、フック内で相対パスを使用しているスクリプトなどが実行できないことがありました。

変更後

変数の解決ロジックが改善され、プラグインルートを基準としたファイル参照が安定して動作するようになりました。

ユーザーへの恩恵

プラグインの配布形式やユーザーの実行環境を問わず、フック機能が確実に動作するようになります。

変更前

モデルが ok:false を返した際にフックが予期せずエラーになったり、ツール実行をブロックすべき場面で継続されてしまう不具合がありました。

変更後

Stopイベントの判定が正確になり、プロンプト型フックによるワークフローの中断制御が意図通りに機能するようになります。

ユーザーへの恩恵

フックを利用した自動化プロセスの信頼性が向上し、特定の条件下で処理を確実に停止させることが可能になります。

変更前

Claude がファイルを編集した直後にフックで Prettier などのフォーマッタを動かすと、Claude 側が持っているファイル状態と不一致が起き、次の編集ができなくなることがありました。

変更後

フックによる変更が正しく検知され、Claude はエラーで止まることなく連続した編集作業を継続できるようになりました。

ユーザーへの恩恵

自動フォーマットなどのフック機能を併用しているプロジェクトでも、Claude による一連のコード修正がスムーズに完了します。

変更前

特定の条件でツール実行を拒否しようとしても、フックの出力形式や終了コードの組み合わせによってはブロック処理が正しく動作しない不具合がありました。

変更後

フックからのブロック指示が確実に処理され、セキュリティ上の制約やバリデーションが厳密に適用されます。

ユーザーへの恩恵

独自に作成したフックによる実行制限（破壊的なコマンドの禁止など）が意図通りに機能し、安全性が向上します。

変更前

非常に長いテキストやデータが送られてくる際、データ量が増えるほど処理速度が指数関数的に低下し、UI が重くなることがありました。

変更後

データ量に比例した安定した速度で処理されるようになり、大容量データのストリーミングも高速に行われます。

ユーザーへの恩恵

大規模なドキュメントや長いログを扱う際でも、快適にレスポンスを受け取ることができます。

変更前

ヘッドレスモード（-p）において、フックがツールの実行を条件付きで保留し、後からユーザーの判断を待って再開させる明確な仕組みが不足していました。

変更後

フックが "defer"（保留）を返せるようになり、実行を中断したセッションを -p --resume で再開する際に、再度フックを走らせて最終的な実行可否を決定できるようになりました。

ユーザーへの恩恵

自動化スクリプトやCI環境において、重要な操作の直前で一時停止し、人間が確認してから安全に続行させるワークフローが構築しやすくなります。

変更前

オートモード（auto mode）で操作が拒否された際、プログラム的に介入して修正を促したり、特定の条件下で再試行を許可したりする柔軟な手段がありませんでした。

変更後

拒否イベントをトリガーにフックを実行できるようになり、拒否理由に基づいてモデルに指示を出し直すなどの動的な制御が可能になりました。

ユーザーへの恩恵

安全性を保ちつつ、誤検知による中断を自動でリカバーさせることができ、オートモードでの作業の自律性が高まります。

変更前

フックに渡却されるパスが相対パスであったため、フック側のスクリプトでカレントディレクトリを移動している場合などにパスの解決が失敗することがありました。

変更後

常にルートからの絶対パスが渡されるようになり、どのような実行環境でもフックが正確に対象ファイルを特定できます。

ユーザーへの恩恵

フックを利用した複雑な自動処理や検証スクリプトの作成が、より簡単かつ確実になります。

変更前

特定のコマンドを制限するためのフックを設定していても、書き方のバリエーションによって制限をすり抜けて実行されてしまう可能性がありました。

変更後

シェルコマンドの構文をより深く理解してマッチングを行うようになり、複雑なワンライナーに対しても確実にフィルタが機能します。

ユーザーへの恩恵

セキュリティや運用ルールの強制力が強化され、より安全にエージェントにシェル操作を任せられるようになります。

変更前

フック（自動テスト結果など）の出力が非常に大きい場合、それだけでコンテキスト窓を占有してしまい、AIが本来のタスクを忘れたり回答できなくなったりしていました。

変更後

出力の要約のみを渡し、詳細は別ファイルを参照する形式になったため、トークンの節約と精度の維持が両立されます。

ユーザーへの恩恵

大量のログを出すテストスイートなどと連携しても、 Claude Codeの応答性能を落とさずに開発を続けられます。

変更前

エージェントチームにおけるタスク作成時にトリガーされるフックの詳細な仕様や、作成を阻止する方法が公開されていませんでした。

変更後

フックを介して新しいタスクの開始を制限したり、特定の条件下でのみ許可したりする手法が公式にサポートされました。

ユーザーへの恩恵

チーム開発においてAIエージェントの無秩序なタスク増殖を防ぎ、人間の意図に沿った形でエージェントを管理・統制できるようになります。

変更前

Autoモード（研究プレビュー）において、AIの操作がセキュリティポリシー等で拒否された場合、AIがその理由を理解して別の方法でリトライすることが困難でした。

変更後

このフックを利用して {retry: true} を返すと、AIに操作が拒否されたことを伝え、安全な代替案を自律的に考案させることが可能になります。

ユーザーへの恩恵

AIが一度の拒否で止まってしまうことを防ぎ、ユーザーが手動で指示し直す手間を省きながら、タスクの完了率を高めることができます。

変更前

&& で繋いだ複数のコマンドや、VAR=val cmd のように環境変数を指定したコマンドに対して、特定のフックが正しく発火しない場合がありました。

変更後

コマンド解析の精度が向上し、より複雑な形式のシェルコマンドに対しても正確にフックが適用されるようになりました。

ユーザーへの恩恵

特定のコマンド実行時に自動で行いたい処理（プッシュ前のバリデーションなど）の確実性が高まり、意図しない操作の防止や自動化の信頼性が向上します。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

フックは条件に関わらずイベントごとに実行されていたため、特定のコマンドの時だけ動作させたい場合でも毎回プロセスが起動し、パフォーマンスに影響を与えていました。

変更後

パーミッションルールと同様の構文で実行条件を指定できるようになったため、条件に一致しない場合はプロセスの起動自体をスキップできます。

ユーザーへの恩恵

不要なフックの実行が抑制されることで、ターミナルの応答性が向上し、特に頻繁に発生するイベントでのリソース消費を抑えることができます。

変更前

ヘッドレス（非対話）モードでの実行中、Claudeがユーザーに質問（AskUserQuestion）を投げると、外部から動的に回答を供給するスマートな方法が不足していました。

変更後

フック経由で質問への回答（updatedInput）を返せるようになったため、独自のUIや自動化スクリプトを介してClaudeの質問に回答できます。

ユーザーへの恩恵

CLIを直接操作できないCI/CD環境やカスタムアプリ経由の利用において、Claudeとの対話を自動化または外部UI化することが可能になります。

変更前

Git以外のVCS（SVN等）をフックでサポートしようとしても、起動時のGitチェックで処理が止まってしまい、フックによるカスタム処理が実行できませんでした。

変更後

--worktree起動時のチェック順序が見直され、Gitがない環境でもフックによる独自のワークツリー作成処理を正しく開始できるようになりました。

ユーザーへの恩恵

Git以外のプロジェクト管理ツールを使用している開発者も、Claude Codeの強力な並行作業機能を活用できるようになります。

変更前

Claudeが新しいタスクを作成した瞬間に外部ツールを連携させたり、カスタムログを記録したりする標準的なトリガーがありませんでした。

変更後

TaskCreate ツールによってタスクが作成されたときに発火する TaskCreated フックが実装されました。

ユーザーへの恩恵

タスク管理システムとの自動同期や、タスク開始時のCI実行など、開発ワークフローをよりきめ細かく自動化できます。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

Claude が cd コマンドでディレクトリを移動したり、特定のファイル（.env など）が変更されたりしても、Bash ツール内の環境変数が自動的に更新されませんでした。direnv などの外部ツールによる動的な環境変化を自動的に反映する仕組みが不足していました。

変更後

ディレクトリ移動時に発火する CwdChanged と、指定したファイルを監視する FileChanged イベントが導入されました。これらのフックを使用して CLAUDE_ENV_FILE を更新することで、環境変数を自動的に再読み込みできます。

ユーザーへの恩恵

プロジェクトごとに異なる環境変数を扱う direnv や .env ファイルの運用が自動化され、ユーザーが手動で環境を再設定する手間が省け、作業ミスも防げます。

変更前

Claude Code が起動されているシェルに設定されている API キーなどの機密情報が、Claude が実行する Bash コマンドや MCP サーバーなどの子プロセスにそのまま引き継がれていました。万が一、プロンプトインジェクションが発生した場合、これらの情報が外部に漏洩するリスクがありました。

変更後

この環境変数を有効にすることで、子プロセスの環境変数から機密性の高い認証情報を自動的に除去（スクラブ）します。Claude Code 本体は認証情報を保持し続けますが、その配下で動くツールからは参照できなくなります。

ユーザーへの恩恵

開発環境における機密情報の露出を最小限に抑え、信頼できないコードを分析したり、外部の MCP ツールを利用したりする際の安全性が大幅に向上します。

変更前

フック機能などが生成するシステムメッセージが原因で、会話履歴の ID 管理が複雑になり、一度終了したセッションを /resume で再開した際、過去のやり取りの一部が見えなくなることがありました。

変更後

メッセージの親子関係（Uuid チェーン）の管理ロジックが改善され、システム的な副作用があっても会話の整合性が維持されるようになりました。

ユーザーへの恩恵

長期間にわたるプロジェクトで過去の経緯を振り返りながら作業する際、履歴が欠落する心配なく安心して作業を継続できます。

変更前

非インタラクティブモード（-p）でスクリプトを実行する際も、通常のセッションと同様にフックの実行やプラグインの同期、メモリの読み込みが行われていました。

変更後

--bare フラグを使用することで、純粋にモデルの推論のみを高速に実行できるようになります。このモードでは OAuth 認証等がバイパスされるため、API キーの設定が必須となります。

ユーザーへの恩恵

CI/CD パイプラインや自動化スクリプトにおいて、不要なオーバーヘッドを削減し、起動速度の向上と実行の安定性を確保できます。

変更前

セッションを終了して別のセッションに切り替える際、本来実行されるべき終了時フック (SessionEnd) がスキップされていました。

変更後

セッションの切り替え時にも正しく SessionEnd イベントが発火し、登録されたフックが実行されるようになりました。

ユーザーへの恩恵

セッション終了時のクリーンアップ作業やログ記録などを、どのような切り替え操作を行っても確実に行うことができます。

変更前

APIエラーで処理が中断された場合、それをフックして自動的に通知を送ったりログを記録したりする仕組みがありませんでした。

変更後

StopFailure イベントにより、レート制限や認証エラーなどの失敗を検知して特定のスクリプトを実行できるようになりました。

ユーザーへの恩恵

エラー発生時の後処理を自動化し、モニタリングやトラブルシューティングの効率を向上させることができます。

変更前

特定の API エラーが発生した際、エラー処理のフック自体が新たなエラーを引き起こし、処理が止まらなくなる不具合がありました。

変更後

エラー発生時のループ検知と処理フローが改善され、無限ループに陥ることなく安全に停止するようになりました。

ユーザーへの恩恵

予期せぬエラー発生時でもリソースやトークンの浪費を防ぎ、安定した動作が保証されます。

変更前

Git ワークツリーを利用した並行作業中に、そのワークツリー独自の自動化スクリプトやカスタムスキルが認識されませんでした。

変更後

ワークツリー環境からでも正しく設定ファイルが読み込まれ、メイン環境と同じ自動化機能が利用可能になりました。

ユーザーへの恩恵

複数の機能を並行して開発する際も、一貫した開発体験と自動化ツールを維持できます。

変更前

フック側で許可（allow）を出すと、エンタープライズの管理ポリシー等で定義された強力な拒否ルールすら上書きされてしまう脆弱な状態でした。

変更後

パーミッション評価順序が厳格化され、フックの出力に関わらず拒否ルールが常に優先されるようになりました。

ユーザーへの恩恵

組織レベルで設定したセキュリティポリシーが確実に適用されるため、安全にフック機能を活用できます。

変更前

プラグイン開発時に YAML のパースエラーやスキーマ違反があっても、実行するまで気づけないことがありました。

変更後

バリデーションコマンドで事前に構文エラーや設定の誤りを網羅的にチェックできるようになりました。

ユーザーへの恩恵

プラグイン開発のデバッグ効率が上がり、より高品質な拡張機能を短時間で作成できます。

変更前

MCP elicitationの応答やプロセスを自動化したり、独自のロジックで制御したりするための拡張ポイントが存在しませんでした。

変更後

新しいフックにより、Claude Codeがユーザーに応答を返す直前でデータを取得し、必要に応じてその内容を変更したり独自の処理を挟んだりすることが可能になりました。

ユーザーへの恩恵

elicitationプロセスにおけるカスタムバリデーションの追加や、特定の入力を自動補完するなどの高度な自動化が可能になります。

変更前

セッション終了時に実行したいクリーンアップ処理やログ保存などのフック処理が、設定したタイムアウト時間に達する前に強制的に打ち切られていました。

変更後

環境変数で終了時の待機時間をカスタマイズできるようになり、時間のかかる終了後処理も確実に完了させることができます。

ユーザーへの恩恵

大切な後処理や自動化スクリプトが途中で途切れる心配がなくなり、開発ワークフローの自動化がより堅牢になります。

変更前

--resume や --continue を使用すると、初期化スクリプトが必要以上に実行され、セットアップ時間が無駄にかかっていました。

変更後

再開時のライフサイクルイベントが適切に整理され、フックは期待通り1回のみ実行されるようになりました。

ユーザーへの恩恵

セッション開始時の待ち時間が短縮され、プロジェクト固有の環境構築がより正確に行われます。

変更前

フックを使用するたびに余分なメッセージがコンテキストに蓄積され、トークン消費が増大したりモデルの精度に影響したりしていました。

変更後

内部的なリマインダー挿入ロジックが改善され、コンテキストがクリーンに保たれるようになりました。

ユーザーへの恩恵

フックを多用してもコンテキストウィンドウが圧迫されにくくなり、長時間の対話でも一貫した性能が維持されます。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

プロジェクト固有の指示が読み込まれたタイミングを検知して自動で処理を実行する手段がありませんでした。

変更後

メモリファイルが読み込まれた直後に特定のスクリプトを実行し、コンテキストの検証や追加情報の注入が可能になりました。

ユーザーへの恩恵

指示ファイルの変更に合わせた環境の自動セットアップなどが可能になり、プロジェクトごとのカスタマイズの幅が広がります。

変更前

フックが実行された際、それがメインセッションによるものか、どの種類のサブエージェントによるものかをプログラムで判断できませんでした。

変更後

エージェントの種類に応じた条件分岐がフック内で可能になり、サブエージェント専用の制御フローを実装できるようになりました。

ユーザーへの恩恵

サブエージェントごとの権限制限や通知内容の変更など、より高度で精緻な自動化が可能になります。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

Claude がいつプロジェクト固有のルールを認識したのかをトリガーにして外部スクリプトを実行したり、読み込まれた指示の内容に基づいて動的な処理を行ったりする手段がありませんでした。

変更後

ルールの読み込み完了をフックできるようになったため、特定のルールが適用された際に通知を出したり、関連する依存関係のチェックを自動で行ったりすることが可能になります。

ユーザーへの恩恵

指示ファイル（CLAUDE.md）を中心とした開発ワークフローの自動化が進み、特定のコンテキストに合わせた柔軟な拡張が可能になります。

変更前

フック内で、現在実行中のアクションがメインスレッドによるものか、それとも特定のサブエージェントによるものかを判別して処理を分けることが困難でした。

変更後

フックハンドラーに渡される JSON にエージェントの情報が含まれるようになったため、「このエージェントが実行するときだけは特定の処理をスキップする」といったきめ細やかな制御が可能になりました。

ユーザーへの恩恵

サブエージェントを活用した複雑な自動化において、フックの挙動を意図通りに制御できるようになり、より高度な開発支援環境を構築できます。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

エージェントチームの作業完了時や待機時の挙動をカスタマイズする際、スクリプト側から「ここで完全に停止させる」という判断を Claude Code に伝えるスマートな方法が不足していました。

変更後

標準的な停止シグナルをサポートしたことで、特定の条件（テスト失敗時など）でチームメイトの稼働を強制終了させることが、JSON レスポンス一つで制御可能になりました。

ユーザーへの恩恵

チームメイトの無駄な待機時間を削減し、特定の状況下での自動化フローの制御がより正確に行えるようになります。

変更前

フックはシェルコマンドとしてしか実行できず、外部APIとの連携に制約がありました。

変更後

HTTPフックにより、指定したURLにJSONデータをPOSTし、JSON形式でレスポンスを受け取ることができるようになりました。

ユーザーへの恩恵

外部APIやWebサービスとの連携が容易になり、より多様な自動化ワークフローを構築できるようになりました。

変更前

ワークスペースの信頼が承認されていない状態でも、statusLine や fileSuggestion のフックコマンドが意図せず実行される可能性があり、セキュリティリスクがありました。

変更後

ワークスペースの信頼が承認されていない場合、これらのフックコマンドは実行されなくなりました。

ユーザーへの恩恵

意図しないコマンド実行を防ぎ、ローカル開発環境のセキュリティを強化します。

変更前

ワークツリーの作成・削除時にカスタムVCSのセットアップ/ティアダウンを行う機能がありませんでした。VCSの初期化やクリーンアップを自動化したい場合に、手動での対応が必要でした。

変更後

ワークツリーの作成・削除時にカスタムVCSのセットアップ/ティアダウンを行えるようになりました。これにより、VCSの初期化やクリーンアップといった定型作業を自動化できます。

ユーザーへの恩恵

VCSのセットアップとティアダウンを自動化することで、開発者はワークツリーのライフサイクル管理にかかる手間を省き、より効率的に開発を進めることができます。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

これまでは、Claude Codeのセッション中に設定ファイル(settings.jsonやスキルファイルなど)が外部から変更されても、それを自動的に検知して対応する仕組みがありませんでした。これにより、セキュリティポリシーの監査や、意図しない設定変更を防ぐことが困難でした。

変更後

新しく追加されたConfigChangeフックイベントは、設定ファイルがセッション中に変更されるとトリガーされます。このイベントを利用することで、企業は設定ファイルの変更をリアルタイムで監視し、監査ログに記録したり、特定の変更をブロックしたりするカスタムフックを実装できるようになります。

ユーザーへの恩恵

企業はClaude Codeのセキュリティとコンプライアンスをより厳密に管理できるようになります。設定変更が追跡可能になり、承認されていない変更を自動的に防ぐことで、開発環境の安全性が向上し、管理者は安心してClaude Codeを導入・運用できます。

変更前

以前は、ユーザーやプロジェクトの設定でdisableAllHooks: trueを設定すると、組織のポリシーによって管理対象として設定された重要なフックも無効化されてしまう可能性がありました。これにより、意図せずセキュリティやコンプライアンスに関わるフックが無効化され、ポリシーの一貫性が損なわれるリスクがありました。

変更後

今回の修正により、disableAllHooks設定が管理対象設定の階層を正しく尊重するようになりました。具体的には、ユーザーやプロジェクトレベルの設定でdisableAllHooksをtrueにしても、管理者によって設定された管理対象(マネージド)フックは無効化されなくなります。これにより、ポリシーによるフックの強制力が高まります。

ユーザーへの恩恵

エンタープライズ環境でClaude Codeを利用する管理者は、組織のセキュリティポリシーやワークフローに必要なフックが常に有効であることを保証できるようになります。ユーザーが誤って重要なフックを無効化する心配がなくなり、より安全で統制の取れた開発環境を維持できます。

変更前

Claude Codeの起動時、SessionStartフックが即座に実行されるため、初期化に時間がかかり、ユーザーが操作可能になるまでの時間が長くなっていました。

変更後

Claude Codeの起動パフォーマンスが改善されました。SessionStartフックの実行が遅延されるようになり、ユーザーが操作可能になるまでの時間が約500ミリ秒短縮されました。

ユーザーへの恩恵

Claude Codeの起動が速くなり、開発者はすぐに作業を開始できるようになりました。これにより、開発サイクルの初期段階での待ち時間が減り、生産性が向上します。

変更前

StopおよびSubagentStopフックでは、アシスタントの最終応答テキストにアクセスするためにトランスクリプトファイルを解析する必要がありました。これは手間がかかるだけでなく、エラーが発生しやすいプロセスでした。

変更後

StopおよびSubagentStopフック入力に last_assistant_message フィールドが追加されました。これにより、フックはトランスクリプトファイルを解析することなく、アシスタントの最終応答テキストに直接アクセスできます。

ユーザーへの恩恵

フック開発者がアシスタントの最終応答に簡単にアクセスできるようになり、より効率的で堅牢なフックの作成が可能になりました。

変更前

Windows環境では、cmd.exeが使用されていたため、フック(PreToolUse、PostToolUse)がサイレントに失敗し、実行されない問題がありました。

変更後

Windows環境でhooks(PreToolUse、PostToolUse)がサイレントに失敗する問題が修正されました。Git Bashが使用されるようになり、フックが正しく実行されるようになりました。

ユーザーへの恩恵

Windows環境でのフック実行が安定し、Git Bashの利用によりPreToolUseやPostToolUseといった重要な自動化処理が正しく機能するようになりました。

変更前

プラグインをインストールしても、そのプラグインが提供するコマンド、エージェント、フックがすぐに利用できず、Claude Code の再起動が必要でした。

変更後

プラグインのインストール後、再起動することなく、提供されたコマンド、エージェント、フックが即座に利用可能になりました。

ユーザーへの恩恵

プラグインの追加や更新がよりスムーズになり、開発者はツールのセットアップ時間を短縮して、すぐに作業を開始できます。

変更前

フックがブロックされた際に発生するエラーで、エラー出力(stderr)の内容がユーザーインターフェースに適切に表示されないことがありました。これにより、何が原因でフックがブロックされたのか、詳細な情報が確認できず、問題解決が困難でした。

変更後

フックがブロックされた際のエラー通知に、stderr(標準エラー出力)の内容が含まれてUIに表示されるようになりました。これにより、エラーの具体的な原因を開発者がより詳細に把握し、迅速なトラブルシューティングが可能になります。

ユーザーへの恩恵

フックがブロックされた際、エラーの原因がUIで明確に表示されるようになるため、問題の診断と修正が大幅に効率化されます。これにより、フックベースの自動化ワークフローの信頼性が向上し、開発者のデバッグ作業が軽減されます。

変更前

以前は、エージェントチームのメンバーがアイドル状態になる前や、タスクが完了とマークされる前に、カスタムロジックを挿入してワークフローを制御する仕組みがありませんでした。これにより、特定の条件下でチームメイトの作業を継続させたり、タスクの完了を阻止してフィードバックを提供したりするなどの、高度なワークフローの自動化が困難でした。

変更後

TeammateIdleとTaskCompletedフックイベントが追加されたことで、エージェントチームのメンバーがアイドル状態になる直前や、タスクが完了とマークされる直前に、カスタムスクリプトやHTTPエンドポイントを実行できるようになりました。これにより、例えば、チームメイトがアイドル状態になるのを防ぎ作業を継続させたり、特定の条件が満たされない限りタスクの完了を阻止して詳細なフィードバックを要求したりすることが可能になります。

ユーザーへの恩恵

これらの新しいフックイベントにより、マルチエージェントワークフローの自動化と制御が大幅に強化されます。チームメイトの振る舞いやタスクの完了プロセスをより細かくカスタマイズできるため、複雑なプロジェクト管理や品質保証のシナリオにおいて、より堅牢でインテリジェントなエージェントチームを構築できます。これにより、開発者はワークフローの柔軟性が向上し、生産性が高まることを実感できます。

変更前

ツール実行前のPreToolUseフックは、モデルに渡す追加情報を提供できませんでした。

変更後

PreToolUseフックは、ツールの実行前にモデルにadditionalContextとして追加情報を提供できるようになりました。

ユーザーへの恩恵

これにより、フックはツールの実行前にモデルに追加のコンテキストを提供できるようになり、よりインテリジェントな意思決定や、フックによるツール実行の制御が可能になります。

変更前

フックの実行時にどのエージェントが使用されているかの情報が不足しており、特定のカスタムエージェントが起動した際に連動した処理を行うことが困難でした。

変更後

SessionStart イベントの JSON コンテキストに agent_type フィールドが含まれるようになり、--agent フラグで指定されたエージェント名をフック内で識別できるようになります。

ユーザーへの恩恵

カスタムエージェントの種類に応じた初期化処理や環境設定をフックで自動化できるようになり、ワークフローの柔軟性が向上します。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

セッション開始時の環境構築など、一度だけ実行すれば十分なタスクをフックで行う際、その後も条件に合うたびに繰り返し実行されてしまうのを防ぐのが困難でした。

変更後

初回実行後に自動で無効化されるフックを簡単に設定できるようになりました。

ユーザーへの恩恵

セットアップ処理や初回限定の通知などを、無駄な繰り返しを避けてスマートに自動化できます。

変更前

フックの設定を対話形式で行う際、選択項目のスクロール操作が原因で意図しない設定が適用されてしまうことがありました。

変更後

リストの選択挙動が安定し、意図した通りのイベントやアクションを正確に設定できるようになりました。

ユーザーへの恩恵

複雑なフックの構成を、CLI 上でミスなく直感的に行えるようになります。