Codexにブログのアイキャッチを作ってもらうため、headless Chromeを実行してもらいました。
ウィンドウは出ず、ログに残ったのはbootstrap_check_in ... Permission deniedの1行。
終了コードは134でした。
🎥 この記事の内容は動画でも解説しています。
https://youtube.com/watch?v=w90hoSdYrRk
最初はChromeか画像生成スクリプトの不具合にも見えます。
ところが、同じコマンドをCodexのサンドボックス内外で比べると、外では成功し、中では失敗しました。
原因はアプリではなく、Codexがコマンドを実行する環境の制限でした。
このときの確認手順を、同じエラーで困ったときの切り分けに使える形でまとめます。
CodexのChromeが終了コード134で止まった
2026年9月29日、Codexにブログ用アイキャッチ画像の生成を進めてもらっていました。
生成処理では、HTMLをheadless Chromeで開き、画面を画像として保存します。
ところが、Chromeはスクリーンショットを作る前に落ちました。
エラーログにはbootstrap_check_inとPermission deniedがあり、終了コードは134でした。
同じ時期にAivisSpeechの起動も失敗し、音声生成用のhttp://127.0.0.1:10101にも接続できませんでした。
💡 Tips: headless Chromeとは
画面を人が操作せず、コマンドからWebページを開くChromeです。HTMLからアイキャッチを画像にしたり、ブラウザ表示を自動確認したりするときに使います。
アプリの更新や再インストールを疑うこともできますが、この段階では原因を決められません。
同じパソコンで、実行環境だけを変えて動作を比べることにしました。
同じコマンドをサンドボックスの内外で比べた
Claude Codeに、codex sandbox -- <スクリーンショット処理>で同じ処理を実行してもらいました。
結果は、サンドボックス内で失敗・外で成功。
中ではbootstrap_check_in ... Permission deniedが出て終了コード134、外では終了コード0で画像を保存できました。
さらに、サンドボックス内から127.0.0.1:10101への接続と外部URLへの接続も確認しました。
どちらもつながらず、同じ接続先へサンドボックスの外からアクセスすると成功しました。
ここで変えたのは実行環境です。
Chromeのバージョンや画像生成のコードではありません。
そのため、今回の失敗はChromeや生成スクリプトの不具合ではなく、サンドボックスの制限と判断できました。
原因はCodexのサンドボックスによる制限だった
この環境では、CodexのサンドボックスがmacOSのアプリ登録に必要なMach通信と、ネットワーク接続を制限していました。
Chromiumは起動時にmacOSへプロセスを登録します。
その処理が拒否されると、画面を出す前に起動が止まります。
同じような症状は、Codexの公式GitHubにも報告されています。
PlaywrightからChromiumを起動するとbootstrap_check_inで失敗し、127.0.0.1への接続も拒否されるという報告です。
ただし、これは別の人の環境での事例です。エラーが似ているだけで、すべての終了コード134が同じ原因とは限りません。
Codex公式リポジトリの報告: macOSサンドボックス内でPlaywrightのブラウザとlocalhost接続が失敗する
同じ症状が出たら、実行環境を一つずつ比べる
bootstrap_check_in ... Permission deniedや終了コード134が出たら、まずログを残し、同じコマンドがサンドボックスの外で動くかを確認します。
localhostや外部URLへの接続も、必要な場合だけ内外で比べます。
サンドボックス内でだけ失敗するなら、Chromeの再インストールやコード変更を繰り返す前に、実行環境の制限を疑えます。
一方、外でも失敗するなら、アプリやコマンド自体など別の原因を調べます。
この作業のあと、CodexにChrome、Remotion、AivisSpeechや外部通信を使ってもらうときは、最初から該当コマンドだけ実行許可を求める手順にしました。
サンドボックス全体の設定を広げず、必要な作業の範囲で許可を確認します。
終了コード134だけで故障箇所は特定できません。
同じコマンドを実行環境ごとに比べると、切り分けの手がかりが増えます。
