sandbox

変更前

サンドボックス化が有効な環境で、サンドボックス外で実行されるBashコマンドにおいて $TMPDIR が空の文字列として展開されていた。これは、Linux環境では親シェルで $TMPDIR が未設定の場合が多く、サンドボックス内コマンド向けの設定ロジックがサンドボックス外のコマンドにも影響していたためと考えられる。

変更後

サンドボックス化が有効な環境で、サンドボックス外で実行されるBashコマンドにおいて $TMPDIR が正しく展開されるようになり、親シェルの設定が引き継がれる。

ユーザーへの恩恵

サンドボックス外で実行されるコマンドが正しい一時ディレクトリを参照できるようになり、一時ファイルを扱うコマンドがエラーなく動作する。

変更前

複合コマンドの一部だけが sandbox.excludedCommands の glob パターンに一致しても、コマンド全体がサンドボックス外で実行されていた。

変更後

設定例では sandbox.excludedCommands の ls * が複合コマンドの一部に一致しただけで、コマンド全体がサンドボックス外で実行されていた。修正後は各部分が個別にチェックされ、すべての部分がリストのエントリに一致した場合のみコマンド全体がサンドボックス外で実行される。

ユーザーへの恩恵

複合コマンドの一部だけが除外リストに一致した場合でもコマンド全体がサンドボックス外で実行されなくなり、サンドボックス設定の精度が向上する。

変更前

Bedrock、Vertex、Foundry では Bash サンドボックスに関する説明が独自の記述になっており、サンドボックスの位置づけが first-party ドキュメントの表現と異なっていた

変更後

Bedrock、Vertex、Foundry 向けの Bash サンドボックスの説明が、サンドボックスを「そのタスクに与えられた境界」として表現する first-party の説明文に置き換わる

ユーザーへの恩恵

クラウドプロバイダ経由でもサンドボックスの説明がドキュメントと同じ基準の記述になり、挙動や境界の理解がドキュメントどおりに統一される

変更前

Linux 上で zsh をシェルとして使う環境では、サンドボックス化された Bash コマンドが失敗しても終了コード 0(成功)として報告されていた。

変更後

bash/zsh 問わずサンドボックス内でコマンドが失敗した際には、実際の終了コードが正しく Claude Code に伝わるようになった。

ユーザーへの恩恵

ユーザーは zsh 環境でもコマンドの失敗を見逃さず、Claude Code に確実に失敗を認識させて対処させることができる。

変更前

サンドボックス化された Bash コマンドは、保護されたパスとして扱われるため、プロジェクトディレクトリ内に hooks/ や config/ という名前のディレクトリが存在する場合、それらへの書き込みが拒否されていました。

変更後

サンドボックス化された Bash コマンドが、プロジェクトディレクトリ内の hooks/ や config/ という名前のディレクトリにも書き込めるようになりました。

ユーザーへの恩恵

ユーザーはサンドボックス環境でも、hooks/ や config/ ディレクトリへの書き込みを必要とするビルドやツールの実行が問題なく行えるようになります。

変更前

サンドボックス付きの自動モードでは、コマンドが必要とするホストがコマンド実行時に個別にレビューされ、承認されたホストへのアクセスはセッション全体で許可される仕組みだった。許可の対象はコマンド単位ではなく、同じホストへの以後の接続も自動的に許可される状態だった。

変更後

自動モードのサンドボックス環境で、コマンドごとに allowed_domains で許可ホストを指定できるようになり、Bash・PowerShell・Monitor の各コマンド実行時に必要なホストだけがそのコマンドのために開かれる。指定されていない他のホストへのアクセスは拒否される。

ユーザーへの恩恵

ホストの許可がコマンド単位で閉じるため、悪意あるコマンドが承認済みホストを横流しして外部アクセスするリスクが減る。

変更前

Linux環境でサンドボックス化コマンドの起動に失敗すると、処理の途中で古い.git/config.lockが残されてしまい、その後セッションを終了するまでgit checkout -b、git push -u、git configなどのgitコマンドがロック競合によって失敗し続けていた。

変更後

Linux環境でサンドボックス化コマンドの起動に失敗した後も、残された古い.git/config.lockが原因で、同じセッション内でのその後のgit checkout -bやgit push -u、git configの実行がエラーで失敗するままだった。この修正により、起動に失敗した際にロックファイルが適切にクリーンアップされ、セッション内の後続のgitコマンドが正常に完了するようになった。

ユーザーへの恩恵

サンドボックス起動エラーの後にgitコマンドがブロックされることがなくなり、セッションを再起動せずにそのまま作業を続けられるようになる。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

管理対象設定でサンドボックス化が必須とされている組織では、クラウド上で実行される Cowork の予約タスクが起動時に失敗していた。

変更後

サンドボックスを必須とする管理対象設定がある環境でも、クラウド上の Cowork 予約タスクが起動時に失敗しなくなった。

ユーザーへの恩恵

ユーザーはサンドボックス必須のポリシー環境下でも Cowork の予約タスクを問題なく実行できるようになり、ポリシーとの両立が容易になる。

変更前

サンドボックス内で pbcopy などのクリップボードコマンドが失敗しても、Claude は /copy を提案せず、ユーザーはクリップボードが更新されない理由を自力で突き止める必要があった。

変更後

サンドボックス内で pbcopy などのクリップボードコマンドが失敗したとき、Claude が /copy コマンドの利用を提案するようになった。

ユーザーへの恩恵

ユーザーはクリップボードが反映されない問題に悩まず、Claude の提案に従って /copy を実行するだけで出力をクリップボードにコピーできる。

変更前

コネクタ承認やサインインリンクの承認待ちをしている間、リモートセッションのサンドボックスコンテナが余計に起動し続けていた。

変更後

リモートセッションでも、コネクタ承認やサインインリンクの待ちが発生してもサンドボックスコンテナが維持され、応答後に操作を続行できる。

ユーザーへの恩恵

不要なコンテナの起動時間が減り、クラウドリソースを節約できる。

変更前

Windows の AppContainer や制限付きトークンのサンドボックス内で Claude Code を実行すると、Read・Write・Edit がすべてのファイルに対して「symlink resolution changed after permission was checked(権限確認後にシンボリックリンクの解決が変わりました)」というエラーを出して拒否していました。サンドボックスの制約により権限確認に必要な情報が取れず、シンボリックリンクが変更されたと誤検知していたためです。

変更後

AppContainer や制限付きトークンのサンドボックス内で実行した場合でも、Read・Write・Edit ツールがすべてのファイルを拒否しなくなりました。アクセス権の確認が失敗しても、実際にシンボリックリンクが変更されたケースと区別して判定します。従来はこの環境で権限チェックを正常に完了できず、すべてのファイル操作が拒否されていました。

ユーザーへの恩恵

サンドボックス環境でもファイルの読み書きや編集が通常どおり行えるようになります。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

macOS でも permissions.blockReadsOutsideWorkingDirectories が正しく機能し、サンドボックス化された git コマンドからユーザーの git config を保護し、worktree 分離されたサブエージェントも自身のチェックアウトに問題なくアクセスできる。

変更後

permissions.blockReadsOutsideWorkingDirectories が有効な環境でサンドボックス内の git コマンドがユーザーの git config を読めず、worktree 分離されたサブエージェントも自身のチェックアウトを参照できずに動作しなかった。

ユーザーへの恩恵

macOS ユーザーはファイル読み取り制限を有効にしても git 操作や worktree 分離されたサブエージェントが正常に動作するようになる。

変更前

サーバー管理設定で配信される CLAUDE.md(claudeMd)を適用する際、セキュリティ承認ダイアログが表示され、ユーザーの承認が必要だった。

変更後

サーバー管理設定で配信される CLAUDE.md(claudeMd)は、セキュリティ承認ダイアログを表示せずに適用される。

ユーザーへの恩恵

管理者が配信した CLAUDE.md の内容をユーザーが承認なしですぐに受け取れるようになる。

変更前

厳格サンドボックスモード(sandbox.allowUnsandboxedCommands: false)を有効にすると、Claudeによるコマンドだけでなく、! bashモードプロンプトからユーザーが入力したコマンドもサンドボックス内で実行されるため、サンドボックスの制約によって一部のコマンドが失敗していました。

変更後

これまで、厳格サンドボックスモード(sandbox.allowUnsandboxedCommands: false)が有効な場合、! bashモードプロンプトから入力したコマンドはサンドボックス内で実行されていました。この変更により、!プロンプトから入力されたコマンドは、!経由のbashモードコマンドはユーザー自身のターミナルで実行するのと同等であるため、厳格サンドボックスモードに関係なく、サンドボックスの外で実行されるようになりました。

ユーザーへの恩恵

! bashモードで入力したコマンドは、あたかも自分自身のターミナルで直接実行するかのように、サンドボックスの制約を受けずに動作するようになります。

変更前

セッションを強制終了させた際、一時ファイルとして残ったマスクファイルが古くなっていても、Claude Code はそれを検知しませんでした。

変更後

セッションを強制終了させた際、一時ファイルとして残ったマスクファイルが古くなっていると、/doctor コマンドがそれを検知して警告を表示するようになりました。

ユーザーへの恩恵

ユーザーは /doctor を実行することで、意図せず残った古いマスクファイルを容易に発見し、セキュリティリスクを回避できます。

変更前

サンドボックス内で example.com. というドメインをブロックリストに追加しても、実際にはブロックされず、また「今後は尋ねない」を選択しても次回の接続時にプロンプトが表示され続けていました。

変更後

サンドボックス内で example.com. というドメインをブロックリストに追加すると、正しくブロックされ、また「今後は尋ねない」を選択してもプロンプトが表示されなくなりました。

ユーザーへの恩恵

ユーザーは、末尾のドット付きドメイン名をブロックリストに追加しても、誤ってプロンプトが表示される心配がなくなります。

変更前

サンドボックス化された git コマンドを実行中に、リンクされた git worktree 内のサブディレクトリに移動すると、その後の操作でリポジトリの共通 .git ディレクトリへの書き込みが拒否されることがありました。

変更後

サンドボックス化された git コマンドを実行中に、リンクされた git worktree 内のサブディレクトリに移動しても、リポジトリの共通 .git ディレクトリへの書き込みアクセスが維持されるようになりました。

ユーザーへの恩恵

リンクされた git worktree 内でサンドボックス化された git コマンドを、サブディレクトリ間を移動しても正常に実行できるようになります。

変更前

以前は「merge」モードにおいて、sandbox.credentials.awsPairs と sandbox.ripgrep は複数の管理ソースから値を結合していました。これにより、最上位のソースで設定されていない場合に、下位のソースの値が反映されることがありました。

変更後

現在は「merge」モードにおいて、sandbox.credentials.awsPairs と sandbox.ripgrep は、それらを設定した最上位の管理ソースからそのまま取得されます。下位のソースの値は無視されます。

ユーザーへの恩恵

設定の優先順位が明確になり、意図した管理ソースの設定のみが適用されるようになります。

変更前

以前は、サンドボックス内でコマンドを実行した際、Bash コマンドの出力ファイルが作成され、サンドボックス化されたコマンドによってリダイレクトまたは置換される可能性がありました。

変更後

現在は、サンドボックス内でコマンドを実行した際、Bash コマンドの出力ファイルの作成と読み取り方法が変更され、サンドボックス化されたコマンドがそれらをリダイレクトまたは置換することができなくなりました。

ユーザーへの恩恵

サンドボックス化されたコマンドが意図せず出力ファイルを改ざんするのを防ぎます。

変更前

以前は、サンドボックス TLS を終端する、サンドボックストラフィックを独自のプロキシ経由でルーティングする、認証情報を注入する、またはサンドボックスの分離を弱めるサーバー管理設定は、適用前に承認を求めずに適用されていました。

変更後

現在は、サンドボックス TLS を終端する、サンドボックストラフィックを独自のプロキシ経由でルーティングする、認証情報を注入する、またはサンドボックスの分離を弱めるサーバー管理設定は、適用前に承認を求めるようになりました。

ユーザーへの恩恵

セキュリティリスクの高い管理設定が誤って適用されるのを防ぎます。

変更前

Bash サンドボックスの後処理コマンドは、サンドボックスの書き込み可能領域外に再ポイントされたドットファイルマネージャーが管理する ~/.claude/settings.json のシンボリックリンクを削除していました。

変更後

Bash サンドボックスの後処理コマンドは、サンドボックスの書き込み可能領域外に再ポイントされたドットファイルマネージャーが管理する ~/.claude/settings.json のシンボリックリンクを削除しなくなりました。

ユーザーへの恩恵

ドットファイルマネージャーを使用しているユーザーは、設定ファイルのシンボリックリンクが意図せず削除される心配がなくなります。

変更前

サンドボックス外のネットワークリクエスト許可プロンプトが表示されている間、Notification フックがトリガーされず、通知が届かない状態でした。

変更後

サンドボックス外のネットワークリクエスト許可プロンプトが表示されている間も、Notification フックが正しくトリガーされるようになりました。

ユーザーへの恩恵

許可プロンプト待機中の通知も確実にユーザーに届くようになります。

変更前

コマンドサンドボックスのファイルシステム設定が --setting-sources オプションを無視して、意図した設定が適用されない状態でした。

変更後

コマンドサンドボックスのファイルシステム設定が --setting-sources オプションを正しく尊重し、指定された設定ソースに基づいて動作するようになりました。

ユーザーへの恩恵

ユーザーは --setting-sources を使用して、サンドボックス内のコマンドに対するファイルシステムのアクセス制御を正確に制御できるようになります。

変更前

ブロックされたコマンドが終了コード 0 で終了した場合、Bash ツールの結果からネットワーク違反の詳細が削除されていました。

変更後

ブロックされたコマンドが終了コード 0 で終了した場合でも、Bash ツールの結果にネットワーク違反の詳細が含まれるようになりました。

ユーザーへの恩恵

ブロックされたコマンドの実行結果から違反の詳細を確認できるようになり、トラブルシューティングが容易になります。

変更前

起動時にサンドボックスと MCP の初期化が最初のフレームをブロックし、ベア起動ではサブコマンドの登録が行われ、ワークフロー検出や設定、信頼ストアの処理に時間がかかっていました。

変更後

起動時にサンドボックスと MCP の初期化が最初のフレームをブロックしなくなり、ベア起動ではサブコマンドの登録がスキップされ、ワークフロー検出、設定、信頼ストアの処理がより効率的になりました。

ユーザーへの恩恵

Claude Code の起動が高速になり、特にベア起動やスクリプト実行のパフォーマンスが向上します。

変更前

サンドボックス化された Bash ツールのプロンプトには許可されたネットワークホストの一覧が表示されており、未リストのホストはブロックされていると仮定されていました。

変更後

プロンプトからホストの一覧が削除され、Claude は未リストのホストをブロックとみなさず、リクエストを試みます。新しいホストが必要な場合はユーザーが承認できます。

ユーザーへの恩恵

許可されていないホストへのアクセスを試みる際に、ユーザーが新しいホストを承認できるようになります。

変更前

Git の拡張設定（extensions.worktreeConfig）が有効な状態で Linux のサンドボックス機能（bubblewrap等）を利用すると、本来存在しないはずの個別ワークツリー用ファイルを保護しようとして不適切なマウント操作が行われ、サンドボックス内で git status などのコマンドが一切通らなくなっていました。

変更後

ファイルの存在チェックが適正化され、.git/config.worktree が存在しない場合は保護対象から外します。これにより、サンドボックスが作動している最中であっても、通常通りあらゆる git コマンドを実行させることができます。

ユーザーへの恩恵

ワークツリーを多用する開発リポジトリでも、サンドボックス保護をかけた状態で不自由なく git 操作をエージェントに任せられます。

変更前

セルフホストされたサンドボックス環境でManaged Agentsを動かす際、WebSearchツールやWebFetchツールでの独自ドメイン設定や、セッションをまたぐメモリ保存領域を適切に連動させて制御する仕組みが不足していました。

変更後

同梱の「claude-api」スキルがアップデートされ、組織固有のセルフホスト環境であっても、Web検索・取得のアクセス許可ドメイン設定やメモリ保存機能が正しく適用されるようになります。

ユーザーへの恩恵

セルフホスト環境のサンドボックスから、セキュリティポリシーに沿った安全なWeb検索やメモリ機能を利用できるようになります。

変更前

長時間のやり取りでコンテキスト圧縮が発生すると、以前に承認または処理が完了していたサンドボックスコマンドのネットワークアクセス情報がリセットされ、同一の確認と拒否が無限ループして処理が滞ることがありました。

変更後

圧縮後もサンドボックス環境におけるネットワークアクセスの評価状態が正しく引き継がれ、無駄な再評価やコマンド拒否のループが発生しなくなります。

ユーザーへの恩恵

長いセッションの途中で、すでに解決したはずのネットワークアクセス許可に関するエラーやプロンプトへの対処を何度も強いられることがなくなります。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

ゲートウェイや管理者から管理設定（managed settings）がプッシュされた際、表示されるセキュリティ承諾ダイアログの文言が不明瞭で、かつ大量の低レイヤーなOpenTelemetry設定が並んでいて何を承認しているか見通しが悪い状態でした。

変更後

実際にアクセスされるサーバーのURLが明確に表示され、テレメトリ専用の変更時には文言がマイルドになり、開発者に関係のない通常のOpenTelemetryオプションを省略表示します。また、sandbox.ripgrepなどのサーバー指定のサンドボックスプログラムの書き換え時には厳格に承認を求めます。

ユーザーへの恩恵

社内管理者からセキュリティ設定が適用される際、何が変更されどこにデータが送信されるかを、無駄な技術ノイズに惑わされることなく一目で安全に判断して承認できるようになります。

変更前

プロジェクトのGitリポジトリ内にコミットされた .claude/settings.json の中に、悪意あるローカル実行バイナリを指定するパスが混入していた場合、サンドボックスがシステム検索（ripgrep）を実行した瞬間にその偽バイナリが実行されてしまうセキュリティリスクがありました。

変更後

開発者が信頼してインストールしたユーザー設定（~/.claude）、あるいは社内管理者から配信されたポリシー以外、プロジェクトリポジトリ内の設定ファイル（.claude/settings.json）による検索エンジンのバイパス指定を一切無視します。

ユーザーへの恩恵

インターネットからクローンしてきた見知らぬパブリックGitリポジトリを開いてClaude Codeを動かす際、プロジェクト設定に仕込まれた不正な検索ツール指定によってPCが乗っ取られる危険がなくなります。

変更前

IPv6 アドレスの記述解釈が曖昧であったり、安全性の判定がグレーな書き方のネットワークアクセス規制ルールがすり抜けて許可されてしまう懸念がありました。

変更後

IPv6 表記の標準化と、解析が疑わしいドメインルールを徹底してブロックする fail-closed 方式が採用され、/doctor による検証で事前に不備を検出できます。

ユーザーへの恩恵

サンドボックスの通信制御設定ミスによる意図しない外部ネットワーク漏洩を未然に防ぐことができます。

変更前

サンドボックス環境でパスワードやAPIトークンなどの秘匿情報を保護する際、環境変数を完全に隠す（deny）とツールが動作しなくなり、単純に値を置換するだけの通常のマスキングではJWTのペイロード内部の特定のクレームだけを隠したり、AWS SigV4署名を保ちつつ再署名したりする高度な保護ができませんでした。

変更後

正規表現を用いて構造化ファイルから特定トークンだけを切り出すextractや、JWTをデコードして特定のクレーム値を隠す仕組み、さらにはプロキシ経由でAWS SigV4リクエストを書き換えて再署名する高度なセキュリティオプションが導入されます。これらはリポジトリ内の個別設定ファイルからは設定できず、ユーザーがコントロールする信頼された設定ソースからのみ有効化されます。

ユーザーへの恩恵

ツールに必要な認証情報の利便性を損なうことなく、認証ファイルやトークン内の本当に保護すべき重要な情報だけを確実に隠蔽または安全に中継できるようになります。

変更前

サンドボックスのファイルシステム保護設定で、ディレクトリパスの末尾にスラッシュを指定して読み取り拒否（denyRead）などのルールを定義すると、パス文字列の不一致によりサンドボックス内のシェルコマンドがその制約をすり抜けてアクセスできてしまうセキュリティ上の穴がありました。

変更後

パスの末尾にあるスラッシュが適切に処理され、記述されたパターンに関わらず指定したディレクトリ配下へのアクセスがLinuxおよびmacOS上のサンドボックス内で完全にシャットアウトされるようになります。

ユーザーへの恩恵

セキュリティ設定ファイルのパスの書き方による偶発的な制限の漏れがなくなり、機密ファイルが含まれるディレクトリを確実に保護できます。

変更前

ワークフロー機能用のスクリプトが隔離されたサンドボックス内で実行される際、動的な import() 構文を利用することで、制限をバイパスして意図しないホスト環境の外部コードを読み込んで実行できる危険性がありました。

変更後

動的 import() を経由したサンドボックス外のコード実行が適切にブロックされ、ワークフロースクリプトの実行環境が強固に分離されます。

ユーザーへの恩恵

外部の未検証なスクリプトをワークフローとして実行する際も、ローカル環境を侵害されるリスクを心配せずに安全に実行できます。

変更前

サンドボックス環境内で認証情報にアクセスさせるには、ファイルを完全に露出させるか、ツールを失敗させるかの二択でした。

変更後

サンドボックス内でダミーの認証情報を読み込ませつつ、外部通信時にはプロキシ経由で本物の値を注入できるようになりました。

ユーザーへの恩恵

認証情報ファイルの実体をサンドボックス内に露出させずにツールを実行できます。

変更前

大きなファイルをアップロードしようとすると、TLS通信の制限によりプロセスが中断されていました。

変更後

プロキシを通じたTLSトラフィックの処理が最適化され、アップロードが正常に完了するようになりました。

ユーザーへの恩恵

大きなサイズのファイルを安定してサーバーへアップロードできます。

変更前

サンドボックス環境からのネットワークアクセス制御が緩やかで、意図しない通信が発生する可能性がありました。

変更後

設定したホワイトリスト以外の通信を即座に遮断できるようになりました。

ユーザーへの恩恵

許可リストを定義するだけで安全な通信環境を維持できます。

変更前

一部のコマンド操作がIDE経由で実行された際、サンドボックスの適用範囲が過剰に制限されていました。

変更後

IDE操作とサンドボックスの境界が最適化され、利便性が向上しました。

ユーザーへの恩恵

IDEを通じた操作がサンドボックスによって予期せず制限される機会が減ります。

変更前

ファイルシステムを隔離しようとすると、常に制限が強制されていました。特定の環境で柔軟な運用が難しい状態でした。

変更後

新しい設定項目により、ファイルアクセスの制約を外しつつネットワーク出口の制御のみを適用できるようになりました。

ユーザーへの恩恵

ファイルシステム隔離の制限を気にせず、ネットワーク環境の制約がある場所での操作を完結できます。

変更前

入力待ちの状態でも「Working」と表示され、本当に作業中か確認が必要でした。

変更後

ユーザーの介入が必要な状態が明確に区別されます。

ユーザーへの恩恵

どのセッションがユーザー対応を待っているか、即座に見分けることができます。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

サンドボックス環境下では、Apple Events を介したアプリケーション連携が制限されていました。

変更後

この設定を有効にすることで、安全性を維持しつつ Apple Events の送信が可能になりました。

ユーザーへの恩恵

サンドボックス環境でも Apple の自動化機能を活用したワークフローを構築できます。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

.claude/skills や .claude/hooks を共有フォルダへのシンボリックリンクとして構成している Linux 環境では、セキュリティサンドボックスが正しく初期化できずエラーになっていました。

変更後

シンボリックリンクを適切に解決してサンドボックスを起動できるようになりました。

ユーザーへの恩恵

設定ファイルを複数の場所で共有・管理している開発環境でも、セキュリティ機能を有効にしたまま安全に Claude Code を利用できます。

変更前

設定ファイルをシンボリックリンクで管理している Linux 環境において、セキュリティサンドボックスが正しく初期化できず起動に失敗していました。

変更後

絶対パスのリンク先も正しく認識されるようになり、柔軟なファイル管理構成でもサンドボックス機能を利用できます。

ユーザーへの恩恵

設定ファイルをドットファイル管理ツールなどで共有している高度なユーザーでも、安全な実行環境を維持できます。

変更前

すべてのコマンドで一時ディレクトリが強制的に変更されていたため、Bazel などの厳格な環境でパスの不整合によるエラーが発生していました(v2.1.154 のデグレ)。

変更後

環境に応じた適切な一時ディレクトリ設定が維持されるようになり、ビルドツール等の動作を妨げません。

ユーザーへの恩恵

特定のビルドシステムやセキュリティツールを使用している複雑な開発プロジェクトでも、Claude Code が正常に動作します。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

毎回の起動時に画面を占有する定型メッセージが表示され、ターミナルの表示領域を圧迫していました。

変更後

起動画面がすっきりと簡素化され、重要な情報は必要な時だけ確認するスタイルに変わります。

ユーザーへの恩恵

起動がより軽快に感じられ、すぐに本題のプロンプト入力に移れるようになります。

変更前

サンドボックスが有効なツール呼び出しと、そうでないシェル実行(!コマンドなど)の間で一時ファイルの場所が一致せず、作成したファイルが見つからないなどの混乱が生じることがありました。

変更後

セッションを通じて一貫した一時ディレクトリが使用されるようになり、サンドボックスの境界を越えてもファイル参照が正しく行われます。

ユーザーへの恩恵

AIが生成した一時的なスクリプトやログファイルを、ユーザーが直接コマンドで確認したりデバッグしたりする作業がスムーズになります。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

ワイルドカードを使用した広範な allowedDomains 設定を行っている場合、その範囲内の特定のドメインだけを拒否することが困難でした。

変更後

拒否リスト(deniedDomains)が許可リストより優先されるようになり、細かいネットワーク制御が可能になりました。

ユーザーへの恩恵

広域な許可を与えつつ、特定の機密ドメインや不要なドメインへのアクセスを確実に遮断できるため、セキュリティが向上します。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

システム起動直後など、サンドボックスが必要とする一時ディレクトリが準備できていない状態でコマンドを実行するとエラーが発生することがありました。

変更後

サンドボックスの初期化処理が改善され、再起動後でも最初のコマンドから安定して動作します。

ユーザーへの恩恵

サンドボックスの利用に伴う不安定さが解消され、安全な実行環境を意識せずに使い続けられます。

変更前

AIが実行するサブプロセスからホスト側のプロセス情報が見えてしまったり、悪意のあるプロンプトによって無限にスクリプトが実行されたりするセキュリティ上の懸念がありました。

変更後

OSレベルでのプロセス隔離が強化され、また1セッション内でのスクリプト実行回数に上限を設けることができるようになりました。

ユーザーへの恩恵

AIにコマンド実行権限を与える際の安全性が高まり、プロンプトインジェクション等による情報の漏洩やリソースの枯渇リスクを大幅に低減できます。

変更前

サンドボックス環境下で特定の macOS 固有サービス(iOSシミュレータなど)と連携させるための設定が、実質的に無視されていました。

変更後

設定したMachサービスへのアクセスが正しく許可され、サンドボックス内から高度なシステム連携が可能になりました。

ユーザーへの恩恵

安全性を保ちつつ、シミュレータの操作やOS機能を利用したテストなどの開発作業をサンドボックス内で完結できます。

変更前

macOS特有のサンドボックス機構(Seatbelt)において、一部のネットワーク関連のルックアップ制限が設定通りに適用されないケースがありました。

変更後

OSレベルのセキュリティ設定がより厳密に制御され、設定した隔離ポリシーが確実に反映されるようになりました。

ユーザーへの恩恵

macOS上でのエージェントの動作をより安全に、かつ意図した範囲内に制限でき、セキュリティリスクを低減できます。

変更前

一部の環境でサンドボックスの制約が不十分になり、本来制限すべき Unix ソケット通信が許可されてしまうケースがありました。

変更後

セキュリティ機能が強化され、サンドボックス内で実行されるコマンドの通信制限がより厳密に適用されます。

ユーザーへの恩恵

悪意のあるスクリプトや予期せぬ挙動からローカルシステムを保護する能力が高まり、安全性が向上します。

変更前

サンドボックスが有効に設定されていても、依存関係の不足やプラットフォームの制限で起動できない場合、Claude Code は警告を表示した上でサンドボックスなし(保護なし)の状態でコマンドを実行してしました。

変更後

sandbox.failIfUnavailable を true に設定することで、サンドボックスを起動できない場合にプロセスをエラーで停止させることができるようになりました。これにより、意図しない非保護状態での実行を防げます。

ユーザーへの恩恵

厳格なセキュリティポリシーを必要とするエンタープライズ環境において、安全性が確認できない状態でのコマンド実行を確実に阻止できるようになり、セキュリティガバナンスが強化されます。

変更前

サンドボックス保護下で複数のコマンドをパイプでつなぐと、プロセスの通信制御の問題によりデータが正しく流れず、検索結果が正しくカウントされないなどの不具合がありました。

変更後

サンドボックス内のプロセス間通信(パイプ処理)のハンドリングが修正され、通常のシェルと同じように複雑なコマンド列を実行できるようになりました。

ユーザーへの恩恵

安全なサンドボックスを利用しながらも、パワフルなシェルコマンドを制限なく活用したコード分析が可能になります。

変更前

サンドボックス設定画面において、キーボード操作で設定項目やタブ間を移動しようとしてもフォーカスが正しく切り替わりませんでした。

変更後

標準的なキーボードショートカット(Tab や矢印キー)によるタブ移動や項目の選択が、意図通りに動作するようになります。

ユーザーへの恩恵

マウスを使わずにキーボードだけでサンドボックス構成を素早く変更でき、開発の流れを止めずにセキュリティ設定を管理できます。

変更前

Linux のサンドボックス環境で Git 操作を行うと、「引数が曖昧」というエラーが出たり、不要なファイルが Git ステータスに表示されたりしていました。

変更後

サンドボックス内での Git コマンドの互換性が修正され、作業ディレクトリを汚さずに正確なログ確認やステータス表示が可能になりました。

ユーザーへの恩恵

Linux ユーザーがセキュリティ機能を有効にしたままでも、ストレスなく Git ワークフローを継続できます。

変更前

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

変更後

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

ユーザーへの恩恵

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

変更前

macOS でサンドボックス設定を確認した際、不要な Linux 用パッケージ(bubblewrap など)のインストールを促される混乱がありました。

変更後

OS を正しく判別し、macOS では標準の Seatbelt フレームワークが使用されることが正しく表示されるようになりました。

ユーザーへの恩恵

ユーザーが自分の環境に合った正しい情報を得られるようになり、セットアップの迷いが解消されます。

変更前

サンドボックス設定が有効でも、必要なツールがない場合に無言で機能がオフになっており、セキュリティ上の死角となっていました。

変更後

起動時に依存関係の不足を明示的に警告するようになり、安全な状態であるかどうかを確実に把握できるようになりました。

ユーザーへの恩恵

設定したセキュリティ境界が機能していないことに気づかないまま作業を続けるリスクを回避できます。

変更前

特定のディレクトリへのアクセスを denyRead で制限した場合、そのサブディレクトリを個別に読み取り許可する手段がありませんでした。

変更後

allowRead 設定を使用することで、読み取り拒否された広範なパスの中から特定のサブパスだけを安全に許可できるようになりました。

ユーザーへの恩恵

サンドボックスのセキュリティ制限を維持しつつ、必要なファイルへのアクセスだけをピンポイントで許可できるため、柔軟な環境構築が可能です。

変更前

リスト項目内のカーソル移動や展開を行おうとすると、意図せず画面上部のタブが移動してしまう操作の競合がありました。

変更後

リスト操作とタブ切り替えのキーバインドが整理され、意図した通りのナビゲーションが可能になりました。

ユーザーへの恩恵

設定画面での誤操作が減り、必要な項目を素早く探し出して変更できるようになります。

変更前

安全な場所(/tmp/claude/ など)への書き込みや、サンドボックス内で完結するはずの操作において、不必要な承認プロンプトが表示されることがありました。

変更後

サンドボックスの権限判定が最適化され、許可されたディレクトリ内でのファイル操作やリダイレクトがよりスムーズに行えるようになりました。

ユーザーへの恩恵

セキュリティを維持したまま、細かなファイル操作に伴う承認プロンプトの回数が減り、作業効率が向上します。

変更前

ヒアドキュメントを含むコマンドや環境変数プレフィックス付きのコマンドなど、特定のパターンにおいてパーミッション設定が正しく適用されない場合がありました。

変更後

コマンドラインの解析ロジックが強化され、複雑な形式のコマンドに対しても設定した許可・拒否ルールが正確に機能するようになりました。

ユーザーへの恩恵

「常に許可」や「常に拒否」の設定が期待通りに働くようになり、セキュリティ設定の信頼性が向上します。

変更前

サンドボックスのネットワーク隔離が厳格すぎて、Go言語で書かれたCLIツールがカスタムCA証明書を介したプロキシ環境で証明書エラーを起こすことがありました。

変更後

macOSの信頼された証明書サービスへのアクセスを許可するオプションが追加され、企業プロキシ環境下でもこれらのツールが正常に動作するようになります。

ユーザーへの恩恵

社内ネットワーク制限がある環境でも、terraform や gcloud といった必須のインフラ操作ツールをClaude Codeから安全に実行できます。

変更前

サンドボックスが環境設定を読み込む際、作業ディレクトリに実体のないゴーストファイルが生成され、Gitのクリーンな状態を乱していました。

変更後

ファイルの分離が適切に行われるようになり、開発環境のGit状態に不要なファイルが混入しなくなりました。

ユーザーへの恩恵

Gitステータスを汚すことなくサンドボックスの安全な実行環境を利用でき、コミット時の混乱を防げます。

変更前

macOS のサンドボックス環境でカスタムプロキシを使用すると、Go 言語で書かれたツールが証明書の検証に失敗し、ネットワーク通信が必要なコマンドが実行できないことがありました。

変更後

ネットワークの隔離レベルをわずかに調整するオプションが提供され、セキュリティを維持しつつ、企業内プロキシ環境などでも Go 製のツールが正しく動作するようになりました。

ユーザーへの恩恵

企業独自のネットワーク環境下でも、gh コマンドによる PR 作成や terraform によるインフラ操作を Claude に安全に実行させることができます。

変更前

組織レベルで許可ドメインを制限している場合でも、制限外のサイトへアクセスしようとするとユーザーに承認を求めるプロンプトが出てしまい、管理ポリシーをバイパスできてしまう余地がありました。

変更後

ポリシーで制限されている場合はプロンプトすら出さずに即座に遮断されるようになり、管理者の意図通りの厳格な制限が適用されるようになりました。

ユーザーへの恩恵

企業におけるセキュリティポリシーの強制力が向上し、ヒューマンエラーによる機密情報の流出リスクを低減できます。

変更前

サンドボックス化された環境でzsh heredocを使用すると、「read-only file system」エラーが発生し、コマンドが失敗する問題がありました。

変更後

サンドボックス化されたコマンドでzsh heredocが「read-only file system」エラーを起こす問題が修正されました。

ユーザーへの恩恵

サンドボックス環境でのzsh heredocの利用が改善され、より多くのシナリオでシェルコマンドの実行が容易になりました。

変更前

以前は、サンドボックスモードで動作しているClaude Codeが、許可なく.claude/skills ディレクトリにファイルを書き込む可能性がありました。これにより、セキュリティ上の懸念や、予期せぬ変更が発生するリスクがありました。

変更後

今回の変更により、サンドボックスモードでは、Claude Codeが.claude/skills ディレクトリにファイルを書き込むことができなくなりました。これにより、サンドボックスの隔離性が強化され、不必要なファイル操作が防がれます。

ユーザーへの恩恵

ユーザーは、サンドボックス環境でのセキュリティが向上し、Claude Codeが意図しないスキルファイルを作成・変更するリスクがなくなります。これにより、より安全で予測可能な開発環境を維持できます。

変更前

以前は、サンドボックス機能を使って自動承認されるように設定されたBashコマンドの一部が、意図せず権限の要求なしに実行される可能性がありました。これは、特定のコマンドがサンドボックスから除外されるように設定されている場合に発生し、セキュリティ上の脆弱性となる恐れがありました。

変更後

今回の修正により、autoAllowBashIfSandboxed 設定が有効な環境でも、サンドボックスから除外されたコマンドは適切にBashの権限要求ルールに従うようになりました。これにより、除外設定されたコマンドであっても、ユーザーの許可なく勝手に実行されることはありません。

ユーザーへの恩恵

この修正により、サンドボックスのセキュリティモデルが強化され、より安心してClaude Codeを利用できるようになります。意図しないコマンドの実行を防ぎ、システムへのアクセスを厳密に制御できるため、セキュリティリスクが低減されます。

変更前

LinuxやWSL2環境でサンドボックス機能を有効にする際、bubblewrapやsocatといった必要な依存関係が不足している場合、ユーザーは手動でそれらのインストール方法を調べて設定する必要がありました。/sandboxコマンドのUIは、このプロセスを明確にガイドするものではありませんでした。

変更後

/sandboxコマンドを実行した際に、必要な依存関係が不足している場合は、そのステータスとプラットフォームに応じた具体的なインストール手順がUIに表示されるようになりました。これにより、ユーザーはスムーズにサンドボックス機能を設定できるようになります。

ユーザーへの恩恵

これにより、LinuxやWSL2ユーザーはサンドボックスのセットアップが大幅に簡素化されます。不足している依存関係を特定し、インストール方法を調べる手間が省け、Claude Codeのサンドボックス環境を迅速かつ容易に利用開始できるようになります。