Codex「Work browser access requires an authenticated account」

Codex デスクトップアプリで送信すると「メッセージの送信中にエラーが発生しました」の下に英語で Work browser access requires an authenticated account と出る場合や、過去のチャットを開くと「チャットの再開に失敗しました」の下に同じ英文が出る場合、原因はアプリ自身のチェックです。26.1013 以降のアプリは、Work モード（左上のメニューで「ChatGPT Work」を選んだ状態）でローカルのブラウザー操作の実行環境をチャットに付けるとき、アプリにサインインした ChatGPT アカウントを求めます。API キーや CC Switch などの中継ツールで使っているとそのアカウントがないため、ブラウザーを使わない普通のメッセージも含めてチャットそのものが始まりません。中継サーバーや回線の障害ではなく、同じ設定の Codex CLI はそのまま動きます。

送信を戻すいちばん早い方法は、左上のモードメニューを「ChatGPT Work」から「Codex」に切り替えて新しいチャットを始めることです。メニューで戻せない、どのチャットも開けないときは、アプリを完全に終了してから ~/.codex/config.toml の [desktop] にある conversationDetailMode を "STEPS_COMMANDS" に書き換えます。どちらも Work モードは手放すことになります。Work を残したいなら、アプリに ChatGPT でサインインし、モデルへのリクエストだけを中継に流す（CC Switch のルーティングモード）しかありません。

ChatGPT アカウントがなく、Work モードのブラウザー操作がどうしても必要な場合、2026年10月23日時点で手元で直す方法はありません。OpenAI の Codex リポジトリの報告 openai/codex#54841 は未解決のままです。下の条件と対処は、同じ日に macOS のアプリ 26.1016.62342 のプログラムを読んだ結果と GitHub 上の利用者の報告に基づいています。

Work browser access エラーが出る 4 つの条件

2026年10月23日に、macOS 26.1 にインストールされた ChatGPT デスクトップアプリ 26.1016.62342（Codex を含むアプリ）のプログラムを読むと、このエラーはチャットに付けるツールの構成を組み立てる処理の中で出ます。この処理はチャットを始めるとき、新しいチャットにメッセージを送るとき、過去のチャットを再開するときに走り、4 つの条件がすべてそろうと処理を止めます。チャットがこのパソコン上で動いていること、Work モードであること（設定 conversationDetailMode の実効値が "STEPS_PROSE"）、ローカルのブラウザー／コンピューター操作の実行環境である node_repl というツールサーバーがチャットに付いていること、そしてアプリに ChatGPT アカウントの身元（アカウント ID とユーザー ID）が保存されていないこと、の 4 つです。

止まるのがツールの準備段階なので、ブラウザーを使う作業だけでなく送信や再開そのものが失敗します。エラー文の "authenticated account" はアプリ内の ChatGPT サインインのことで、Web サイトへのログインや OpenAI Platform のアカウントを指しているわけではありません。

API キーで使っている人が当たる理由も、同じプログラムから読み取れます。API キーなど ChatGPT 以外のサインインでは、アプリはローカルの Work を「利用可」と扱い、どのモードで動かすかを利用者が保存した選択に任せます。ChatGPT サインインでないことを理由に断られるのは、Work のクラウド側だけです。そのため、メニューで Work を選んだ時点で 2 つ目の条件がそろい、ChatGPT の身元はもともとないので 4 つ目もそろいます。Codex モードに切り替えると 2 つ目が外れ、このチェックは行われません。圧縮されたプログラムの読み取りによる判断で、関数名などはビルドごとに変わります。

OpenAI の ChatGPT・Codex の認証ドキュメント は、デスクトップアプリのローカル作業に API キーでサインインできること、ChatGPT ワークスペースやクラウドに依存する一部の機能が制限されることを書いていますが、2026年10月23日時点でこのエラーや、Work モードが ChatGPT アカウントを求める規則は説明していません。GitHub の報告は、アプリが 26.1013 系に自動更新された直後から集まっていて、CC Switch、magpie、Codex++、sub2api、codex2api、NewAPI、DeepSeek などで外部 API につないでいる人が中心です。

確認に使った Mac はアプリに ChatGPT でサインインし（~/.codex/auth.json の auth_mode が chatgpt）、config.toml の [desktop] には conversationDetailMode = "STEPS_COMMANDS" が入っていて、2026年10月分のアプリのログにこのエラーは 1 件もありません。API キーでサインインし直しての再現はしていないため、以下の手順が直ることは利用者の報告で裏付けられている範囲にとどまります。

同じ「メッセージの送信中にエラーが発生しました」の下に別の英文が出ている場合は、Codex「メッセージの送信中にエラーが発生しました」は2行目で判断で 2 行目ごとに対処を分けています。2026年10月23日に読んだ同じアプリ 26.1016.62342 のプログラムでは、2 行目が Work browser access is unavailable になるのは、アカウントの Work 設定（/wham/work/settings）を取得できなかったときです。ChatGPT の身元がないこととは別の問題で、Codexのブラウザーがオンなのに無効：2つの表示別の原因と対処が担当です。

Codex に戻す・設定を書き換える・サインインする：3 つの道の選び方

Work モードがなくても困らないなら、モードメニューで Codex に戻すのが最も手軽です。メニューが見当たらない、切り替えてもエラーが続く、どのチャットも開けないといった状態なら設定ファイルを書き換えます。Work モードを手放せず、ChatGPT アカウントを持っているなら、アプリに ChatGPT でサインインしたうえで中継をルーティングで使います。違いは次のとおりです。

設定ファイルを書き換えても、メニューで Work を選び直すとアプリが "STEPS_PROSE" を書き戻すので、エラーは戻ってきます。上の 2 つは「Work を使わない」という同じ選択の入り口違いで、Work を使いながら API キーだけで済ませる方法ではありません。

ChatGPT アカウントがないまま Work モードのブラウザー操作が必要な場合は、Codex モードか Codex CLI で作業を続け、openai/codex#54841 の修正を待つことになります。2026年10月17日に立てられたこの報告には 30 件ほどの賛同が付いていますが、10月23日時点で OpenAI の返答はなく、10月21日のアプリ更新後も直っていないという書き込みがあります。CC Switch の開発者は、ChatGPT にサインインしたくない人向けにアプリ 26.1007 に留まる方法も挙げていますが、それ以降の修正を受けられず、自動更新で再び上がることもあるため、最後の手段と考えてください。

ChatGPT アカウントなしで送信を戻す手順

ChatGPT アカウントを使わずに送信を戻すには、Work モードを抜けて Codex モードに戻します。まずメニューから試し、それで戻らないときだけ設定ファイルを直します。

左上のモードメニューで「Codex」を選ぶ

アプリ 26.1016.62342 のプログラムでは、このメニューで Work（ChatGPT Work）を選ぶと conversationDetailMode に STEPS_PROSE が、Codex を選ぶと STEPS_COMMANDS が書き込まれます。メニューを切り替えるだけで、設定ファイルを開かずに条件が外れます。

1. 画面左上の「ChatGPT Work」と表示されているモードメニューを開きます。読み上げソフトでは「モード切り替え、現在のモード: ChatGPT Work」と読まれるボタンです。
2. 一覧から「Codex」を選びます。
3. 新しいチャットを開いて短いメッセージを送り、エラーなく返答が来るかを確かめます。

config.toml の conversationDetailMode を STEPS_COMMANDS にする

メニューで戻せないときは、設定を直接書き換えます。ファイルは Mac なら ~/.codex/config.toml、Windows なら %USERPROFILE%\.codex\config.toml で、環境変数 CODEX_HOME を設定している場合はそのフォルダーの中の config.toml です。アプリが動いている間に書き換えると、終了するときにメモリ上の古い値が書き戻されることがあるという報告があるため、必ずアプリを閉じてから作業します。

1. アプリを完全に終了します。Mac では ⌘Q、Windows ではウィンドウだけでなくアプリ自体を終了します。
2. config.toml をテキストエディターで開き、[desktop] の行を探します。
3. その下の conversationDetailMode の行を次のように書き換えて保存します。

[desktop]
conversationDetailMode = "STEPS_COMMANDS"

4. アプリを起動し、新しいチャットで送信できるかを確かめます。

GitHub の報告では、Windows でこの書き換えのあとアプリを完全に再起動したら送信できるようになった、という例が複数あります。conversationDetailMode の行をコメントアウトしても既定値の STEPS_COMMANDS に戻るので同じ効果があり、Codex モードで表示を最も詳しくする STEPS_EXECUTION でもこのチェックは掛かりません。行そのものが見当たらない場合は設定がすでに既定値なので、書き換えても何も変わりません。その場合は後述の「ChatGPT でサインインしているのに出る」ケースに近い状態を疑います。

Work モードを残す：ChatGPT にサインインして CC Switch をルーティングに

Work モードを使い続けるには、アプリに ChatGPT アカウントの身元を持たせたまま、モデルへのリクエストだけを中継に送ります。CC Switch の開発者が 2026年10月16日と23日に GitHub で案内し、複数の利用者が成功を報告している方法で、ChatGPT アカウントを持っていて、アプリからサインインできることが前提です。

開発者の説明では、~/.codex/auth.json が ChatGPT のサインイン（"auth_mode": "chatgpt" と tokens がある状態）になっていないと、アプリは身元がないと判断します。OPENAI_API_KEY だけが入っている auth.json でも同じエラーになります。さらに CC Switch の Direct（直連）モードで中継に切り替えると、既定では公式のサインイン情報が退避されて auth.json から消えるため、ChatGPT でサインインしていたはずの人もこのエラーに当たります。Routing（路由）モードなら auth.json には触れず、モデルへのリクエストだけが CC Switch 経由で中継に向かいます。

1. CC Switch で Codex のプロバイダーを「OpenAI Official」に切り替えます。
2. Codex デスクトップアプリを完全に終了してから開き直し、ChatGPT アカウントでサインインします。
3. もう一度アプリを完全に終了し、CC Switch で Codex の接続モードを Direct から Routing に変え、ルーティングの画面で使いたい中継を選びます。
4. アプリを開き、Work モードの新しいチャットで送信できるかを確かめます。あわせて中継側の利用ログにリクエストが記録されているかも見ておきます。

CC Switch 4.0.16（2026年10月19日公開）より前の版は、CC Switch を終了するときに ChatGPT のサインイン情報を消してしまい、起動のたびにこの手順をやり直す必要がありました。4.0.16 以降はそれが直っています。Direct モードのまま使いたい場合は、Settings → General → Codex App Enhancements にある「Keep official login for direct switches」（中国語表示では「非接管切换时保留官方登录」、既定はオフ）をオンにしてから、一度 OpenAI Official でサインインし、そのあと中継に切り替えます。

2026年10月23日には、Windows のアプリ 26.1016.8622.0 と NewAPI の組み合わせで、Direct から Routing に変えただけで Work モードの送信が戻ったという報告があり、別の利用者も Direct と集約モードでは失敗し Routing なら動くと書いています。一方で、リクエストが中継ではなく公式アカウントに流れたという未解決の報告や、切り替え後に DeepSeek の API へつなぐのに VPN が必要になったという報告もあります。magpie や Codex++ など CC Switch 以外のツールでも、アプリ側が ChatGPT のサインインを求める点は同じですが、そのサインインを残したまま中継につなげるかはツールごとに異なります。

ChatGPT のサブスクと API キーで、費用や使える機能がどう違うかは Codex APIキーとChatGPTサブスクの違い：クレジット換算はAPIと同額で比べています。

ときどき送れる、新しいチャットだけ失敗するのはなぜか

同じ設定でも送れたり送れなかったりするのは、アプリが Work モードの判定を返すまでに時間差があるためと考えられます。アプリ 26.1016.62342 のプログラムでは、アカウントごとの機能の割り当て（Statsig）と、その身元向けの Work のポリシーを受け取ってから、Work モードかどうかを返します。受け取る前は何も返さないので、身元のチェックは飛ばされます。

その結果、起動直後は送れたのにしばらくすると失敗する、OpenAI の機能設定サービスへの接続が不安定だと送れたり送れなかったりする、ということが起こりえます。中継事業者の星芒が Windows のアプリ 26.1013.4894 を調べた分析も同じ結論で、チェックはチャットを始めるときに 1 回行われるため、すでに開いているチャットは使い続けられ、新しいチャットだけ失敗することがあると説明しています。ときどき送れることは中継の回線が原因という意味ではなく、Codex モードに戻せばこのチェック自体が走らないので、症状も安定します。

Work browser access エラーのその他の疑問

ブラウザーのスイッチをオフにすれば直りますか

確実ではありません。2026年10月23日にアプリ 26.1016.62342 のプログラムを読んだ範囲では、エラーには node_repl のツールサーバーがチャットに付いていることが必要ですが、どの設定を切ればそれが外れるかまではたどれていません。中継事業者の星芒の分析は、config.toml の [plugins."browser@openai-bundled"] でブラウザーのプラグインを切ればこのエラーを避けられるとしつつ、Chrome やコンピューター操作など別のプラグインも node_repl を付ける可能性があるため、それだけでは足りないかもしれないと書いています。この点は検証されていません。実際、Codex++ の GitHub の報告（2026年10月20日）では、ブラウザーのスイッチをオフにしてもエラーが出続け、メッセージを送れなかったという利用者がいます。ブラウザーも使えなくなるので、モードを Codex に戻すほうが確実です。

ChatGPT でサインインしているのに出るのはなぜですか

原因はまだわかっていません。2026年10月16日に、macOS のアプリ 26.1013.31256 を使う ChatGPT Plus 利用者が、通常の Chat モードが消えて「ChatGPT Work」と「Codex」しか選べない、ログアウトのボタンが反応しないという症状とあわせて、このエラーを openai/codex#54143 に報告しています。再インストールや ~/.codex/cache の削除では直らず、見た目はサインイン済みでもアプリが身元を保持できていない状態と考えると、4 つ目の条件と一致します。モードを Codex に戻せばチェックは掛かりませんが、このスレッドでそれを試したという報告はありません。

中継やカスタムプロバイダーはどこで設定しますか

config.toml にカスタムプロバイダーを登録し、API キーと Base URL を指定します。書き方と選び方は Codex カスタムプロバイダー設定：APIキーとBase URLの選び方にまとめています。この設定自体は Codex CLI でもデスクトップアプリでも使えますが、デスクトップアプリで Work モードを選ぶと、どのプロバイダーでもここで説明した身元のチェックに当たります。