この日の更新は、Claude Code が「確認なしで実行してよい操作」の境界を明文化する内容に集まっています。bypassPermissions モードでの rm の扱い、worktree 削除時のリンクの扱い、sandbox の除外コマンドと権限モードの関係が主な論点です。env-vars、permission-modes、hooks、sandboxing、routines、headless、worktrees の 7 ページが対象です。
bypassPermissions でも出る rm の確認を、環境変数で外せるようになった
permission-modes ページによると、bypassPermissions モードでも、重要パス（critical path）を対象にした rm や rmdir は確認または拒否の対象です。新たに CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 を起動環境に置くと、この確認を外せることが記載されました。必要バージョンは v2.1.311 以降です（2026-10-28 時点の記載）。
適用範囲は狭く書かれています。確認が外れるのは bypassPermissions モード自体の中だけで、plan モードでは外れません。対象は Bash と Monitor ツールで重要パスと判定されたものに限られます。Claude Code が完全には解析できないコマンドも、確認なしで実行される側に含まれます。ドキュメントは次のように警告しています。
you lose a safety prompt for destructive deletes: a command such as rm -rf ~ can run without asking you
（出典 [2]）
（訳：安全確認がなくなり、rm -rf ~ のようなコマンドが確認なしで実行され得ます。）
隔離され、中身を失っても構わない環境でのみ使う前提です。CI やコンテナで bypassPermissions を使っている運用では、設定するかどうかを明示的に判断する項目が増えました。
変数を置いても効かない条件が列挙された
同じページには、変数が効かないケースがまとまっています。まず読み込み経路です。
Claude Code reads the variable from the launch environment only and ignores it in a settings file's env block
（出典 [2]）
（訳：Claude Code はこの変数を起動時の環境からのみ読み取り、設定ファイルの env ブロックでは無視します。）
そのほかの原因として、次のものが挙げられています。
- PermissionRequest フックや --permission-prompt-tool など、別の仕組みが権限確認を処理している
- Bash、Edit、Read を対象にした deny または ask ルールがある
- permissions.blockReadsOutsideWorkingDirectories が有効になっている
- claude が別セッションの中から起動されている
- VS Code 拡張のチャットパネルや Desktop アプリがセッションを動かしている
- バックグラウンドセッションなど、Claude Code 側が起動するセッションは変数なしで始まる
- 管理設定や Windows レジストリが読めない
起動時に Claude Code が出力する 1 行で、変数が有効かどうかを確認できます。-p 実行では stderr に出ます。Agent SDK では stderr オプションを渡さないと、この行を読めません。行が見えないことは確認が有効という意味ではなく、確認なしで実行され得る状態でも行が出ない場合があります。
中断した tool call の再開と無人実行向けの変数
env-vars ページには、再開と無人運用に関わる変数も加わりました。CLAUDE_CODE_RESUME_SHOWS_CUT_OFF_CALLS を 1 にすると、中断された tool call を「cut off」の印付きで残したまま、CLAUDE_CODE_RESUME_INTERRUPTED_TURN が続行するターンに含められます。未設定では、これらの呼び出しはターン続行前に破棄されます。ただし 1 にしても、次の呼び出しは残りません。
Some calls stay dropped, such as calls to subagents, skills, workflows, and tools that wait on a person
（出典 [1]）
（訳：サブエージェント、スキル、ワークフロー、人の応答を待つツールの呼び出しなど、一部の呼び出しは破棄されたままです。）
CLAUDE_CODE_EXIT_AFTER_STOP_DELAY は、クエリループが idle になってから自動終了するまでの待ち時間をミリ秒で指定します。CLAUDE_CODE_RETRY_WATCHDOG は、評価ハーネス、CI、リモートワーカーなどの無人セッション向けに 1 を設定する変数です。追加された文には動作の詳細がなく、挙動は不明です。
worktree の削除でリンクをどう扱うか、承認ルールをどこに保存するか
hooks ページと worktrees ページでは、worktree 削除時の安全側の挙動が追記されました。リポジトリにコミットされた symlink で worktree の位置を外部へ向けられる可能性があるため、バックグラウンドセッションの削除では、フック実行前に保存済みの worktree パスを検証します。
refusing a path that is a symlink or passes through one below the repository root
（出典 [3]）
（訳：リポジトリルート以下に symlink があるパス、または symlink を経由するパスは拒否します。）
ファイルが残る worktree でフックが走るのは、agent view で削除を確認した場合だけです。それ以外では claude rm はセッションと worktree を残します。worktrees ページには、worktree 内のフォルダが NTFS junction やディレクトリ symlink の場合、リンクだけを削除すると書かれています。
承認ルールの保存先も明記されました。worktree セッションで Bash コマンドに "Yes, and don't ask again" を選ぶと、ルールはメインチェックアウトの .claude/settings.local.json に保存されます。
The rule applies in the main checkout and in every other worktree of the repository, and it survives the worktree's removal
（出典 [7]）
（訳：ルールはメインチェックアウトとリポジトリの他のすべての worktree に適用され、worktree を削除した後も残ります。）
worktree 単位で承認したつもりのルールが、リポジトリ全体に及ぶことになります。
sandbox の除外コマンドと権限モードの組み合わせ
sandboxing ページでは、除外コマンドのエントリが権限フローにどう乗るかが書かれました。読み取り専用のコマンドと allow ルールが覆うコマンドは確認なしで動き、auto モードでは分類器が他の除外コマンドを審査します。bypassPermissions モードでは次のとおりです。
In bypassPermissions mode, an excluded command runs without a prompt unless an ask rule matches it
（出典 [4]）
（訳：bypassPermissions モードでは、ask ルールに一致しない限り、除外コマンドは確認なしで実行されます。）
また、sandbox が admin-required の間は、.claude/settings.json と .claude/settings.local.json のエントリが無視されます。git clone の除外エントリは、絶対パス、~ で始まるパス、.. を含むパスの clone をカバーしません。
その他の更新
- routines：モデル選択の Default オプションには、effort level の選択肢がありません。
- headless：fork されたスキルのメッセージがストリームに出る最小バージョンは、v2.1.86 から v2.1.287 まで種別ごとに異なります。
- headless：不正な MCP 設定で skip されたエントリは、stderr を捕捉する環境では警告が出ず、mcp_server_errors フィールドだけで報告されます。
- worktrees：「fresh」な base では、24 時間以内に fetch していなければ既定ブランチを fetch します。上限は 5 秒（2026-10-28 時点）で、失敗時はローカルのキャッシュ済み ref を使います。
- worktrees：git replace を使うリポジトリでは、worktree のファイルに置換前の内容が入ります。置換後が必要なら git worktree add で自分で作成します。
- worktrees：エージェント実行中は git worktree lock が保持され、終了時に解除されます。
この日の更新から言えること
影響が大きいのは、CI やコンテナで bypassPermissions を使っている運用者です。rm の確認を外す手段は用意されましたが、起動環境でしか読まれず、フック、deny ルール、入れ子のセッションなど多くの条件で無効になります。起動時の 1 行の確認が必要になりました。worktree を多用する運用では、削除時のリンクの扱いと、承認ルールがリポジトリ全体に及ぶ点を把握しておく必要があります。いずれもドキュメントの記載に基づく整理で、実際の挙動の検証は含みません。
出典
本稿の引用はすべて一次資料と逐語照合（verify_article 通過）のうえ掲載しています（2026-11-03 検証）。
[1] https://code.claude.com/docs/en/env-vars
[2] https://code.claude.com/docs/en/permission-modes
[3] https://code.claude.com/docs/en/hooks
[4] https://code.claude.com/docs/en/sandboxing
[5] https://code.claude.com/docs/en/routines
[6] https://code.claude.com/docs/en/headless
[7] https://code.claude.com/docs/en/worktrees