Codexのブラウザが使えないときの復旧例

ページは見えるのに、Codexはブラウザを操作できない。同じ端末で起きた「接続先が見つからない不調」と「古いエラー画面が残った不調」は、復旧方法が違いました。確認の順序と、実際に直った範囲をまとめます。

内蔵ブラウザ・Chrome連携・Web検索の違い

「ブラウザで調べて」と依頼したとき、毎回同じ仕組みが使われるわけではありません。まず、どの機能で何ができないのかをそろえると、不要な設定変更を減らせます。

OpenAIのブラウザの公式説明は、デスクトップアプリではCodexが内蔵ブラウザを開き、クリック、入力、画面の確認などを行えるとしています。CLIやIDE拡張そのものに内蔵ブラウザがあるという説明ではありません。どの画面から使っているかを確認するのが最初の分かれ目です。

内蔵ブラウザのプロファイルは普段のブラウザと別です。Chromeの拡張がインストール済みと表示されても、それだけで内蔵ブラウザの操作接続が正常とは分かりません。逆に、内蔵ブラウザが動いても、Chromeの既存タブを自動的に共有するわけではありません（OpenAIのブラウザとプロファイルの説明）。

今回の調査では内蔵ブラウザを優先し、Chromeは別経路の確認に使いました。画面表示、ブラウザへの接続、個別サイトでの操作を一度に「使える・使えない」と判定しないようにしました。

ページは開くのに、Codexから見つからない

発端は、以前できていたブラウザ操作をCodexができないと返すようになったことでした。アプリ設定のブラウザは有効で、Chromeには拡張がインストール済みの表示がありました。さらに、内蔵ブラウザには実際にページを開けました。

ただし操作用のインターフェースから一覧を取得すると、内蔵ブラウザとChromeのどちらも取得できませんでした。見えていたのは別のMCP Apps用の対象だけです。ユーザーに見えている画面と、Codexに渡される操作対象がそろっていない状態でした。

復旧の確認には、画面表示に加えて、Codexからのタブ取得・本文の読み取り・リンク操作をそれぞれ試す必要がありました。

最初に分けたい3つの症状

今回のような接続不調と、特定サイトだけで起きる問題では、確認先が違います。まず、どこまでできるかを分けます。

確認の依頼も「ブラウザを直して」だけでなく、公開ページを開く → 見出しを読む → 表示されたリンクを押す → 元に戻ると具体的にします。検索できたことと、ブラウザのクリック操作が通ったことを取り違えずに済みます。

再読み込みだけで直った、別チャットの例

別の開発チャットでは、ローカルサーバー停止中の「このサイトにアクセスできません」がタブに残っていました。サーバー復旧後も、Codexによるタブ取得は「URLの形式が許可されない」という理由で拒否されていました。

正規のタブ一覧で確認した実URLは、HTMLを直接含むdata:形式でした。利用者が同じタブを通常の再読み込みで更新すると、実URLがHTTPへ戻り、Codexも見出しやボタンを読めました。アプリ全体の再起動や権限変更は不要でした。

これは接続先が一覧に出ない症状とは別です。このチャットで確認できたのは本文の読み取りまでで、ゲームへの入場や本編の操作を検証した結果ではありません。過去に記録された接続経路のエラーの内部原因も未確定です。

今回の復旧までに変えたこと

この端末では、Codexホームの実データはすでにD:\CodexHomeにありました。既定の%USERPROFILE%\.codexはDドライブへのジャンクションでしたが、ユーザー・システム範囲のCODEX_HOMEは未設定でした。

OpenAIが公開しているCODEX_HOMEは、設定、認証、ログ、セッション、スキルなどを置くルートです。今回は、既存のDドライブの実パスを指定する試験に使いました。ブラウザ専用の修復スイッチとして説明されている変数ではありません（OpenAIの環境変数仕様）。

1. アプリと関連するCodexの処理を停止しました。他のチャットの作業が終わったことを利用者に確認し、停止中のデータをバックアップしました。
2. ホームなどをコピーし、内容を確認しました。約68.6GB・445,279ファイルの件数、サイズ、更新日時を比べ、重要な144ファイルはハッシュも比較しました。
3. 一回の起動だけDドライブの実パスを指定しました。同じアプリ版を完全終了後に起動し、シェルと生成された操作用設定がDドライブを参照することを確認しました。
4. 内蔵ブラウザとChromeを別々に試しました。どちらも取得でき、ページの読み取りとリンク操作が通りました。
5. 通常起動でも確認しました。承認後にユーザー環境変数を設定し、タスクバーから起動した新しいアプリでも同じ参照と操作が通りました。

この順序で重要なのは、先にアプリ本体を別ドライブへ移したわけではないことです。ブラウザの復旧は本体の移動前に確認できました。本体の移動中には別の障害も起きたため、「ブラウザを直すためにWindowsのアプリ移動をする」という対処にはつながりません。

また、ジャンクションを削除したり、MCP設定を手で書き換えたりする対処も採用していません。起動後に生成された設定の参照先を読んで、意図した状態になっているかを確認しました。ホームとアプリ本体の違いはCドライブから別ドライブへ移した記録に整理しています。

復旧を判断した操作

復旧後はブラウザが一覧に現れただけで終えず、公開ページを使って実際に操作しました。ここでは利用者のログイン、購入、ファイルのアップロードなどは必要ありませんでした。

Chromeの私的な既存タブ一覧は記事資料に残していません。復旧確認には、新しく作った検証用タブだけで十分でした。「ブラウザを調べる」という目的で、開いているメールや社内サイトまで収集する必要はありません。

保存状態も確認し、ピン留めチャット2件、ピン留めプロジェクト18件、ローカルプロジェクト63件などの指定項目がバックアップ時と一致しました。CLIのログイン状態確認も正常終了しました。ブラウザが直る代わりに履歴やログインを作り直した、という状況ではありません。

一方、アプリ再起動とPC再起動は別です。前者は確認していますが、PC再起動後と将来のアプリ更新後の継続性は、利用者の都合に合わせて後日確認することにしました。今回の結果は、その場の復旧と通常起動の確認までを示します。

先にやらない方がよい対処

原因がブラウザへの接続なのか、サイト側なのか、保存先なのかを分ける前に、アプリデータやブラウザプロファイルを消すと、ログインや設定を失い、比較材料も減ります。今回の復旧では、ブラウザデータの全消去やアプリの再インストールは使いませんでした。

古いブラウザ用スキルを戻す方法も、今回の標準対処にはしていません。調査した端末では、古いスキルがなくなっていること自体が統合されたComputer Useへの移行に伴う状態でした。古いファイルが見当たらないという一点だけで、それを不具合の原因と判断しないことが大切です。

非公開の内部設定、アプリ内のコードのパッチ、実行ファイルの差し替えも採用していません。別の版へ変更すれば復旧したように見えることはあり得ますが、その場合は今回のような同じ版での前後比較とは条件が変わります。

また、内蔵ブラウザとChromeの両方で必要な権限がすでに有効なのに、セキュリティ設定を順に緩める必要もありませんでした。サイトの操作許可と、そのサイトの内容を信頼してよいかは別です。復旧を確認するページは、機密情報や重要な操作のない対象を選びます。

直らないときに残す情報

問い合わせや追加調査には、一般的な「使えない」より、どこまでできるかが分かる記録が役立ちます。今回も、ページ表示は可能、操作対象の取得は不可、復旧後はリンク遷移まで可能、という前後の違いが重要でした。

• アプリ版と、デスクトップ・CLI・IDEのどこで使っているか。
• 内蔵ブラウザとChromeのどちらに症状があるか。
• ページを手で開けるか、Codexが本文を読めるか、クリックできるか。
• 特定サイトだけか、ログイン不要の公開ページでも同じか。
• 完全終了して新しく起動したか。別ドライブやホーム指定を使っているか。
• 発生時刻と、実際に返されたエラー文。秘密の入った生ログは除きます。

ホームの参照先を調べるなら、シェルの$env:CODEX_HOMEだけでなく、Windowsのユーザー範囲の指定と、起動中アプリで使われる値を分けます。独自の保存先を使っていない利用者が、この実例をまねてDドライブの空フォルダを指定する必要はありません。

履歴を開けない、送信だけ失敗するなどの症状は、ブラウザ操作の問題と同じとは限りません。そうした場合は、既存のCodexのthread not foundと履歴の確認方法も、表示される文言に合わせて参照してください。

この実例から使える確認順序

まず利用している場所とブラウザの種類を確認します。サーバーが復旧してもエラー画面が残る場合は、タブを通常の再読み込みで更新します。その後、公開ページで表示・読み取り・クリックを分けて試します。ブラウザ全体の接続がない場合は、作業を保存したうえで完全終了・再起動を検討します。独自のホーム移行をしている端末では、参照先を追加で確認する意味があります。

今回の端末で有効だった組み合わせは「すでに存在するDドライブのホームを実パスで指定すること」と「完全終了後の起動」でした。復旧した事実は残せますが、ジャンクションが唯一の原因だったとは言えません。アプリ本体の移動やデータ削除を万能の修復手順にせず、戻せる範囲で一つずつ確認する方が、作業を続けやすい対処になります。

よくある疑問

ページが見えていれば、Codexも操作できますか？

今回の端末では、ページが見えても操作対象として取得できませんでした。本文の読み取りとリンクのクリックまで確認する必要があります。

Chrome拡張を入れれば内蔵ブラウザも直りますか？

内蔵ブラウザとChrome連携は別の経路です。どちらで失敗しているかを分けて確認してください。今回も両方を個別に試しました。

CODEX_HOMEを指定すれば必ず直りますか？

そのような結果は得ていません。この端末では実パス指定と完全終了・再起動を同時に行い、その後に復旧しました。保存先を変えていない端末まで、ホームの移動を先に勧める根拠にはなりません。

Dドライブへアプリを移さないと復旧しませんか？

ブラウザはアプリ本体の移動前に復旧しました。Windowsのアプリ移動はブラウザ修復とは別の作業です。