localhostはリクエストを発行する端末やネットワーク環境を指します。 Codex Cloudがホスト環境からリクエストするなら、http://localhost:3000はその環境を指します。手元のコンピューターでループバックにだけ接続された開発サーバーには届きません。
あるReddit利用者は、プレビューでプロジェクトが使っていないポートが繰り返し開かれたと述べています。設定を変える前に実際の宛先を記録します。
最初に、ブラウザやコマンドがどこで動くかを確認します。そのうえで、手元のブラウザを使う、ホスト環境内でアプリを起動する、または許可済みのプレビューを渡します。TabbitとCodexの比較は製品の役割を説明しています。ネットワークの境界はブラウザの実行場所で決まります。
要点
ポートは、そのアドレスを持つ環境の待受サービスを示します。
ホスト環境のターミナルと手元のブラウザでは、同じURLでも違う結果を受け取ることがあります。
待受アドレスを変えても、手元までの経路は作られません。
実際に使う環境からプレビューを確認します。
200の場合も、対象のインスタンスに固有の目印を見ます。
サーバーを変える前に送信元を確認する
| リクエストの送信元 | localhostが指す範囲 | 最初の確認 |
|---|---|---|
| 手元のブラウザ | 端末のネットワーク | 意図したポートで待ち受けているか |
| ホスト型VMのブラウザやコマンド | VMのループバック | 同じ環境にサービスがあるか |
| コンテナ内のブラウザやコマンド | 通常の分離モードではコンテナのネットワーク名前空間 | サービスが内側か外側か |
| HTTPSプレビューを開くブラウザ | プレビューのドメインが実際の宛先 | アクセス、ビルド、期待する結果 |
IANAは 127.0.0.0/8 をループバックに分類しています。OpenAIは、Codex Cloudが独自のインターネットとプライベートネットワークの設定を持つホスト環境だと説明しています。手元のネットワークへのアクセスを継承しません。IANAレジストリ、OpenAIクラウド環境、ワークスペース管理。
どのプロセスがリクエストしたかを考えます。外部のツールが手元の許可済みブラウザを動かすなら、HTTPリクエストはそのブラウザから出ます。ホスト環境内でブラウザを起動すれば、送信元はその環境です。仮想ブラウザガイドとブラウザエージェントの概要も参照してください。
同じアドレスで異なる応答を確認する
ローカル実験では、MacホストとApple Virtualizationで動かしたAlpine Linuxゲストを使いました。ホストのNodeサーバーは 127.0.0.1:61616 で host-loopback を返しました。ゲストで同じアドレスを開くと最初は接続拒否でした。ゲストの同じポートで別の待受を開始すると guest-loopback が返り、ホストの結果は変わりませんでした。
| 送信元 | その環境のサービス | 結果 |
|---|---|---|
| Macホスト | ホスト側 | host-loopback |
| Alpineゲスト | なし | Connection refused |
| Alpineゲスト | ゲスト側 | guest-loopback |
| ゲスト側が起動した後のMac | ホスト側 | host-loopback |
同じMac上で動く独立したネットワークを使った実験です。ゲストに外部ネットワークアダプターはありませんでした。ここで確認したのはループバックの分離です。Codex Cloudの実行やリモートプレビューの動作は検証していません。
分離されたVMやコンテナで再現できます。空いているポートを選び、ホストでNodeを起動したまま、別のターミナルでcurlを実行します。次にゲストでも同じURLを使います。
node -e "require('node:http').createServer((_, res) => res.end('host-loopback\n')).listen(61616, '127.0.0.1')"
curl --noproxy '*' -fsS http://127.0.0.1:61616/probeゲストでは応答を guest-loopback に変えて同じコマンドを実行し、結果を比べます。コンテナのホストネットワークモードは設定によって名前空間を共有するので、実験では分離された環境を使います。host.docker.internal はDocker Desktopのホスト接続用です。Dockerのネットワーク資料を参照してください。
アプリとブラウザをどこで動かすか
| 目的 | 最初の選択 | 確認すること |
|---|---|---|
| 手元の開発サーバーを確認 | 同じ端末の許可済みブラウザ | 正しいポートとローカルビルド |
| ホスト環境で統合テスト | タスク内でテストサーバーを起動 | クライアントと待受が想定ネットワークにある |
| クラウドからテスト版を見る | 許可されたHTTPSプレビュー | リモートからの到達とビルド |
| プライベートサービスへ接続 | 組織が許可した経路 | ID、経路、ドメイン、権限 |
手元の画面を確認するなら、同じ端末でブラウザとサーバーを動かします。OpenAIのデスクトップブラウザガイドにローカルアプリの開き方があります。Tabbit Browserでも、手元のテストページを開いて許可された操作を行えます。Tabbitの仕組みも参照してください。 別の確認ではTabbit TangoでテストURLをTabbit Browserに開き、期待したローカルの目印を読み取れました。
リモートプレビューではテスト用コピーを用意し、アクセスする人を限定します。到達、認証、ネットワークポリシーはそれぞれ確認します。HTTPSの200はサービスが応答したことを示します。期待したビルドや画面の表示も照合します。
エラーが出た側で切り分ける
「Connection refused」は、多くの場合、送信元から見たアドレスとポートに待受がない状態です。タイムアウト、ポリシー拒否、認証画面、証明書エラーは別の確認が必要です。送信したツール、機密情報を除いた宛先、エラー、期待したインスタンスを記録します。ブラウザのデバッグガイドでは文書とデータ要求を分けて確認しています。
ローカルのPython環境を使う開発者は、Codexのどの処理が手元とクラウドで行われるか質問しました。障害時はコマンド、ブラウザ、サーバーを別々に確認します。
選択したURLと、公開できる識別情報をエージェントに報告させます。表示を確認するだけなら、最初は読み取りだけにします。最初の作業のチェックリスト、ブラウザ自動化ガイド、安全ガイドも参照できます。必要なテスト版に届く最小の経路を選び、そこから応答が返ったと確かめます。
よくある質問
Codex Cloudから手元のlocalhostを開けますか？
クラウド側からlocalhostに送るリクエストはホスト環境内に留まります。手元で動く許可済みブラウザを使うか、必要な環境でアプリを起動するか、許可済みのプレビューを用意します。
Codexがブラウザを開くと、どこのlocalhostになりますか？
リクエストを送るプロセスの環境です。手元のブラウザは手元のループバックを使います。ホスト環境内のブラウザやコマンドは、その環境のループバックを使います。
0.0.0.0で待ち受けるとCodex Cloudからアクセスできますか？
同じ環境内の待受インターフェースが増えます。クラウドから手元への経路やアクセス権が作られるわけではありません。
host.docker.internalはCodex Cloudから手元を指しますか？
Docker Desktopのコンテナが自分のホストにアクセスするための名前です。ホスト型Codex環境から自分の端末へつながる共通の経路ではありません。
リモートプレビューを使うのはいつですか？
クラウド側のブラウザやコマンドで、配置されたテスト用コピーを見るときです。同じ実行環境からアクセスとビルドの識別情報を確認します。
意図したサーバーに届いたか、どう判断しますか？
最終URL、応答、インスタンスやビルドに固有の目印を照合します。別のサービスも同じポート番号で200を返せます。