sandbox.allowNestedUserNamespaces とは何ですか？

Claude Code 2.1.305 で加わった、Linux 向けのサンドボックス設定です。サンドボックス内で実行するコマンドが、ユーザー名前空間を作れるようになります。changelog は、Chromium や rootless な podman のように名前空間を作る道具のための設定と説明し、この設定でサンドボックスのファイル保護を回避できるようになると明記しています。回避できる範囲、既定値、設定できるファイルは changelog に記載がありません。

sandbox.allowNestedUserNamespaces は有効にしてよいですか？

changelog が、この設定でファイル保護を回避できるようになると明記しているため、必要なコマンドが実際に失敗してから入れるのが安全です。入れる前に、コマンドをサンドボックスに残したまま書き込み先や接続先を足す allowWrite・allowedDomains で足りないかを見てください。excludedCommands で外に出したコマンドは、ファイルにもネットワークにも制限なしで動きます。回避できる範囲は、changelog にも設定リファレンスにも記載がありません。

enableWeakerNestedSandbox とは何が違いますか？

公式ドキュメントでは、enableWeakerNestedSandbox は特権の無い Docker コンテナー内で、bubblewrap が新しい /proc を mount できないときのための設定です。既定値は false で、セキュリティを下げると明記されています。allowNestedUserNamespaces は、サンドボックス内のコマンドがユーザー名前空間を作るための許可です。2 つを同時に使うときの関係は、公式に記載がありません。

CLAUDE_CODE_RETRY_WATCHDOG_USAGE_LIMIT_RECHECK_MS は何をする環境変数ですか？

CLAUDE_CODE_RETRY_WATCHDOG を設定した状態で、利用上限のリセットを待っているあいだに、上限がすでに解除されていないかを確認する間隔の下限です。解除が見つかると、リクエストはすぐに送られます。値は 60000 から 10800000 までのミリ秒です。未設定か範囲外のときは、再確認をしません。必要なバージョンは 2.1.305 以降です。

利用上限の再確認は、どんな上限でも働きますか？

働きません。公式ドキュメントによると、再確認するのは claude.ai サブスクリプションのセッション上限または週次上限で、使用量クレジットを使っていないときに限ります。CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC を設定している間も再確認しません。再確認しないときは CLAUDE_CODE_RETRY_WATCHDOG の待ち方のままで、試行の間隔を最大 5 分まで空けるか、応答にリセット時刻があればリセットまで待ちます。

tool search が拒否される環境で、2.1.305 は何が変わりますか？

Vertex・Bedrock などのプロバイダーや、tool search を許可しない、または --tools から外しているゲートウェイで、すべてのリクエストが失敗していた 2.1.304 の不具合が直ります。2.1.305 は tool search を外して再試行し、成功すれば利用者は何もしなくてよく、MCP ツールは最初から読み込まれます。後で tool search を再び試すため、拒否されるリクエストが増えます。避けるなら ENABLE_TOOL_SEARCH=false を設定します。

Claude Code

Claude Code 2.1.305｜sandbox.allowNestedUserNamespaces と上限の再確認を整理する

Claude Code 2.1.305 では、Linux のサンドボックス内でユーザー名前空間を作れる設定 sandbox.allowNestedUserNamespaces が加わりました。あわせて、利用上限の解除を再確認する環境変数と、tool search が拒否されたときの再試行も入っています。changelog と公式ドキュメントで確認できる範囲を整理します。

Dodai/ バックエンド / インフラエンジニア·2026年10月21日公開·約 10 分で読めます

#Claude Code#Claude Code 設定#サンドボックス#開発運用

Claude Code 2.1.305｜sandbox.allowNestedUserNamespaces と上限の再確認を整理する

この記事のポイント

sandbox.allowNestedUserNamespaces は、Linux のサンドボックス内のコマンドにユーザー名前空間の作成を許す設定で、changelog にはサンドボックスのファイル保護を回避できるようになると明記されている
回避できる範囲、既定値、設定できる場所は changelog に記載が無い。入れる前に自分の環境で確認する
利用上限の再確認は CLAUDE_CODE_RETRY_WATCHDOG_USAGE_LIMIT_RECHECK_MS で、60000〜10800000 ミリ秒の範囲を指定する
再確認が働くのは、CLAUDE_CODE_RETRY_WATCHDOG を設定していて、claude.ai サブスクリプションの上限に当たり、使用量クレジットを使っていないときだけ
tool search を拒否する Vertex・Bedrock・ゲートウェイですべてのリクエストが失敗していた 2.1.304 の不具合は、2.1.305 の再試行で直る。再試行が通れば利用者は何もしなくてよい

2.1.305 で設定に関わる変更は 3 件

Claude Code 2.1.305 の changelog には、CLI のほか、クラウドセッション、Claude Tag、Code Review の項目まで多くの行が並んでいます。この記事では、Linux でサンドボックスを使っている人と、設定を配る管理者に関係しそうな 3 件に絞ります。

変更	向く人
`sandbox.allowNestedUserNamespaces` の追加	Linux のサンドボックス内で名前空間を使う人
利用上限の解除を再確認する環境変数の追加	無人で長く実行し、上限待ちが出る人
tool search が拒否されたときの再試行	Vertex・Bedrock・ゲートウェイ経由で使っている人

内容は公式の changelog と、サンドボックスの公式ドキュメント、環境変数の一覧、MCP の公式ドキュメントに基づきます。書かれていない点は、その旨を添えます。

先に結論を言うと、判断が要るのは 1 件目だけです。ほかの 2 件は、更新するだけで済むか、使うと決めた人だけ設定すれば足ります。サンドボックスの外側の権限設計は Claude Code の権限と settings.json 設計を参照してください。

sandbox.allowNestedUserNamespaces は、名前空間を作るコマンドを通す許可

changelog には、Linux でサンドボックス内のコマンドがユーザー名前空間を作れるようにする設定、と書かれています。Chromium や rootless な podman のように、自分で名前空間を作る道具を想定した設定です。

同じ行に、この設定でコマンドがサンドボックスのファイル保護を回避できるようになる、と明記されています。どこまで回避できるかは書かれていません。

設定は sandbox の下に書く形です。

{
  "sandbox": {
    "enabled": true,
    "allowNestedUserNamespaces": true
  }
}

どの settings ファイルに書けるか (ユーザー・プロジェクト・managed の別) は、changelog に記載がありません。配る前に、自分の環境で /status と claude doctor を使って読み込まれたかを確認してください。

既存の enableWeakerNestedSandbox とは目的が違う

サンドボックスには、ネストに関わる設定がすでにあります。enableWeakerNestedSandbox は公式ドキュメント、allowNestedUserNamespaces は 2.1.305 の changelog の記載をもとに並べます。

設定	内容
`sandbox.enableWeakerNestedSandbox`	特権の無い Docker コンテナーで、bubblewrap が新しい /proc を mount できないときに、既存の /proc を bind mount する。既定値は false。セキュリティを下げる
`sandbox.allowNestedUserNamespaces`	サンドボックス内のコマンドがユーザー名前空間を作れるようにする。サンドボックスのファイル保護を回避できるようになる

allowNestedUserNamespaces の既定値は、changelog に記載がありません。

enableWeakerNestedSandbox は、サンドボックス自体がコンテナーの中で起動できないときの設定です。allowNestedUserNamespaces は、起動したサンドボックスの中で実行するコマンドが、さらに名前空間を作る場面の許可です。対象が違うため、一方が他方の代わりになるとは、公式に書かれていません。

2 つを同時に入れたときにどう組み合わさるかは、公式に記載がありません。

Ubuntu 24.04 以降では、既定の AppArmor ポリシーが、bubblewrap によるユーザー名前空間の作成を妨げます。この場合は、サンドボックス自体の起動に必要な手当てが先です。公式の「Set up Linux and WSL2」に、確認用の sysctl と AppArmor プロファイルの手順があります。

注意

公式ドキュメントの Limitations は、enableWeakerNestedSandbox について、安全性を大きく下げるため、ほかの隔離が別にある場合にだけ使うよう求めています。この記載が新しい設定にも当てはまるかは書かれていません。ただ、changelog 自身が、新しい設定でファイル保護を回避できるようになると明記しているため、同じ慎重さで扱うのが安全です。

FIXIT

コマンドが失敗するなら、とりあえず入れちゃえばいいの？

Dodai

先に allowWrite か allowedDomains で足りるかを見ます。excludedCommands で外に出すと、ファイルもネットワークも無制限です。

FIXIT

新しい設定のほうは、ファイルの保護を回避できるようになるんだよね。

Dodai

そこは事故ります。必要なコマンドが実際に失敗してから、1 台で試してください。

入れる前の確認

自分なら、次の順で判断します。

失敗しているコマンドと、エラーの内容を記録します。ユーザー名前空間の作成が理由かは、エラーで確認します
書き込み先か接続先が 1 つ足りないだけなら、sandbox.filesystem.allowWrite か sandbox.network.allowedDomains に足して済まないかを見ます。この 2 つなら、コマンドはサンドボックスの中で動いたままです
済まなければ、excludedCommands でコマンドをサンドボックスの外に出すかを検討します。外に出したコマンドは、ファイルにもネットワークにも制限なしで動き、自動承認ではなく通常の権限確認を通ります。公式ドキュメントは、全権を任せてよい道具に限って使うよう書いています
どちらも合わないときだけ、1 台の端末で allowNestedUserNamespaces を入れて実行します
保護したいファイルがあるなら、その保護が残っているかを同じ端末で確認します。どこまで回避できるかは、changelog からは分かりません

4 番目で、全員に配る前に 1 台で試す理由は、回避できる保護の範囲が公式に説明されていないためです。

利用上限の再確認は、無人実行で上限待ちを短くする環境変数

2.1.305 では、環境変数 CLAUDE_CODE_RETRY_WATCHDOG_USAGE_LIMIT_RECHECK_MS が加わりました。無人で再試行を続ける CLAUDE_CODE_RETRY_WATCHDOG と組み合わせて使います。

export CLAUDE_CODE_RETRY_WATCHDOG=1
export CLAUDE_CODE_RETRY_WATCHDOG_USAGE_LIMIT_RECHECK_MS=600000

公式の環境変数一覧で確認できる仕様を表にします。

項目	内容
役割	利用上限のリセットを待つあいだに、上限がすでに解除されていないかを確認する間隔の下限
解除が見つかったとき	リクエストをすぐに送る
値の範囲	60000 (1 分) から 10800000 (3 時間) までのミリ秒。桁区切りなしの整数
再確認の対象	claude.ai サブスクリプションのセッション上限または週次上限で、使用量クレジットを使っていないとき
再確認しない場合	`CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC` を設定している間。未設定か、値が範囲外のとき
必要なバージョン	2.1.305 以降

使う前に、表の「再確認の対象」と「再確認しない場合」に自分が当たるかを確認してください。再確認しないときの待ち方は、CLAUDE_CODE_RETRY_WATCHDOG の説明にあります。試行の間隔を最大 5 分まで空けて再試行し、応答にレート制限のリセット時刻が含まれていれば、リセットまで待ちます。

CLAUDE_CODE_RETRY_WATCHDOG 自体は、公式ドキュメントで無人のセッション向けに再試行の上限を外す変数として案内されています。再確認の間隔は、リクエストごとの待ち時間の上限を決める CLAUDE_CODE_RETRY_WATCHDOG_MAX_WAIT_MS とは別の変数です。

tool search が拒否される環境の失敗は、更新で直る

changelog によると、Vertex・Bedrock などのプロバイダーで、エンドポイントやゲートウェイが tool search を拒否する場合と、tool search を許可しない、または --tools から外しているゲートウェイを通す場合に、すべてのリクエストが失敗していました。changelog は、この失敗を 2.1.304 で入った不具合としています。

2.1.304 には、カスタムの ANTHROPIC_BASE_URL の背後で tool search を既定で有効にし、ゲートウェイが 400 か 422 を返したら tool search を外して再試行する変更がありました。2.1.305 はこの再試行の対象を広げ、エンドポイントやゲートウェイが tool search を拒否した場合にも、tool search を外して再試行します。

MCP の公式ドキュメントによると、2.1.305 以降は、原因を判別できない 400 か 422 のあとに tool search を外して再試行できます。再試行が成功すれば画面には何も出ず、利用者は何もしなくて構いません。そのとき MCP ツールは最初から読み込まれます。

ただし Claude Code は後で tool search を再び試すため、そのたびに拒否されるリクエストが 1 回増えます。ゲートウェイには、拒否されたリクエストと、それに続く再試行が届きます。このリクエストを避けたい場合は、ENABLE_TOOL_SEARCH=false を設定します。

ほかに設定へ影響する 3 件

残りの行にも、設定や運用に関わるものがあります。

変更	影響しそうな人
`allowedMcpServers` が、`env` の中だけに `${VAR}` を使う `managed-mcp.json` の stdio サーバーを絞らなくなった	managed の MCP 設定を配っている管理者
クラウドセッションや SDK の `setMcpServers` で渡した MCP サーバーが、同名の設定ファイルのサーバーに置き換わらなくなった	SDK で MCP サーバーを渡している人
`/artifacts` の削除確認が、1 または Enter で保持、2 で削除、Esc で取り消しになった。`y` と `n` は使えない	`/artifacts` を使っている人

1 行目は、これまで絞られていたサーバーが、更新後に絞られなくなる向きの変更です。changelog は、許可リストから外していたサーバーを止めたままにするなら deniedMcpServers を使うよう書いています。許可リストで管理している場合は、更新後に managed の MCP サーバーの一覧が想定どおりかを確認してください。MCP の設計は Claude Code と MCP の実践パターンも参照してください。

更新の進め方

更新前に、sandbox の設定と、ユーザー名前空間の作成が理由で失敗しているコマンドの一覧を取ります。失敗が無ければ、新しい設定は入れません
失敗があるときは、allowWrite・allowedDomains で足りるかを先に見ます。足りなければ excludedCommands で外に出すかを検討し、それも合わないときだけ 1 台で allowNestedUserNamespaces を試します
無人実行をしているなら、CLAUDE_CODE_RETRY_WATCHDOG を使っているかを確認します。契約の種類が対象に当たる場合だけ、再確認の変数を足します
Vertex・Bedrock・ゲートウェイ経由なら、更新後に tool search まわりの失敗が消えたかを見ます。拒否されるリクエストを避けたいなら、ENABLE_TOOL_SEARCH=false を設定します
managed の MCP 設定を配っているなら、allowedMcpServers の結果を更新前後で比べます

1 番目を飛ばすと、新しい許可を「念のため」で入れてしまい、どのコマンドがファイル保護を回避できる状態なのかを誰も把握できなくなります。

過去の版でサンドボックス周りの設定が変わった経緯は、Claude Code 2.1.299〜2.1.302 の変更の --sandbox 廃止の項と、権限バイパス修正が続いた 3 リリースにまとめています。

FIXIT の運用 — 許可を足す前に、失敗の理由を残す

新しい許可を入れる判断は、設定そのものより、記録の有無で差が出ます。失敗したコマンド、エラー、試した順番を残しておくと、半年後に「なぜこの許可が入っているのか」に答えられます。

サンドボックスの許可を社内の標準にするときは、1 台で試す、記録する、見直す日を決める、の 3 点を手順に入れます。更新のたびに判断し直す負担を減らせます。

設定の標準化と更新運用を社内ルールに落とし込むところで止まっている場合は、AI 開発ツール定着支援をご覧ください。具体的な進め方はお問い合わせからご相談いただけます。AI 駆動開発のクリエイティブスタジオとして、権限設計と更新運用の設計からお手伝いしています。

確認できなかったこと

この記事は、公式の changelog と公式ドキュメントに書かれていることだけで書いています。sandbox.allowNestedUserNamespaces について、次の点は記載が無く、確認できませんでした。

既定値
設定できる場所 (ユーザー・プロジェクト・managed)
回避できるファイル保護の範囲
設定リファレンスでの項目 (取得できた範囲には載っていない)
enableWeakerNestedSandbox と同時に使ったときの関係
カーネルや AppArmor の不具合との関係

自分の環境に当たる項目は、更新後に実際の動作で確認してください。

まとめ

2.1.305 で判断が要るのは sandbox.allowNestedUserNamespaces。名前空間を作るコマンドが実際に失敗し、allowWrite・allowedDomains・excludedCommands で合わないときに、1 台で試す
changelog には、この設定でファイル保護を回避できるようになると明記されている。回避できる範囲、既定値、設定できる場所は記載が無い
enableWeakerNestedSandbox は Docker 内の /proc の問題向けで、目的が別
CLAUDE_CODE_RETRY_WATCHDOG_USAGE_LIMIT_RECHECK_MS は 60000〜10800000 ミリ秒。claude.ai サブスクリプションの上限で、使用量クレジットを使っていないときだけ働く
tool search が拒否される環境ですべてのリクエストが失敗していた不具合 (2.1.304 で入った) は、2.1.305 の再試行で直る。利用者は何もしなくてよく、拒否されるリクエストを避けるなら ENABLE_TOOL_SEARCH=false

この記事を書いた人

Dodaiバックエンド / インフラエンジニア

AWS と Ruby on Rails を軸に、バックエンドとインフラの設計・運用、負荷テストやパフォーマンス改善を担当します。新機能の華やかさより先に「どこで壊れるか」を考えるのが習い性で、障害やデータの取り扱いには慎重です。 AI が書いたコードもテストと検証を通すまで信用しない姿勢で、堅実に動き続けるシステムづくりを大切にしています。

AWSRuby on Railsインフラ負荷テストバックエンド

プロフィールと執筆記事を見る →

FIXIT について

この記事を書いている FIXIT は、Claude Code・Cursor・AI エージェントを実プロジェクトに組み込む、AI 駆動開発のクリエイティブスタジオです。

会社概要開発実績を見る

よくある質問

Q. sandbox.allowNestedUserNamespaces とは何ですか？: Claude Code 2.1.305 で加わった、Linux 向けのサンドボックス設定です。サンドボックス内で実行するコマンドが、ユーザー名前空間を作れるようになります。changelog は、Chromium や rootless な podman のように名前空間を作る道具のための設定と説明し、この設定でサンドボックスのファイル保護を回避できるようになると明記しています。回避できる範囲、既定値、設定できるファイルは changelog に記載がありません。
Q. sandbox.allowNestedUserNamespaces は有効にしてよいですか？: changelog が、この設定でファイル保護を回避できるようになると明記しているため、必要なコマンドが実際に失敗してから入れるのが安全です。入れる前に、コマンドをサンドボックスに残したまま書き込み先や接続先を足す allowWrite・allowedDomains で足りないかを見てください。excludedCommands で外に出したコマンドは、ファイルにもネットワークにも制限なしで動きます。回避できる範囲は、changelog にも設定リファレンスにも記載がありません。
Q. enableWeakerNestedSandbox とは何が違いますか？: 公式ドキュメントでは、enableWeakerNestedSandbox は特権の無い Docker コンテナー内で、bubblewrap が新しい /proc を mount できないときのための設定です。既定値は false で、セキュリティを下げると明記されています。allowNestedUserNamespaces は、サンドボックス内のコマンドがユーザー名前空間を作るための許可です。2 つを同時に使うときの関係は、公式に記載がありません。
Q. CLAUDE_CODE_RETRY_WATCHDOG_USAGE_LIMIT_RECHECK_MS は何をする環境変数ですか？: CLAUDE_CODE_RETRY_WATCHDOG を設定した状態で、利用上限のリセットを待っているあいだに、上限がすでに解除されていないかを確認する間隔の下限です。解除が見つかると、リクエストはすぐに送られます。値は 60000 から 10800000 までのミリ秒です。未設定か範囲外のときは、再確認をしません。必要なバージョンは 2.1.305 以降です。
Q. 利用上限の再確認は、どんな上限でも働きますか？: 働きません。公式ドキュメントによると、再確認するのは claude.ai サブスクリプションのセッション上限または週次上限で、使用量クレジットを使っていないときに限ります。CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC を設定している間も再確認しません。再確認しないときは CLAUDE_CODE_RETRY_WATCHDOG の待ち方のままで、試行の間隔を最大 5 分まで空けるか、応答にリセット時刻があればリセットまで待ちます。
Q. tool search が拒否される環境で、2.1.305 は何が変わりますか？: Vertex・Bedrock などのプロバイダーや、tool search を許可しない、または --tools から外しているゲートウェイで、すべてのリクエストが失敗していた 2.1.304 の不具合が直ります。2.1.305 は tool search を外して再試行し、成功すれば利用者は何もしなくてよく、MCP ツールは最初から読み込まれます。後で tool search を再び試すため、拒否されるリクエストが増えます。避けるなら ENABLE_TOOL_SEARCH=false を設定します。

Next read