Claude Code v2.1.163 — バージョン固定の管理設定と、hook条件の誤発火を修正
Claude Code v2.1.163は、組織が許可バージョンの範囲を管理設定で固定できるようにし、hookのBash条件が誤発火する問題やHomeディレクトリのdeny抜け穴を修正した22項目の版です。
このリリースで何ができるようになるか
Claude Codev2.1.163は、新機能・挙動変更7件と修正12件、軽微な改善3件を合わせた22項目の版です。なかでも読者の体験に直接効くのは、組織が利用してよいバージョンの範囲を管理設定で固定できるようになったこと、hookのif条件が意図しないBashコマンドで誤発火していた問題が直ったこと、そして$HOME経由のパス参照を見逃していた拒否ルールの抜け穴がふさがれたことの3点です。
1つ目は、バージョン範囲の固定です。管理設定にrequiredMinimumVersionとrequiredMaximumVersionの2つのキーが加わり、組織が承認したバージョンの範囲を指定できるようになりました。利用者のバージョンがこの範囲の外にあると、Claude Codeは起動を拒否し、承認済みのバージョンへ誘導します。IT管理部門が「検証済みのバージョンだけを社内で使わせたい」という要件を、利用者の手動運用に頼らず仕組みで担保できます。
2つ目は、hookのif条件の修正です。これまでif: "Bash(...)"の条件は、$()や$VARを含むすべてのBashコマンドで発火していました。本版では、サブシェルやバッククォート内のコマンドにも正しくマッチするようになり、条件が書いたとおりに効きます。hookを運用しているチームにとって、意図しないタイミングでhookが走る取りこぼしが減ります。
3つ目は、拒否ルールの抜け穴の修正です。Read(~/Desktop/**)のようにHomeディレクトリのパスを対象にした拒否ルールが、$HOMEを経由してパスを参照するBashコマンドをブロックしていませんでした。本版ではこの抜け穴がふさがれ、Homeディレクトリ配下を守る拒否ルールが$HOME参照経由でも効くようになります。
あなたの開発フローはどう変わるか
組織でバージョンを統制したい場合
社内で利用してよいClaude Codeのバージョンを管理したい運用では、本版から管理設定で範囲を固定できます。これまでは「全員このバージョンを使ってください」という案内を出しても、実際のバージョンは各自のインストール状況に委ねられていました。requiredMinimumVersionとrequiredMaximumVersionを設定すると、範囲外のバージョンで起動しようとした利用者はその場で止められ、承認済みのバージョンへ誘導されます。
この仕組みは、検証していない新しいバージョンが現場に広がる前に止めたい場合や、既知の不具合がある古いバージョンを下限で弾きたい場合に役立ちます。後段の早見表で、個人による手動固定と組織による管理設定固定の使い分けを示します。
hookを運用している場合
hookでif条件を使っている運用では、本版で書いたとおりに効いていなかった落とし穴が直ります。前述のif: "Bash(...)"の誤発火で、$()のコマンド置換や$VARの変数参照を含むコマンドのすべてで条件が反応してしまっていました。本版ではサブシェルやバッククォート内まで正しく判定され、条件の対象が絞り込まれます。
あわせて、StopフックとSubagentStopフックの拡張も入りました。これは不具合の修正ではなく、hook運用の幅を広げる機能追加です。本版から、この2つのフックがhookSpecificOutput.additionalContextを返せるようになりました。返した内容はClaudeへのフィードバックとして渡され、ターンを継続させられます。これまでフックがフィードバックを返そうとするとhookエラー扱いになっていましたが、本版ではエラーにならず、Claudeに追加の文脈を渡してそのまま処理を続けられます。
拒否ルールでファイルを保護している場合
Read(~/Desktop/**)のようにHomeディレクトリ配下を保護する拒否ルールを書いている運用では、本版で抜け穴が1つふさがれます。これまでは拒否ルールがHomeディレクトリのパスを対象にしていても、Bashコマンドが$HOMEを経由してパスを組み立てると、そのコマンドはブロックされませんでした。本版では$HOME経由の参照もルールの判定対象になり、保護したいパスがコマンド経由で読まれることを防げます。
この修正は、v2.1.160から続く権限・セキュリティ堅牢化の流れの一部です。後段のタイムライン表で、どの版でどの抜け穴がふさがれてきたかを示します。
claude -pを自動化で使っている場合
非対話モードのclaude -pを使った自動化では、2つのハングと失敗が解消します。1つは、バックグラウンドのコマンドが終了しないとき、最終結果を出したあとにclaude -pが永久にハングする問題です。本版では、stdinが閉じたら結果のおよそ5秒後にバックグラウンドのシェルを停止し、プロセスが残り続けないようになります。
もう1つは、BedrockやVertex、Foundryを使っていて、CI=trueかつAnthropic APIキーが未設定のときに、claude -pが「ANTHROPIC_API_KEY required」で失敗していた問題です。本版でこの誤った失敗が直り、これらのプロバイダーをCI環境で使う際の起動が通るようになります。
主な変更点
本版は22項目で構成されます。性質別に並べ、各項目に誰の体験に効くかを1行ずつ添えます。
新機能・挙動変更
- バージョン範囲の管理設定:
requiredMinimumVersionとrequiredMaximumVersionを管理設定に追加。範囲外のバージョンでは起動を拒否し、承認済みバージョンへ誘導します(社内でバージョンを統制する運用に効きます) /plugin listの追加: 導入済みのプラグインを一覧表示する/plugin listコマンドが加わり、--enabled/--disabledで絞り込めます(複数プラグインを管理する運用に効きます)/btwのコピー操作追加:/btwに「c to copy」のショートカットが付き、回答の生のMarkdownをクリップボードへコピーできます。貼り付け時に書式が保たれます(回答を他所へ持ち出す運用に効きます)- StopフックのadditionalContext対応: StopとSubagentStopのフックが
hookSpecificOutput.additionalContextを返せるようになり、hookエラー扱いにならずClaudeへフィードバックを渡してターンを継続できます(フックで自走を制御する運用に効きます) - Skillsの
$エスケープ: Skillsで\$のエスケープ構文が加わり、コマンド本文で数字の前にリテラルの$を置けるようになりました(金額表記などを含むコマンドに効きます) - MCPのセッションID共有:
--resume時に、stdioのMCPサーバーがhooksやBashと同じCLAUDE_CODE_SESSION_IDを受け取るようになりました(セッションIDで連携するMCP運用に効きます) - 背景更新後のcold restart解消: バックグラウンドのエージェントセッションが背景で新版に更新され、更新後にセッションを開いてもcold restart(冷えた状態からの再起動)を待たなくなりました(常時並走させる運用に効きます)
修正(自動化・CI)
claude -pの永久ハング解消: バックグラウンドのコマンドが終了しないとき最終結果のあとにハングしていた問題を修正。stdinが閉じると結果のおよそ5秒後に背景シェルを停止します(非対話モードの自動化に効きます)- CIでのAPIキー誤要求の修正: Bedrock・Vertex・Foundryで
CI=trueかつAnthropic APIキー未設定時に、claude -pが「ANTHROPIC_API_KEY required」で失敗していた問題を修正(これらのプロバイダーをCIで使う運用に効きます)
修正(サンドボックスと環境)
$TMPDIR上書きの修正: bazelやEDR(端末の脅威検知)保護下のGoワークフローでbashコマンドが失敗していた問題を修正。$TMPDIRがサンドボックス対象だけでなく全コマンドで/tmp/claude-{uid}に上書きされていた、v2.1.154で混入したリグレッションです(bazelやEDR下でビルドする運用に効きます)- WindowsのEEXISTエラー解消: Windowsでsession-envディレクトリが読み取り専用属性、またはOneDrive配下のとき、bashコマンドが「EEXIST: file already exists」で失敗する問題を修正(Windowsで特定の環境を使う運用に効きます)
- 管理設定の適用タイミング修正: 新規の設定ディレクトリでの起動中に管理設定の取得が完了したとき、組織が管理する権限ルールがセッション全体に適用されない問題を修正(管理設定下で初回起動する環境に効きます)
修正(権限・hook条件)
- hookのBash条件の誤発火修正:
if: "Bash(...)"の条件が$()や$VARを含むすべてのBashコマンドで発火していた問題を修正。サブシェルやバッククォート内のコマンドにもマッチするよう絞り込まれました(hookの条件を使う運用に効きます) $HOME経由のdeny抜け穴修正:Read(~/Desktop/**)のようなHomeディレクトリの拒否ルールが、$HOME経由でパスを参照するBashコマンドをブロックしていなかった問題を修正(Homeディレクトリ配下を保護する運用に効きます)
修正(エージェント並走画面とUI)
- 更新後の背景タスク喪失修正:
claude agentsで、Claude Code更新後に再アタッチするとバックグラウンドのタスクが失われる問題を修正(更新を挟んで並走させる運用に効きます) - Esc離脱時のズレ解消: エージェント画面をEscで抜けるときのターミナルのズレと数秒のハングを修正(エージェント画面を頻繁に出入りする運用に効きます)
- 停止済みchipの修正: デスクトップアプリで、バックグラウンドタスクのchipの停止をクリックしても、対象プロセスが既に終了済みのときchipが消えない問題を修正(デスクトップアプリで背景タスクを管理する運用に効きます)
- 貼り付け後の無反応解消: 貼り付けの終端マーカーが端末に取りこぼされたあと、キーボード入力が永久に反応しなくなる問題を修正(貼り付けを多用する運用に効きます)
- 空行残りの解消:
/mcpや/pluginsのようなパネルダイアログを閉じたあと、トランスクリプトに「(no content)」の行が残る問題を修正(パネルを開閉する運用に効きます)
軽微な改善
- コマンド説明の明確化:
/メニューの組み込みコマンドとスキルの説明が分かりやすくなりました(コマンドを補完から探す運用に効きます) - サブスクリプション提案の移動: サブスクリプション切り替えの提案が、トーストではなく起動時のアナウンス枠に表示されるようになりました(起動時の通知が落ち着きます)
- dispatchの開始位置修正:
claude agentsの状態別表示からのディスパッチが、エージェント画面を開いたディレクトリでセッションを開始するようになりました(並走を状態別に管理する運用に効きます)
バージョン固定は「個人の手動」と「組織の管理設定」でどう使い分けるか
本版で加わったrequiredMinimumVersionとrequiredMaximumVersionは、管理設定でバージョンの範囲を縛る仕組みです。これまでもバージョンを揃える手段はありましたが、その多くは利用者一人ひとりの手元の運用に依存していました。本版の管理設定固定は、組織がポリシーとして範囲を定め、範囲外の起動そのものを止められる点が新しいといえます。
両者は目的も効き方も異なります。個人がバージョンを手動で固定するのは、自分の環境を安定させたい・ある版の挙動に依存している作業を続けたいといった、自己完結した動機が中心です。一方の管理設定固定は、検証済みの範囲だけを社内に行き渡らせたい・既知の不具合がある古い版を下限で弾きたいといった、組織全体の統制が目的になります。下の早見表で、どちらの手段がどの場面に向くかを示します。
| 観点 | 個人による手動固定 | 組織による管理設定固定 |
|---|---|---|
| 主な目的 | 個人による手動固定自分の環境の安定 | 組織による管理設定固定社内で承認版の範囲を統制 |
| 効く範囲 | 個人による手動固定自分の端末のみ | 組織による管理設定固定管理設定が配られる全利用者 |
| 範囲外の扱い | 個人による手動固定各自の判断に委ねられる | 組織による管理設定固定起動を拒否し承認版へ誘導 |
管理設定固定は、利用者が範囲外のバージョンをインストールしていても、起動の段階で止めて承認済みのバージョンへ誘導します。個人の手動固定が「自分が選んだバージョンに留まる」運用だとすれば、管理設定固定は「組織が決めた範囲から外れさせない」運用にあたります。社内のバージョン統制を、案内文ではなく仕組みで担保したい場合に向く構成です。
設定は管理設定のファイルに範囲を書く形になります。下限と上限を次のように指定します。
{
"requiredMinimumVersion": "2.1.163",
"requiredMaximumVersion": "2.1.999"
}hook運用者が実は踏んでいた2つの落とし穴
本版は、hookを運用していると気づきにくい2つの落とし穴を同時に直しています。どちらも「ルールや条件を書いたのに、書いたとおりに効いていなかった」類の問題で、運用者が意図せず踏んでいた可能性があります。あわせて、StopとSubagentStopのフックがフィードバックを返せるようになった拡張も、hook運用の幅を広げます。
1つ目の落とし穴は、if: "Bash(...)"条件の誤発火です。これまでは$()のコマンド置換や$VARの変数参照を含むコマンドのすべてで条件が反応していました。本版では、サブシェルやバッククォート内のコマンドにも正しくマッチするよう判定が見直され、条件の対象が絞り込まれます。下のビフォーアフターのとおり、想定より広い範囲で走っていたhookが、書いた条件のとおりに絞られます。
| 局面 | v2.1.162まで | v2.1.163 |
|---|---|---|
$()や$VARを含むコマンド | v2.1.162まですべてで条件が発火 | v2.1.163書いた条件に沿って判定 |
| サブシェル・バッククォート内 | v2.1.162までマッチが正しく効かない | v2.1.163正しくマッチする |
$HOME参照の拒否ルール | v2.1.162までブロックされない | v2.1.163ブロックされる |
2つ目の落とし穴は、$HOME経由の拒否ルール抜け穴です。Read(~/Desktop/**)のようにHomeディレクトリのパスを対象にした拒否ルールが、$HOMEを使ってパスを組み立てるBashコマンドをブロックしていませんでした。表記の違いで保護をすり抜けられる状態だったわけです。本版でこの抜け穴がふさがれ、$HOME経由でも拒否ルールが効くようになります。
加えて、StopとSubagentStopのフックがhookSpecificOutput.additionalContextを返せるようになった点は、hook運用の自由度を上げます。これまでフックからフィードバックを返そうとするとhookエラー扱いになっていましたが、本版ではエラーにならず、Claudeに追加の文脈を渡してターンを継続できます。「終了の前にもう一手続けてほしい」といった制御を、エラーを出さずにフックから伝えられるようになります。
v2.1.160から続く権限・セキュリティ堅牢化の流れ
本版の$HOME抜け穴修正は、単発の修正ではなく、ここ数版で続いている権限・セキュリティ堅牢化の流れの一部として読めます。直前のv2.1.162では、WebFetchの明示ルールが組み込みの自動許可より優先されるようになり、Windowsのバックスラッシュ表記や大文字小文字違いのパスでも拒否ルールが一致するようになりました。本版はその延長で、$HOMEという別経路からの抜け穴をふさいでいます。
この流れを版番号付きで並べると、利用者が書いた権限ルールが「書いたとおりに、どの経路からでも効く」状態へ少しずつ近づいている動きと読めます。表記やパスの組み立て方が違っても拒否ルールが一致する、明示ルールが組み込みの自動許可に勝つ、といった修正が連続して入っています。
なお、本版で混入元が直った$TMPDIRの全コマンド上書きは、v2.1.154で入ったリグレッションでした。サンドボックス対象だけに留めるべき$TMPDIRの置き換えが全コマンドに及び、bazelやEDR保護下のGoワークフローでbashコマンドが失敗していました。本版で対象がサンドボックスに戻り、混入から数版を経て解消した形になります。
利用形態別の影響早見表
本版の影響は利用形態によって大きく異なります。全行が同じ判定にはならないため、自分の運用に近い行だけ確認すれば更新価値を判断できます。
| 利用形態 | 主に効く変更 | 影響度 |
|---|---|---|
| 組織でバージョンを統制したいIT管理 | 主に効く変更管理設定でのバージョン範囲固定 | 影響度明確な恩恵あり(該当時) |
hookでif条件を使う運用 | 主に効く変更Bash条件の誤発火修正、additionalContext対応 | 影響度明確な恩恵あり(該当時) |
| bazelやEDR下でビルドする運用 | 主に効く変更$TMPDIR上書きの修正 | 影響度明確な恩恵あり(該当時) |
claude -pをCIや自動化で使う運用 | 主に効く変更永久ハング解消、CIでのAPIキー誤要求修正 | 影響度条件次第で更新価値あり |
| 個人のローカル単発実行が中心 | 主に効く変更コマンド説明の明確化、起動通知の整理 | 影響度ほぼ影響なし |
組織のバージョン統制、hookの条件運用、bazelやEDR下のビルドでは、本版の中心的な修正がそのまま効きます。claude -pを自動化で回している運用では、バックグラウンドコマンドが残るケースやBedrock・Vertex・Foundryを使うCIで更新価値が出てきます。並走もhookも使わず単発でローカル実行している場合は、コマンド説明の明確化や起動通知の整理が中心で、緊急性は高くありません。
hookのif条件や$HOMEの拒否ルールを書いている運用では、本版で条件やルールの効き方が変わるため、更新後に意図したとおりに発火・ブロックされているか確認しておく価値があります。
まとめ
- 組織でバージョンを統制したいIT管理:
requiredMinimumVersionとrequiredMaximumVersionの管理設定で承認版の範囲を固定でき、範囲外の起動を止めて承認版へ誘導します - hookで
if条件を使う運用:if: "Bash(...)"が$()や$VARを含むコマンドで誤発火していた問題が直り、StopとSubagentStopのフックがadditionalContextでフィードバックを返せるようになります - 拒否ルールでファイルを保護する運用:
$HOME経由でパスを参照するBashコマンドが、Homeディレクトリの拒否ルールでブロックされるようになります - bazelやEDR下でビルドする運用: v2.1.154で混入した
$TMPDIRの全コマンド上書きが直り、bashコマンドが失敗しなくなります claude -pを自動化で使う運用: バックグラウンドコマンド残りによる永久ハングと、Bedrock・Vertex・FoundryでのCI時のAPIキー誤要求が解消します- 個人のローカル単発実行が中心の場合: コマンド説明の明確化や起動通知の整理が中心で、緊急性は高くありません
本版は、直前のv2.1.162が権限ルールの効き方を整えたのに続き、組織向けのバージョン統制と、hook条件や$HOME拒否ルールの効き方の修正を中心に据えた版です。組織でバージョンを管理したい、あるいはhookや拒否ルールを細かく書いている運用では、本版で意図したとおりの挙動に近づくと言えます。
Claude Code全体の機能や使い方を整理して把握したい場合は、Claude Codeとは — エージェント型AIコーディングCLIの完全ガイドもあわせて参照できます。
関連する記事
Claude Code をもっと見る →Claude Code v2.1.152 — /code-review --fixで指摘を作業ツリーに自動適用
Claude Code v2.1.47 — Windows・メモリ周り68項目を整える整備版
Claude Code v2.1.9 — Hookが追加文脈を返せるようになり、長時間セッションのAPIエラーも解消
Claude Code v2.1.3 — Hook実行時間が10分に拡張、到達不能な権限ルールを検出
Claude Code v2.1.0 — Skillが独立した実行ユニットに昇格、Hooksが機能ファイルに同梱可能に
Claude Code v2.1.162 — エージェント並走画面の安定化と、起動の堅牢化