Codex CLIでChrome接続に失敗、Desktopでは成功：Windows 10での切り分け記録

11月 14, 2026

2026年11月14日、Windows 10の同じPCで、Codex CLIからはChromeに接続できず、Codex Desktopからは接続できた。CLI側はブラウザの一覧取得より前に失敗した一方、Desktopでは既存のWordPressログインセッションを利用して投稿一覧と編集画面を開けた。

これはモデルの回答品質を比べた実験ではない。ブラウザへ接続する実行環境と経路の切り分け記録であり、CLI側の根本原因は未確定、修復も未実施である。

発端：WordPress更新をCLIに任せたかった

WordPressの更新をCodex CLIに任せようとしたところ、Chromeへの接続で止まった。それ以前には、Claude CodeとClaude in Chromeで既存記事を更新できていた。

同じPCにChrome拡張が入っているのにCodexだけ失敗するため、拡張の有無、Native Messaging Hostの登録、プラグイン設定、実行経路を読み取り専用で調べた。その後、Desktop側で公開ページから順番に試した。

検証環境：診断時点の実測値

以下は2026年11月14日のローカル診断報告で確認した値である。最新版の案内ではなく、接続できなかった時点の構成を示す。Desktop成功後に全項目を再採取したわけではない。

PATH上のCLIと、今回の診断ツールを実行したdaemonは同じ版ではなかった。ただし、この版の相違だけで原因とは判断していない。更新やdaemon停止による比較試験も実施していない。

CLIではページを開く前に失敗

ブラウザ一覧取得とChrome選択のどちらも、次のエラーになった。

The browser access host is unavailable

この段階ではexample.comにも到達していない。Web検索やHTTP取得でページを読めても、それをChrome操作の成功には数えていない。

診断で確認できたことは次のとおり。

• Chrome拡張の登録が存在した。登録ファイルだけでは、実行時の有効状態やサイト許可まで証明できない。
• Native Messaging Hostの登録、manifest、参照先実行ファイルが存在し、許可対象と署名の整合性も確認できた。実通信の成功は未確認だった。
• browser関連プラグインは有効設定で、関連ファイルも存在した。
• ツール用PowerShell子プロセスでは、ブラウザ接続用情報が未設定だった。親daemonや実際のブラウザツールの環境全体を読み取ったわけではない。
• インストール済みサービスには、接続用情報が足りないと同じエラーを返す分岐があった。

これらから、CLI／共有daemon側でDesktop用の接続コンテキストが成立していない可能性を有力候補とした。ただし、どの親子プロセス間で欠けたか、版の相違が関係したかは不明である。

また、診断時点ではChromeとDesktopのGUIプロセスが検出されていなかった。追加の前提不足ではあるが、「Chromeを起動するだけで直る」とは確認していない。接続識別子の流用、認可処理の改変、Cookieの移送は行っていない。

公式資料とGitHub Issueを分けて読む

2026年11月14日にOpenAIのBrowser公式資料を再確認した。同資料は内蔵BrowserをCLI／IDEでは利用できないと案内し、通常ブラウザとは別プロファイルであることを説明している。Browser extension公式資料は、デスクトップアプリから拡張を使い、既存のログイン状態があるサイトを操作する経路を案内している。これは独立CLIの認証付き接続を修復できるという説明ではない。提供範囲は環境や展開状況にも依存する。

指定した3件のIssueも実在と状態を再確認した。公式リポジトリのIssueであっても、利用者の報告をそのまま公式仕様や修復保証として扱わない。

Issue内のコミュニティ回避策は、今回適用していない。登録が揃っていることと、認可された接続経路が成立することは別の確認項目だった。

Desktopでは公開ページから段階的に成功

次に、既存のCodex DesktopチャットからChromeを指定し、https://example.com/ を開いた。Chrome拡張経由でページを表示し、タイトル「Example Domain」を取得できた。

続いて既存のWordPress管理タブに接続し、再ログインや資格情報の移送をせず、次の確認ができた。

• 投稿一覧を表示した。
• 投稿ID 1191「GitHub Learning Lab」と2054「Thunderbirdで、Gmailが受信できなくなった」が、いずれも公開済みであることを確認した。
• 投稿1191の編集画面を開き、タイトルと公開状態を確認した。本文入力や保存はしていない。
• Windows上の更新用HTMLを読み、冒頭と末尾を確認した。
• 同じCodexチャット内でブラウザ操作とローカルファイル読み取りを実行できた。

ここまでの段階では、WordPressへの書き込みはまだ未検証だった。編集画面を開けたことだけでは、本文入力・保存・公開の成功までは言えない。

CLIとDesktopで確認できた範囲

この差をモデルの性能差に置き換えることはできない。今回直接確認した違いは、ブラウザツールへ到達する経路と、そのセッションで利用できた機能である。

実用上は作業を使い分ける

今回の環境では、コード開発やローカル調査はCodex CLI、既存Chromeを使うブラウザ作業はCodex Desktopという使い分けができる。ただしCLIのブラウザ接続障害は解決済みではなく、別環境でもDesktopが必ず成功するという保証はない。

再確認する場合は、拡張を入れたChromeプロファイルを使い、Desktopの新しいチャットから公開ページの表示とタイトル取得を試し、その後にログイン済みサイトの閲覧へ進むと、失敗した段階を区別しやすい。設定変更や再インストールを最初から重ねる前に、公式手順で接続できる範囲を確認する。

この記事自身の投稿実験

この記事はCodex Desktopのブラウザ操作で、新規下書きから公開まで進める実験として作成した。原稿はローカルで先に完成させ、既存記事を変更しない方針で作業している。

2026年11月14日、Codex Desktopの既存Chrome接続を利用し、この記事（投稿ID 4519）で新規下書き作成、HTML本文入力、下書き保存、保存後の本文照合、PC幅とスマートフォン幅390pxの実ブラウザプレビュー、公開、公開URLでの表示確認に成功した。タイトル・主要な技術説明・出典リンク・カテゴリーとタグを確認した。購読者へのメール送信はこの記事だけオフにし、既存記事やサイト全体の設定は変更していない。公開後の表示確認を終えてから、この結果段落だけを追記する最小限の更新を行った。

公開後の結果は、実際に確認できた工程に限って記録する。CLI障害の根本原因、他のPC・ブラウザ・OSでの再現性、長期的な自律運用の安定性は、この1件では検証できない。