CIでPlaywrightを動かしていると、テストコードではなくChromiumの起動で止まることがあります。特にLinuxのコンテナやrootless Podmanでは、サンドボックスとユーザー名前空間の条件がぶつかります。
今回はClaude Code v2.1.305で追加されたsandbox.allowNestedUserNamespacesを、無人のE2E実行でどう考えるか整理します。
Chromiumのサンドボックスは何を守っているのか
Chromiumのサンドボックスは、ブラウザプロセスがOS上でできることを制限する境界です。もしページ側のJavaScriptやブラウザのバグをきっかけにプロセスが悪用されても、ホスト全体へ届きにくくする役割があります。
そのため、CIで起動しないからといって、いきなり--no-sandboxを付けるのは最後の手段です。テストを通すために保護機能を外すと、失敗の原因は消えても実行環境の前提が変わってしまいます。
ユーザー名前空間の入れ子で何が起きるか
Linuxのユーザー名前空間は、プロセスが見えるユーザーや権限の範囲を分離する仕組みです。rootlessコンテナの中で、さらにChromiumがサンドボックスを作ろうとすると、名前空間の入れ子が必要になる場合があります。
ここでホストやコンテナの設定が許可していないと、Chromiumはテスト開始前に終了します。Playwrightのpage.goto()まで到達しないので、テストの失敗ログだけ見ていると原因を見落とします。
allowNestedUserNamespacesは何を許可する設定か
Claude Code v2.1.305のリリースノートでは、Chromiumやrootless Podmanのように、サンドボックスの内側でユーザー名前空間を使うケースに関係する設定として説明されています。
大事なのは、この設定を「安全機能を無効にするスイッチ」と読み替えないことです。名前空間の入れ子を許可することと、サンドボックスを完全に外すことは別の話です。ただし、許可範囲を広げる変更なので、共有CIランナーでは管理者と影響範囲を確認してください。
Playwrightの前に確認する順番
では、テストがChromium起動直後に落ちる時の確認順をまとめます。
- まず実行場所を確認します。ホスト上か、Dockerか、rootless Podmanかで条件が変わります。
- 次に、Chromiumの起動ログからsandboxやnamespaceに関するエラーを探します。
- 同じイメージを使って、テストではなくブラウザ起動だけを再現します。
- ホスト管理者の許可が得られるなら、ユーザー名前空間の入れ子を許可します。
- それでも必要な場合だけ、サンドボックスを外す選択肢を検討します。
この順番なら、テストの都合でセキュリティ境界を雑に外したのか、実行環境が本当に必要な分離を提供していないのかを分けられます。
設定を足す前に記録するもの
無人実行では、次の3つをログに残すだけで後の切り分けが楽になります。
- 使用したコンテナイメージとChromiumのバージョン
- rootlessかどうか、ユーザー名前空間を使っているか
- 変更前後の起動ログと、Playwrightの最小再現コマンド
「設定を足したら通った」だけでは、次にランナーを変えた時にまた止まります。環境の前提を書いておく方が、テストコードを何度も疑うより安いです。
まとめ
sandbox.allowNestedUserNamespacesは、Chromiumやrootlessコンテナの起動条件を調整するための設定です。--no-sandboxで一気に保護を外す前に、名前空間の入れ子が必要な実行環境なのかを確認しましょう。
Playwrightのテストが始まる前に落ちているなら、テストコードではなくブラウザの境界を見ます。ここを切り分けるだけで、CIの赤いログが少し読みやすくなりますね。
参考: Claude Code v2.1.305リリースノート、PlaywrightをGitHub Actionsで自動実行する記事、Claude Codeサンドボックスの資格情報保護の記事
コメント