Codex account/read failed during TUI bootstrap：末尾で切り分け

Error: account/read failed during TUI bootstrap: account/read failed: workspace routing discovery failed (code -32603)

codexと打つと、ターミナル画面（TUI）が描かれる前にこの1行だけが出て終了します。codex login statusはLogged in using ChatGPTのまま、codex execで投げたプロンプトは普通に返ってきます。この組み合わせが2026年9月末から10月にかけての報告の典型で、一見すると矛盾しています。

手がかりは、2つ目のaccount/read failed:の後ろに続く末尾の文言だけです。(code -32603)はJSON-RPCの汎用コード「internal error」で、HTTPステータスではなく、原因も表しません（-32600は「invalid request」）。同じ書き出しでも、2026年4月の報告と10月の報告では原因が別です。2026年10月17日時点で、末尾ごとの要点は次のとおりです。

• workspace routing discovery timed out／workspace routing discovery failed：バックグラウンドサーバー（daemon）の再起動か更新で開くようになったという報告がもっとも多く、プロキシ環境ではプロキシの環境変数をそのサーバーに渡す必要があります。
• failed to load workspace requirements：取り消されたトークンが隠れていた例と、最新の0.163.0でも再現して未解決の例があり、確かな対処がいちばん少ない末尾です。
• workspace routing discovery unauthorized (401)：認証情報を保存しているマシンで再サインインし、古いトークンを握ったままのプロセスを終了します。
• duplicate workspace in routing discovery：ChatGPTアカウント側に同名のワークスペースが2つある状態で、ユーザー側に対処がありません。
• plan type is required for chatgpt authentication (code -32600)：ChatGPT以外が発行した、または混在した認証情報です。

以下の対処は、すべて日付付きのGitHub issueとOpenAI開発者コミュニティの報告です。実際に手元で実行したのは、ChatGPTデスクトップアプリ同梱のcodex-cli 0.163.0-alpha.10.2で--help、codex login status、codex doctor --summary --no-color、codex app-server daemon versionを読み取り専用で走らせたことと、後述のcurl1本だけで、エラーそのものの再現も、どの対処の検証もしていません。OpenAIからの公式な原因説明や修正の告知は、2026年10月17日時点でありません。

この1行で失敗しているのはTUIがapp-serverへ送るaccount/read

Codex CLIの対話画面は、起動時にバックエンドのapp-serverへいくつかのJSON-RPC要求を順に送ります。account/readはそのひとつで、保存されたサインイン状態を読み取る要求です。これが失敗するとTUIは「account/read failed during TUI bootstrap:」の後ろにエラー本体を続けて終了し、本体のJSON-RPCエラーは「account/read failed:」＋末尾＋「(code N)」の形で描かれます。1行の中にaccount/read failedが2回出るのはこのためです。同じ包み方はmodel/list、configRequirements/read、thread/start、thread/forkにもあり、thread/start failed during TUI bootstrapは起動シーケンスの別の段階で、別の問題です。

ChatGPTアカウントでサインインしている場合、app-serverはaccount/readの中でworkspace routing discoveryを実行します。ここでいうworkspaceは、ChatGPTにサインインするときに選ぶ個人／組織の空間（ChatGPTのワークスペース）で、プロジェクトのフォルダーやVS Codeのワークスペースではありません。discoveryはChatGPTバックエンドのaccounts/checkと、クラウド側の「workspace requirements」という設定束を取りに行き、読み取り全体に15秒の上限がかかっています。15秒で返らなければworkspace routing discovery timed out、routing系の失敗はJSON-RPCのinternal_errorつまり-32603、アカウント状態そのものが不正ならinvalid_requestつまり-32600になります。この仕組みはCodexのソースコードのうちapp-serverのworkspace_routing.rsとTUI側のapp_server_session.rsに書かれています（2026年10月17日時点のmainブランチ）。実際の報告でも、デスクトップアプリのログにdurationMs=15002 errorCode=-32603 method=account/read（issue #49921）、WSL2で15.016s（issue #51052）と、15秒きっかりで落ちています。

APIキーでサインインしている場合、discoveryは走りません（app-serverのテストコードがaccounts/checkの呼び出し0回を規定しています）。0.163.0からは、ChatGPT認証がないときの起動時のバックグラウンド読み取りもスキップされます（PR #52635「Skip background workspace routing reads without ChatGPT auth」、10月9日マージ）。ただしAPIキー利用者でも、カスタムプロバイダーにrequires_openai_auth = trueを付けているとaccount/readが呼ばれ、保存されたChatGPT側の認証状態を読みに行きます。これが後述する4月のケースです。

codex execは動くのにTUIだけ落ちるのは矛盾ではない

この包み文言はTUIの起動シーケンスのものです。codex execは対話画面を経由しない別の起動経路で、同じマシン・同じアカウントでTUIだけが落ちる報告が複数あります。issue #51052（WSL2でaccount/readが15秒でタイムアウト）では2026年10月5日、WSL2のTUIはtimed outで落ち、codex execはWindowsでもWSL2でも成功しています。OpenAI開発者コミュニティのスレッド1407111（0.163.0でTUIがaccount/readに失敗）では10月17日、codex exec "Reply only with READY"がREADYを返す一方でcodexは落ちています。

execが動くことはサインインが生きている証拠にはなりますが、discoveryが通ったことの証拠ではありません。アカウント側の問題であるduplicate workspaceでは、execもReconnecting... 2/5を繰り返してから同じ文言で失敗しています（issue #47034、9月23日のコメント）。

0.157.0から既定で動く「共有バックグラウンドサーバー」

もうひとつ押さえておきたいのが、2026年9月25日の0.157.0から、対話モードのcodexが既定で共有バックグラウンドサーバー（daemon。OpenAIのUI文言では「shared background server」）を自動起動するようになったことです（rust-v0.157.0のリリースノートの#47179「Enable automatic daemon startup by default」）。常駐するcodex app-server --managed-daemonに、新しく開いたTUIが接続する構成です。issue #48195（daemon_auto_startをオプトインにしてほしいという要望）に9月25日時点の挙動がまとまっています。

• CLIとは別に、~/.codex/packages/app-server-daemon/releases/以下へバージョンごとにパッケージを複製して動くため、CLIを更新してもサーバーが古い版のまま残ることがあります。
• 最初に起動したセッションの環境変数（プロキシ設定を含む）を保持し続けます。
• 自動更新ループが別プロセスとして動きます。

--no-daemonを付けると、共有バックグラウンドサーバーを使わずに対話CLIを実行します（公式の開発者コマンド一覧。--remoteやcodex agentsとは併用できません）。-c key=value、--enable、--disable、--searchのどれかを付けた場合も、CLIはRunning without the shared background server: command-line configuration overrides (-c, --enable, --disable, or --search) requires embedded mode.と表示して埋め込みモード（embedded mode）になります（issue #52928（-cを付けると起動する報告）の10月10日のコメント）。後述の「-c log_dir=…を付けると起動する」という報告群は、この性質で説明がつきます。

まず3つの確認：login status・daemon version・doctor

対処を選ぶ前に、次の3つを実行します。どれも読み取り専用で、サインインや会話履歴を変えません。

codex login status
codex app-server daemon version
codex doctor --summary --no-color

codex login statusはLogged in using ChatGPTかLogged in using an API keyかを返します。ChatGPTならdiscoveryを通る経路、APIキーなら通らない経路です。このエラーの報告では、ほぼ例外なくここがLogged in using ChatGPTのままなので、「ログインしているのに落ちる」こと自体は手がかりになりません。

codex app-server daemon versionは、バックグラウンドサーバーが動いていればCLIとサーバー双方の版をJSONで返します。issue #52928の10月15日のコメントの出力は{"status":"running","backend":"pid","managedCodexVersion":"0.162.1","cliVersion":"0.162.1","appServerVersion":"0.162.1"}で3つが揃っていましたが、同じスレッドの別の報告ではCLIが0.162.1なのにappServerVersionが0.160.0でした。この2つの数字がずれているかどうかが、次節の分岐になります。サーバーが動いていなければ、failed to connect toに続けて~/.codex/app-server-control/app-server-control.sockのパスとNo such file or directory (os error 2)が出ます（手元の0.163.0-alphaの出力）。この場合、常駐サーバーの古い状態という原因候補は外れ、ネットワーク・認証情報・アカウント側に絞れます。

codex doctor --summary --no-colorは、インストール・設定・認証・接続・バックグラウンドサーバーの状態をグループ別に1行ずつ出します。手元の出力にはwebsocket connected (HTTP 101 Switching Protocols) · 15s timeoutとBackground Server ○ app-server not running (ephemeral mode)の行があり、末尾は20 ok · 1 idle · 5 notes · 3 warn · 0 failでした。接続（websocket）が正常でもこのエラーは出るので、doctorが全部okでも安心材料にはなりません。コミュニティのスレッド1404666（0.162.0がプロキシ環境でTUI起動に失敗）の報告者は、--summaryなしの詳細レポートでCLI 0.162.0に対してサーバーが0.161.0だったことを見つけています。--jsonで出すと"app-server version"の項目に同じ値が出ます（issue #52775（0.162.1が-c log_dirなら起動する報告）に添付された10月10日のレポート）。

codex app-server daemonのサブコマンドは、公式の開発者コマンド一覧には載っていません。bootstrap、start、restart、update、stop、versionは、CLI自身のcodex app-server daemon --help（0.163.0-alpha.10.2）に出てくるもので、updateの説明には「may interrupt running work」と添えられています。

末尾ごとの意味・報告された原因・報告された対処

末尾は英語のまま読みます。「報告された対処」は、その報告者の環境で開くようになったという記録で、原因の確定ではありません。

timed out／failed：サーバーの再起動か更新で開いた報告が最多

この2つの末尾は報告の大半を占め、対処もいちばんはっきりしています。開くようになった報告は、ほぼ「サーバーを再起動した」「サーバーをCLIと同じ版に更新した」「共有サーバーを使わずに起動した」の3通りです。

codex app-server daemon restartで開くようになった報告

codex app-server daemon restart
codex

• コミュニティのスレッド1404666（2026年10月9日、Linux Mint、0.162.0、ChatGPTサインイン、ローカルプロキシ）：ネットワーク断とPC再起動のあとにworkspace routing discovery failed。codex app-server daemon restartで起動するようになり、報告者は「設定・認証情報・会話履歴を消さずに直った」と書いています。同時にCLI 0.162.0に対してサーバーが0.161.0だったことと、プロキシのポート指定（SOCKS用の10808をHTTP用に使っていて407）を直したことも添え、どちらが原因だったかは確定できないとしています。スレッドの採用済み回答です。
• issue #52928の10月15日のコメント（Linux、0.162.1、HTTPプロキシ）：timed out。CLIとサーバーの版は3つとも0.162.1で揃っていて、プロキシ経由のcurlでhttps://chatgpt.com/backend-api/wham/accounts/checkが0.46秒で401（未認証なので期待どおり）を返し、ネットワークは正常でした。それでもrestartで直り、報告者は「常駐プロセスに残った状態、継承されたプロキシ環境変数、接続状態」のどれかを疑っています。
• issue #17800（4月に開かれた元スレッド）の10月11日と10月15日のコメント：auth.jsonの削除と再サインインでは足りず、codex app-server daemon restartで解消。
• issue #48894（VS Code拡張でSign-in failedになる報告）の9月29日のコメント：pkill -f codexで残ったCodexのプロセスを全部終了してからcodex login statusで確認し、codex。10月5日と6日に別の2人が「同じく直った」と返しています。

再起動は、共有サーバーを使っている他のCodexウィンドウやcodex agentsの作業を中断し得ます。1404666の報告者もその注記を付け、0.163.0でTUI内に追加された/daemonの再起動も「他のチャットの進行中・待機中の作業を中断する可能性がある」と警告してから実行し、終わると自動で再接続します（rust-v0.163.0のリリースノートの#53173）。ただし/daemonはTUIが開いてから使うものなので、起動前に落ちるこのエラーには、ターミナルからのcodex app-server daemon restartが入口になります。ターミナルからの再起動で他のウィンドウがどう振る舞うかについての報告はありません。

CLIとサーバーの版がずれているならupdate --from-cli --yes

codex app-server daemon versionのcliVersionとappServerVersionが違う場合は、サーバー側をCLIに合わせます。

codex app-server daemon update --from-cli --yes
codex

issue #52928の10月15日のコメント（Arch Linux）では、CLI 0.162.1に対してappServerVersionが0.160.0でした。上のコマンドでサーバーが0.162.1になり、codexが起動しています。報告者は「CLIを更新してもサーバーの更新が置き去りになる」更新戦略の欠陥と見ています。--from-cliは「Copy and pin this CLI package」、-y／--yesは確認プロンプトなしで置き換える指定です（codex app-server daemon update --help）。設定のtui.show_server_version_notice（既定true）は、接続したサーバーの版がCLIと違うときにTUIへ通知を出す項目ですが、TUIが開かないこのエラーでは見られません。CLI本体の更新や再インストールの手順はCodex CLIのインストールと設定：Windows・macOS・Linux対応にあります。

--no-daemonで開くなら共有サーバー側の問題

codex --no-daemon

issue #52928（10月10日、Ubuntu 22.04のDockerコンテナ、0.156.1と0.162.1）では、同じシェル・プロキシ・認証・設定で、codexは約1.63秒でworkspace routing discovery failed、codex --no-daemonは正常に起動して会話もできました。1.63秒は15秒のタイムアウトとは整合しないので、「タイムアウト」ではない失敗もあります。10月15日の2人（版ずれの人と、再起動で直った人）も、--no-daemonなら開くと書いています。一方、duplicate workspaceでは--no-daemonでも同じ文言で落ちます（issue #47034、9月23日）。アカウント側の問題は共有サーバーを避けても変わりません。

--no-daemonで開くなら、原因は共有サーバーの経路にあると絞れます。ただし埋め込みモードではcodex agentsやリモート操作が使えず、根本は直っていません。開いたら、前の2項の再起動か更新に戻るのが筋です。

同じ理屈で説明できるのが-c log_dir=…の報告群です。issue #48600（0.157.1でlog_dirを明示すると起動する報告、9月27日）とissue #52775（10月10日・14日）は、codex -c log_dir="$HOME/.codex/log"なら起動すると報告しています。しかしissue #52928の報告者は、-c model_reasoning_effort="medium"でも起動し、config.tomlに同じlog_dirを書いても直らず、config.tomlを外しても落ちることを確かめました。-cが埋め込みモードを強制するだけで、log_dirの値は関係ありません。公式の設定リファレンスのlog_dirは「明示的に設定すると、そのディレクトリにオプトインのTUIログcodex-tui.logも有効になる」項目です。touch ~/.codex/log/codex-tui.logだけでcodexが開くようになったという報告（issue #52775、10月15日）は1件だけで、説明もついていません。

共有サーバーを恒久的に切るなら、codex features disable daemon_auto_start（codex features --helpに出るdisableサブコマンド）か、config.tomlの[features]にdaemon_auto_start = falseを書きます。issue #48195の9月25日のコメントは、Windows 10でこの設定で起動ブロックが解消したと書いています。daemon_auto_startは2026年10月17日時点で公式の設定リファレンスに載っていません。

WSL2と、長く動いていたサーバー

• issue #51052（10月5日、0.160.0）：同じアカウントで、Windowsのaccount/readは0.422秒で成功、WSL2では15.016秒でtimed out。codex execはどちらでも成功。報告者は、タイムアウトがどの段階で止まったかを特定できないと書いています。10月6日に「同じ」が1件。0.162.0（10月8日）の#50555で、Windows側にマウントされたWSLホーム（DrvFS/9p）ではdaemonの自動起動をスキップして埋め込みモードで動くようになりましたが、この報告のWSL2はLinux側のホームです。
• issue #37971（8日間動いていたサーバーのファイルディスクリプタ枯渇）（8月11日、CLI 0.147・サーバー0.146）：configRequirements/read failed during TUI bootstrapにNo file descriptors available (os error 24) (code -32603)。メソッド名は違いますが「常駐サーバーに溜まった状態」の同類で、再起動で解消しています。0.162.0の#51470で、管理されたサーバーのソフト上限が4096に引き上げられました。

プロキシや社内ネットワーク：環境変数を渡してから再起動

プロキシ経由でしか外に出られない環境では、discoveryの要求だけがプロキシを通らない、またはプロキシに拒まれる形で落ちます。

• issue #49921（macOSデスクトップでHTTP_PROXYを明示しないとタイムアウトする報告）（10月1日、デスクトップ26.921）：account/readが約15秒で失敗し、/wham/usageや/settings/userはHTTP 432「Workspace routing is unavailable」。Electronの--proxy-server=フラグでは直らず、HTTP_PROXY、HTTPS_PROXY、NO_PROXYの環境変数を付けてアプリを起動すると動きました。
• issue #52928の10月12日のコメント：~/.codex/.envにhttp_proxy、https_proxy、NO_PROXY／no_proxyを書いて再起動したらCLIが直った。1人の観察で、公式ドキュメントにこのファイルの記載はありません。
• issue #50211（macOSのCLIでdiscovery failed）の10月16日のコメント：会社のネットワークがchatgpt.comを遮断し、openai.com配下は通していたため、サインインは成功するのにその後が全部失敗。
• コミュニティ1404666：プロキシが407 Proxy Authentication Requiredを返していた原因は、SOCKS用のポートをHTTPプロキシとして指定していたこと。

バックグラウンドサーバーは最初に起動したセッションの環境変数を保持するので（issue #48195）、シェルでプロキシ変数を直しただけでは、動いているサーバーには届きません。変えたら再起動します。

export HTTPS_PROXY=$PROXY_URL
export HTTP_PROXY=$PROXY_URL
codex app-server daemon restart
codex

PROXY_URLには、あなたのプロキシが待ち受けているアドレス（HTTPプロキシのポート）を入れます。ネットワーク自体が通っているかは、認証なしの要求を1本投げれば分かります。

curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" https://chatgpt.com/backend-api/wham/accounts/check

未認証なので401が返れば到達しています。issue #52928の報告者はプロキシ経由で0.46秒、手元ではプロキシなしで約1.3秒でした。ここが407や接続エラー、Cloudflareの403になるなら、Codexより前の段階です。

0.163.0のPR #52702で、起動時のGET（accounts/checkとconfig/bundle）はリクエストエラー時にシステムプロキシで再試行するようになりましたが、401・403・407・429・503のHTTP応答は再試行の対象外です。社内のTLS検査がある環境では、公式ドキュメントどおりCODEX_CA_CERTIFICATEにPEMバンドルを指定します（未設定ならSSL_CERT_FILEにフォールバック）。HTTP_PROXY／HTTPS_PROXY自体は、公式の環境変数ページに載っていません。

failed to load workspace requirements：0.163.0でも未解決

この末尾は「クラウド側のworkspace requirementsという設定束を読み込めなかった」という意味で、本当の失敗理由が隠れます。mainブランチのコードはcloud config: authentication failed (HTTP 401)、cloud config: request timed out、cloud config: request failed、cloud config: invalid bundleのような理由を後ろに付けますが、出荷版の0.162.1と0.163.0の報告はどれも理由なしのfailed to load workspace requirements (code -32603)です。

• issue #54184（実体は401 token_revokedだった報告）（10月15日、0.162.1、macOS arm64、ChatGPTサインイン）：バックエンドへの呼び出しがすべて401 token_revoked（「Encountered invalidated oauth token for user」）を返していたのに、TUIは汎用の-32603を出していました。さらに、再度codex loginしても、動いているTUIとapp-serverは取り消されたトークンを使い続け、終了させるまで直りませんでした。コメントはまだありません。
• コミュニティのスレッド1407111（10月17日、codex-cli 0.163.0、macOS、NVM経由のNode 22、ChatGPT Plus）：どのディレクトリからでも再現し、ログアウトと再サインインは効かず、0.162.1から0.163.0への更新も効かず、codex execは動く。10月17日時点で返信はありません。
• issue #52775の10月14日と15日のコメント：-c log_dir=…で起動、またはtouch ~/.codex/log/codex-tui.logで起動。前節のとおり、前者は埋め込みモードの効果、後者は単独の報告です。
• Xでも10月13日に0.162.1でこの末尾の投稿があり、OpenAI側の返答は見当たりません。

試す順は、認証情報の入れ替え、古いトークンを握ったプロセスの終了、共有サーバーの回避、の順です。

1. ブラウザでChatGPTにサインインできることを確かめてから、codex logout、codex login。
2. 動いているCodexのTUI、ChatGPTデスクトップアプリ、codex app-serverをすべて終了します（codex app-server daemon stop、残ればpkill -f 'codex app-server'）。その後codex。再サインインが動いているプロセスに自動で反映されないことは、#54184と後述の#47456の2件が一致して示しています。
3. 開かなければcodex --no-daemon。開けば共有サーバー側、開かなければ現時点で未解決の例と同じ状態です。

3まで進んで開かない場合、2026年10月17日時点で公開されている対処はありません。Codexのissue一覧に版・OS・codex login statusの出力・execが動くかどうかを添えて報告するのが、残る行動です。

unauthorized (401)：認証情報のあるマシンで再サインイン

workspace routing discovery unauthorized (401)は、discoveryの要求にバックエンドが401を返した状態です。issue #47456（リモートホストが古いChatGPT認証を保持する報告）（9月23日）の構成は、macOSのデスクトップアプリからSSHでリモートのLinuxホストに接続し、そこでapp-serverと~/.codex/auth.jsonが動いているというものでした。リモート側のcodex login statusはLogged in using ChatGPTのまま、app-serverは401。直前にアカウントへ新しい権限が付与され、ハードウェア認証器とパスキーが追加されていました。報告者はこれを「確定した原因ではなく、きっかけの可能性」と位置づけています。リモートホストでcodex login --device-authを実行すると、すぐに直りました。デスクトップ側には「refresh token was revoked」という別の文言が出ていて、古い認証情報がリモートにあることに気づきにくかった、とも書いています。

同じissueの10月1日のコメントは、codex login --device-authが成功しても401が続いた例です。原因は、取り消されたトークンを握ったまま動いていたcodex app-serverプロセスで、新しい認証情報はauth.jsonに書かれていたのに、そのプロセスは読み直していませんでした。pkill -f 'codex app-server'のあとcodexで正常に起動し、~/.codexの中は何も削除していません。

手順にすると次のとおりです。

1. 認証情報が置かれているマシン（SSH先なら、そのSSH先）でcodex logout、続けてcodex login。ブラウザのないホストではcodex login --device-authを使います。ChatGPT側のセキュリティ設定かワークスペースの権限でデバイス認証が有効になっている必要があります。手順はCodex CLIをSSH先・ヘッドレス環境でログイン：ブラウザなしの3経路にあります。
2. 動いているcodex app-serverとTUIを終了してからcodex。

codex loginの段階で403が出る場合は別の問題で、Codexのトークン交換が403で失敗する原因と対処：ログインの段階から切り分けるが対象です。

duplicate workspace in routing discovery：アカウント側の問題

duplicate workspace in routing discoveryは、discoveryの結果に同じワークスペースが2つ返ってきた状態です。issue #47034（Windowsでサインイン成功後にduplicate workspaceで落ちる報告）は9月21日に開かれ、2026年10月17日時点で未解決、WindowsとmacOS、CLI 0.155.0-alpha.9.2・0.156.1・0.160.0、デスクトップ26.924で再現しています。

決め手になった観察は、ChatGPTアカウント自体に同名のワークスペースが2つあることです。10月3日のコメントはChatGPTのモバイルアプリに「Personal account / Personal」が2つ表示されると書き、10月4日のコメントはWebのサインイン画面に「Personal account」が2つ並び、「2つ目は自分で作っていない」と書いています。9月23日のコメントでは、同じMacの別のChatGPTアカウント（ワークスペースが1つ）では正常に動いています。

ユーザー側で試して効かなかったものは、codex logoutとcodex login、codex login --device-auth、新しいCODEX_HOME、forced_chatgpt_workspace_idの指定（認可要求にallowed_workspace_idが付くことまで確認済み）、再インストール、~/.codex/auth.jsonの削除、codex --no-daemonです。codex execも失敗します。動くものはVS CodeのCodex拡張（10月4日）だけで、0.154.0へのダウングレードは9月23日の1人には効き、10月4日の1人には効きませんでした。報告者たちはサポートに問い合わせていますが、スレッド内にOpenAIからの返答はありません。

この末尾が出たら、設定やインストールをいじるのは止めて、ChatGPT側のサインイン画面でワークスペースが二重になっていないかを見てから、OpenAIのサポートに「アカウントに重複したPersonalワークスペースがあり、Codexがduplicate workspace in routing discoveryで起動しない」と伝えるのが、報告から読み取れる唯一の筋です。

selected workspace missing／plan type：認証情報を揃える

selected workspace missing from routing discovery

この文言は、保存されたワークスペースの選択がdiscoveryの結果に含まれていないときのものです。公開されたissueやスレッドの本文は2026年10月17日時点で見当たらず、以下は文言と設定項目からの推論です。再サインインしてワークスペースを選び直すこと、そしてforced_chatgpt_workspace_idを設定しているなら、その値がいまもアカウントにあるワークスペースのIDかを確かめること。公式の設定リファレンスはこの項目を「ChatGPTサインインを特定のワークスペースIDに限定する」と説明し、認証ページは「有効な認証情報が設定された制限と一致しない場合、Codexはユーザーをログアウトして終了する」と書いています。

plan type is required for chatgpt authentication (code -32600)

この末尾だけはコードが-32600（invalid request）です。ソースコード上はProviderAccountError::MissingChatgptAccountDetailsで、ChatGPT方式の認証情報なのにトークンにplan_typeの情報がない状態を指します（emailは任意、plan_typeは必須）。古い版では文言が違い、issue #25428（2026年5月31日、0.135.0、Windows、Teamアカウント）ではemail and plan type are required for chatgpt authentication (code -32600)でした。

公式のChatGPTサインインが発行するトークンにはこの情報が入るので、欠けている状況として考えられるのは、ChatGPT以外の経路で作られたauth.json、手で編集された認証情報、別の認証方式から切り替えたときの残りです。中国語圏では2026年4月7日と10月3日のlinux.doのスレッド、7月7日のCSDNの記事が、無料の中継サービスから公式アカウントに戻したあと、またはAPIキーで使うつもりだったのにChatGPT方式の認証状態が残っていたときに、この書き出しのエラーが出たと報告しています。トークンの出所が原因だという点は、コードの読みとこれらの報告の整合からの推論です。

対処は認証情報を一度空にして、1つの方式でサインインし直すことです。

codex logout
codex login

APIキーで使うなら、codex loginの代わりにprintenv OPENAI_API_KEY | codex login --with-api-keyで、codex login statusがLogged in using an API keyになります。APIキー方式はdiscoveryを通りませんが、課金はChatGPTプランの枠ではなくAPIの従量になります。違いはCodex APIキーとChatGPTサブスクの違い：クレジット換算はAPIと同額にまとめてあります。

カスタムプロバイダーを使っている場合は、[model_providers]の設定でenv_keyとrequires_openai_auth = trueを同時に付けないことです。公式ドキュメントは「requires_openai_auth = trueのとき、Codexはenv_keyを無視する」と明記しており、この設定があるとTUIは保存されたChatGPT側の認証状態を読みに行きます。設定の書き方はCodex カスタムプロバイダー設定：APIキーとBase URLの選び方が対象です。

4月の末尾なし版：古い認証キャッシュとrequires_openai_auth

このエラーの元スレッドはissue #17800で、2026年4月14日に0.120.0、APIキー、Linuxで開かれました。当時の文言はError: account/read failed during TUI bootstrapだけで、末尾もコードもありません。報告者はログアウトと再ログインで直り、OpenAIの担当者は同日に再現手順を尋ねたまま、それ以降の公式返答はありません。

4月27日のコメントが当時の仕組みを説明しています。カスタムプロバイダーにenv_keyとrequires_openai_auth = trueを両方書くと、TUIは起動時にaccount/readを呼び、プロバイダーのキーではなくCodexが保存しているChatGPT側の認証状態を読みます。そこが古い、または必要な情報を欠いていると起動に失敗します。対処はrequires_openai_authを外すかfalseにすることです。~/.codexを全部削除しても直りますが、5月9日のコメントが指摘するとおりセッションログも全部消えます。5月14日のコメントはrm ~/.codex/auth.jsonだけで足りる（失うのはサインイン状態だけ）と書いています。

この4月の手順を、いまの既定の対処として扱わないほうがいい理由が2つあります。第一に、10月の報告ではauth.jsonの削除と再サインインでは足りず、バックグラウンドサーバーの再起動が必要だった（同issue、10月11日と15日）こと。第二に、duplicate workspaceでは新しいCODEX_HOMEでも落ちる（issue #47034）こと。削除は原因を変えません。削除するならauth.jsonまでにとどめ、~/.codex全体には手を付けないのが、これらのコメントから読み取れる線です。

履歴を消さずに試す順番

末尾を読んだうえで、会話履歴と設定を残したまま進める順です。各ステップのあとにcodexを打ち、TUIが開けばそこで止まります。

1. 3つの確認：codex login status、codex app-server daemon version、codex doctor --summary --no-color。サインイン方式、サーバーが動いているか、版がずれているかを控えます。
2. サーバーの再起動か更新：版がずれていればcodex app-server daemon update --from-cli --yes、揃っていればcodex app-server daemon restart。他のCodexウィンドウの作業が中断され得るので、先に保存します。サーバーが動いていなかった（socketが無いというエラー）なら、このステップは飛ばします。
3. codex --no-daemonで開くか確認：開けば共有サーバー側の問題と絞れますが、修正ではありません。開かなければ認証情報かアカウントかネットワークに進みます。
4. 再サインイン：codex logoutのあとcodex login（SSH先では--device-auth）。その後、動いているTUI・デスクトップアプリ・codex app-serverを終了してからcodex。これで失うのはサインイン状態だけです。
5. プロキシ：プロキシ環境ならHTTPS_PROXY／HTTP_PROXYをシェルに設定し、サーバーを再起動してからcodex。認証なしのcurlでaccounts/checkが401を返すかも見ます。
6. プロバイダー設定：-32600やカスタムプロバイダー利用なら、requires_openai_authとenv_keyの組み合わせを見直し、1つの方式でサインインし直します。
7. 行き止まり：duplicate workspaceはサポートへ。failed to load workspace requirementsで1〜5が全部効かない場合は、2026年10月17日時点で公開された対処がなく、issueへの報告が残る行動です。

~/.codex全体の削除はどのステップにも入れていません。セッションログを失うだけで、10月の報告では解決にもつながっていないためです。

デスクトップ版・VS Code拡張の「Sign-in failed」も同じ15秒

CLIではなくChatGPTデスクトップアプリやVS CodeのCodex拡張を使っていて、サインイン画面にSign-in failed: workspace routing discovery timed outやLogin failed: workspace routing discovery timed outが出る場合も、裏で失敗しているのは同じaccount/readのdiscoveryです。デスクトップアプリのログにはaccount/read failed: workspace routing discovery failed (error code -32603)と、その後の要求に対するWorkspace routing is unavailable（HTTP 432）が並びます（issue #49443（macOSデスクトップがほぼ毎日サインインを求める報告）、9月30日）。

• 毎日サインインを求められる：macOSの26.924（issue #49443、9月30日）、Windowsの26.1007（issue #53236、10月12日；issue #53520、10月13日）で、PCを一晩置いた最初の起動でdiscoveryがタイムアウトし、サインインし直すとその日は使える、という報告が続いています。
• 残ったプロセスを終了すると直った：issue #49921の10月15日のコメントは、ChatGPTアプリを終了してもDock Extra (ChatGPT.app)というプロセスが残っていて、それも終了させたらサインインできた、と書いています。CLIのpkill -f codexに当たる対処です。
• デスクトップにプロキシの環境変数を渡す：issue #49921（10月1日）のとおり、ElectronのプロキシフラグではなくHTTP_PROXY／HTTPS_PROXY／NO_PROXYを付けてアプリを起動すると動いた例があります。
• 外部のCLIを使わせる：Windowsで同梱のランタイムがタイムアウトの原因になっていた報告（issue #47145、9月22日）では、CODEX_CLI_PATHで別途インストールしたCLIを指すとサインインが維持されるようになった一方、ChatGPTのメモリー機能が使えなくなるという引き換えがありました。

日本語の投稿では、2026年10月17日にXで「Codexデスクトップアプリだけがエラーを出す」「今朝、急にワークスペース情報が取得できなくなった」として、issue #49443をリンクしているものがあります。デスクトップ側の症状を日本語で言うと、この「ワークスペース情報が取得できない」が実態に近い表現です。

VS Codeで30秒待ったあとにCodex could not startと出るのは別のエラーで、Codex could not start：VS Codeで起動しない原因を環境別に切り分けが扱っています。

0.163.0で直ったのか：修正の記載はなく、10月17日にも報告

直っていません。版の流れは次のとおりです（GitHubのリリース一覧、2026年10月17日時点）。

• 0.157.0（9月25日）：daemonの自動起動が既定に（#47179）。「Offer explicit recovery for incompatible background servers」（#47318）も同時。
• 0.162.0（10月8日）：WindowsマウントのWSLホームでdaemon自動起動を除外（#50555）、管理されたapp-serverのファイルディスクリプタ上限を4096に（#51470）、daemonのリリース識別と実行ファイルの中身を区別（#50559）。翌日に0.162.1。
• 0.163.0（10月15日、Latest）：TUIの/daemonから管理されたサーバーを再起動できる（#53173）、起動時のGETをシステムプロキシで再試行（#52702）、ChatGPT認証がないときのバックグラウンドのrouting読み取りをスキップ（#52635）、daemonの互換性チェックを明示的なCLIオーバーライドに限定（#52648）。
• 0.164.0-alpha.1〜3（10月16日・17日）：リリースノートは空。

0.163.0の項目はどれもこのエラーの周辺に手を入れていますが、リリースノートのどこにもworkspace routing discovery failedやtimed outを修正したとは書かれていません。そして0.163.0での報告は続いています。10月16日のissue #54462は0.163.0でtimed out（#53520の重複として閉じられました）、10月17日のコミュニティ1407111は0.163.0でfailed to load workspace requirementsです。

公式ドキュメント側も、認証ページ、設定リファレンス、開発者コマンド一覧、環境変数ページのいずれにも「workspace routing」「account/read」「TUI bootstrap」の記載がありません（2026年10月17日時点）。OpenAIの担当者がこのエラーについて書いた公開コメントは、4月14日にissue #17800で再現手順を尋ねた1件です。次に見るべきは0.164の正式版のリリースノートです。

別の段階のエラー：thread/start failed、os error 1、401と403

• Error: thread/start failed during TUI bootstrapやthread goal/set failed：起動シーケンスの別の要求（account/readの後）で、このページの末尾一覧は当てはまりません。GitHubにはissue #18064（thread/start failed during TUI bootstrap）として別のスレッドがあります。
• Operation not permitted (os error 1)：OSの権限エラー（EPERM）で、この一覧の末尾ではありません。
• TUIが開いてからモデルへの要求で401 Incorrect API keyが出る：認証情報とURLの組み合わせの問題で、Codexの401「Incorrect API key」：URLとキーで原因を見分けるが対象です。
• codex loginの途中でtoken exchange failedと403：サインインの段階の問題で、Codexのトークン交換が403で失敗する原因と対処：ログインの段階から切り分けるが対象です。
• 起動後の送信で「メッセージの送信中にエラーが発生しました」：Codex「メッセージの送信中にエラーが発生しました」は2行目で判断が対象です。