# Codex account/read failed during TUI bootstrap：末尾で切り分け > codexが画面を描く前に1行だけ出て終了するエラーです。原因は末尾の文言で分かれ、バックグラウンドサーバー再起動、再サインイン、プロキシ設定のどれを先に試すかもそこで決まります。 - URL: https://blog.laozhang.ai/ja/posts/codex-account-read-failed-tui-bootstrap - Published: 2026-10-17 - Updated: 2026-10-17 - Author: LaoZhang AI Team (https://blog.laozhang.ai/ja/about) - Topic: 開発ツールとエージェント - Tags: Codex, Codex CLI, app-server, ChatGPTサインイン, トラブルシューティング --- ```text 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`を読み取り専用で走らせたことと、後述の`curl`1本だけで、エラーそのものの再現も、どの対処の検証もしていません。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](https://github.com/openai/codex/blob/main/codex-rs/app-server/src/request_processors/account_processor/workspace_routing.rs)と[TUI側のapp_server_session.rs](https://github.com/openai/codex/blob/main/codex-rs/tui/src/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」](https://github.com/openai/codex/pull/52635)、10月9日マージ）。ただしAPIキー利用者でも、カスタムプロバイダーに`requires_openai_auth = true`を付けていると`account/read`が呼ばれ、保存されたChatGPT側の認証状態を読みに行きます。これが後述する4月のケースです。 ### `codex exec`は動くのにTUIだけ落ちるのは矛盾ではない この包み文言はTUIの起動シーケンスのものです。`codex exec`は対話画面を経由しない別の起動経路で、同じマシン・同じアカウントでTUIだけが落ちる報告が複数あります。[issue #51052（WSL2でaccount/readが15秒でタイムアウト）](https://github.com/openai/codex/issues/51052)では2026年10月5日、WSL2のTUIは`timed out`で落ち、`codex exec`はWindowsでもWSL2でも成功しています。[OpenAI開発者コミュニティのスレッド1407111（0.163.0でTUIがaccount/readに失敗）](https://community.openai.com/t/1407111)では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のリリースノート](https://github.com/openai/codex/releases/tag/rust-v0.157.0)の#47179「Enable automatic daemon startup by default」）。常駐する`codex app-server --managed-daemon`に、新しく開いたTUIが接続する構成です。[issue #48195（daemon_auto_startをオプトインにしてほしいという要望）](https://github.com/openai/codex/issues/48195)に9月25日時点の挙動がまとまっています。 - CLIとは別に、`~/.codex/packages/app-server-daemon/releases/`以下へバージョンごとにパッケージを複製して動くため、CLIを更新してもサーバーが古い版のまま残ることがあります。 - 最初に起動したセッションの環境変数（プロキシ設定を含む）を保持し続けます。 - 自動更新ループが別プロセスとして動きます。 `--no-daemon`を付けると、共有バックグラウンドサーバーを使わずに対話CLIを実行します（[公式の開発者コマンド一覧](https://learn.chatgpt.com/docs/developer-commands?surface=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を付けると起動する報告）](https://github.com/openai/codex/issues/52928)の10月10日のコメント）。後述の「`-c log_dir=…`を付けると起動する」という報告群は、この性質で説明がつきます。 ## まず3つの確認：login status・daemon version・doctor 対処を選ぶ前に、次の3つを実行します。どれも読み取り専用で、サインインや会話履歴を変えません。 ```bash 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起動に失敗）](https://community.openai.com/t/1404666)の報告者は、`--summary`なしの詳細レポートでCLI 0.162.0に対してサーバーが0.161.0だったことを見つけています。`--json`で出すと`"app-server version"`の項目に同じ値が出ます（[issue #52775（0.162.1が-c log_dirなら起動する報告）](https://github.com/openai/codex/issues/52775)に添付された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」と添えられています。 ## 末尾ごとの意味・報告された原因・報告された対処 末尾は英語のまま読みます。「報告された対処」は、その報告者の環境で開くようになったという記録で、原因の確定ではありません。 | 末尾 | ソースコード上の意味 | 報告された原因 | 報告された対処（出典・日付） | |---|---|---|---| | `workspace routing discovery timed out` | discoveryが15秒で返らなかった | 常駐サーバーに残った接続やプロキシ環境（#52928）；WSL2（#51052）；社内ネットワークがchatgpt.comだけを遮断（#50211） | `codex app-server daemon restart`（コミュニティ1404666、10月9日）；`pkill -f codex`のあと起動（#48894、9月29日）；プロキシの環境変数（#49921、10月1日） | | `workspace routing discovery failed` | discovery要求が失敗（タイムアウト・401以外） | 上と同じ原因に加え、CLIとサーバーの版の不一致（#52928、10月15日） | `codex app-server daemon version`で版を比べ、`codex app-server daemon update --from-cli --yes`か`restart` | | `failed to load workspace requirements` | クラウド側の設定束を読めなかった。出荷版では理由が付かない | 実体は401 token_revoked（#54184、10月15日）；0.163.0でも再現し原因不明（コミュニティ1407111、10月17日） | 再サインインのあと、古いトークンを持つTUIとサーバーを終了（#54184）；`-c log_dir=…`で埋め込みモード（#52775、10月10日） | | `workspace routing discovery unauthorized (401)` | バックエンドが401を返した | アカウントの権限やプランの変更後、ローカルのトークンだけが失効（#47456、9月23日） | 認証情報のあるマシンで`codex login`（リモートは`--device-auth`）；残った`codex app-server`プロセスを終了（#47456、10月1日） | | `duplicate workspace in routing discovery` | discovery結果に同じワークスペースが2つ | ChatGPTアカウント自体に同名の「Personal」ワークスペースが2つ（#47034、10月3日・4日） | ユーザー側に対処なし。VS Code拡張は動く；サポートへ問い合わせ | | `selected workspace missing from routing discovery` | 選択済みのワークスペースがdiscovery結果にない | 公開された報告なし | 推論：再サインインしてワークスペースを選び直す；`forced_chatgpt_workspace_id`の値を確認 | | `plan type is required for chatgpt authentication (code -32600)` | ChatGPTトークンに`plan_type`がない | ChatGPT以外が発行した、または混在した認証情報（推論） | `codex logout`のあと公式のChatGPTサインイン、または`codex login --with-api-key` | | 末尾なし（2026年4月、0.120） | 内側のエラーが表示されない旧版 | 古い認証キャッシュ＋`requires_openai_auth = true`（#17800、4月27日） | プロバイダー設定の修正；`~/.codex/auth.json`を削除して再サインイン（同、5月14日） | ![account/read failed:の後ろに続く5種類の末尾と、それぞれに報告された対処（共有サーバーの再起動、再サインイン、サポートへの問い合わせなど）を対応させた図](https://blog.laozhang.ai/posts/ja/codex-account-read-failed-tui-bootstrap/img/tail-to-fix-map.webp) ## timed out／failed：サーバーの再起動か更新で開いた報告が最多 この2つの末尾は報告の大半を占め、対処もいちばんはっきりしています。開くようになった報告は、ほぼ「サーバーを再起動した」「サーバーをCLIと同じ版に更新した」「共有サーバーを使わずに起動した」の3通りです。 ### `codex app-server daemon restart`で開くようになった報告 ```bash codex app-server daemon restart codex ``` - [コミュニティのスレッド1404666](https://community.openai.com/t/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](https://github.com/openai/codex/issues/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月に開かれた元スレッド）](https://github.com/openai/codex/issues/17800)の10月11日と10月15日のコメント：`auth.json`の削除と再サインインでは足りず、`codex app-server daemon restart`で解消。 - [issue #48894（VS Code拡張でSign-in failedになる報告）](https://github.com/openai/codex/issues/48894)の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のリリースノート](https://github.com/openai/codex/releases/tag/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に合わせます。 ```bash 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対応](https://blog.laozhang.ai/ja/posts/codex-cli-install)にあります。 ### `--no-daemon`で開くなら共有サーバー側の問題 ```bash 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日）](https://github.com/openai/codex/issues/48600)と[issue #52775](https://github.com/openai/codex/issues/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](https://github.com/openai/codex/issues/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日間動いていたサーバーのファイルディスクリプタ枯渇）](https://github.com/openai/codex/issues/37971)（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を明示しないとタイムアウトする報告）](https://github.com/openai/codex/issues/49921)（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）](https://github.com/openai/codex/issues/50211)の10月16日のコメント：会社のネットワークがchatgpt.comを遮断し、openai.com配下は通していたため、サインインは成功するのにその後が全部失敗。 - コミュニティ1404666：プロキシが`407 Proxy Authentication Required`を返していた原因は、SOCKS用のポートをHTTPプロキシとして指定していたこと。 バックグラウンドサーバーは最初に起動したセッションの環境変数を保持するので（issue #48195）、シェルでプロキシ変数を直しただけでは、動いているサーバーには届きません。変えたら再起動します。 ```bash export HTTPS_PROXY=$PROXY_URL export HTTP_PROXY=$PROXY_URL codex app-server daemon restart codex ``` `PROXY_URL`には、あなたのプロキシが待ち受けているアドレス（HTTPプロキシのポート）を入れます。ネットワーク自体が通っているかは、認証なしの要求を1本投げれば分かります。 ```bash 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](https://github.com/openai/codex/pull/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だった報告）](https://github.com/openai/codex/issues/54184)（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](https://community.openai.com/t/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一覧](https://github.com/openai/codex/issues)に版・OS・`codex login status`の出力・`exec`が動くかどうかを添えて報告するのが、残る行動です。 ## unauthorized (401)：認証情報のあるマシンで再サインイン `workspace routing discovery unauthorized (401)`は、discoveryの要求にバックエンドが401を返した状態です。[issue #47456（リモートホストが古いChatGPT認証を保持する報告）](https://github.com/openai/codex/issues/47456)（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経路](https://blog.laozhang.ai/ja/posts/codex-headless-login)にあります。 2. 動いている`codex app-server`とTUIを終了してから`codex`。 `codex login`の段階で403が出る場合は別の問題で、[Codexのトークン交換が403で失敗する原因と対処：ログインの段階から切り分ける](https://blog.laozhang.ai/ja/posts/codex-token-exchange-failed-403)が対象です。 ## duplicate workspace in routing discovery：アカウント側の問題 `duplicate workspace in routing discovery`は、discoveryの結果に同じワークスペースが2つ返ってきた状態です。[issue #47034（Windowsでサインイン成功後にduplicate workspaceで落ちる報告）](https://github.com/openai/codex/issues/47034)は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](https://github.com/openai/codex/issues/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つの方式でサインインし直すことです。 ```bash 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と同額](https://blog.laozhang.ai/ja/posts/codex-api-key-vs-subscription)にまとめてあります。 カスタムプロバイダーを使っている場合は、`[model_providers]`の設定で`env_key`と`requires_openai_auth = true`を同時に付けないことです。公式ドキュメントは「`requires_openai_auth = true`のとき、Codexは`env_key`を無視する」と明記しており、この設定があるとTUIは保存されたChatGPT側の認証状態を読みに行きます。設定の書き方は[Codex カスタムプロバイダー設定：APIキーとBase URLの選び方](https://blog.laozhang.ai/ja/posts/codex-config-toml)が対象です。 ## 4月の末尾なし版：古い認証キャッシュとrequires_openai_auth このエラーの元スレッドは[issue #17800](https://github.com/openai/codex/issues/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が開けばそこで止まります。 ![履歴を消さずに試す7つのステップ。3つの確認、サーバーの再起動か更新、--no-daemonでの確認、再サインイン、プロキシ、プロバイダー設定、行き止まりの順に並べた図](https://blog.laozhang.ai/posts/ja/codex-account-read-failed-tui-bootstrap/img/history-safe-order.webp) 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デスクトップがほぼ毎日サインインを求める報告）](https://github.com/openai/codex/issues/49443)、9月30日）。 - **毎日サインインを求められる**：macOSの26.924（issue #49443、9月30日）、Windowsの26.1007（[issue #53236](https://github.com/openai/codex/issues/53236)、10月12日；[issue #53520](https://github.com/openai/codex/issues/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で起動しない原因を環境別に切り分け](https://blog.laozhang.ai/ja/posts/codex-could-not-start-vscode)が扱っています。 ## 0.163.0で直ったのか：修正の記載はなく、10月17日にも報告 直っていません。版の流れは次のとおりです（[GitHubのリリース一覧](https://github.com/openai/codex/releases)、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](https://github.com/openai/codex/issues/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）](https://github.com/openai/codex/issues/18064)として別のスレッドがあります。 - `Operation not permitted (os error 1)`：OSの権限エラー（EPERM）で、この一覧の末尾ではありません。 - TUIが開いてからモデルへの要求で`401 Incorrect API key`が出る：認証情報とURLの組み合わせの問題で、[Codexの401「Incorrect API key」：URLとキーで原因を見分ける](https://blog.laozhang.ai/ja/posts/codex-401-incorrect-api-key)が対象です。 - `codex login`の途中で`token exchange failed`と403：サインインの段階の問題で、[Codexのトークン交換が403で失敗する原因と対処：ログインの段階から切り分ける](https://blog.laozhang.ai/ja/posts/codex-token-exchange-failed-403)が対象です。 - 起動後の送信で「メッセージの送信中にエラーが発生しました」：[Codex「メッセージの送信中にエラーが発生しました」は2行目で判断](https://blog.laozhang.ai/ja/posts/codex-error-submitting-message)が対象です。 ## 参考資料 本文で参照している外部ページを、登場順に並べています。最終更新日：2026-10-17。 - [Codexのソースコードのうちapp-serverのworkspace_routing.rs](https://github.com/openai/codex/blob/main/codex-rs/app-server/src/request_processors/account_processor/workspace_routing.rs) (github.com) - [TUI側のapp_server_session.rs](https://github.com/openai/codex/blob/main/codex-rs/tui/src/app_server_session.rs) (github.com) - [PR #52635「Skip background workspace routing reads without ChatGPT auth」](https://github.com/openai/codex/pull/52635) (github.com) - [issue #51052（WSL2でaccount/readが15秒でタイムアウト）](https://github.com/openai/codex/issues/51052) (github.com) - [OpenAI開発者コミュニティのスレッド1407111（0.163.0でTUIがaccount/readに失敗）](https://community.openai.com/t/1407111) (community.openai.com) - [rust-v0.157.0のリリースノート](https://github.com/openai/codex/releases/tag/rust-v0.157.0) (github.com) - [issue #48195（daemon_auto_startをオプトインにしてほしいという要望）](https://github.com/openai/codex/issues/48195) (github.com) - [公式の開発者コマンド一覧](https://learn.chatgpt.com/docs/developer-commands?surface=cli) (learn.chatgpt.com) - [issue #52928（-cを付けると起動する報告）](https://github.com/openai/codex/issues/52928) (github.com) - [コミュニティのスレッド1404666（0.162.0がプロキシ環境でTUI起動に失敗）](https://community.openai.com/t/1404666) (community.openai.com) - [issue #52775（0.162.1が-c log_dirなら起動する報告）](https://github.com/openai/codex/issues/52775) (github.com) - [issue #17800（4月に開かれた元スレッド）](https://github.com/openai/codex/issues/17800) (github.com) - [issue #48894（VS Code拡張でSign-in failedになる報告）](https://github.com/openai/codex/issues/48894) (github.com) - [rust-v0.163.0のリリースノート](https://github.com/openai/codex/releases/tag/rust-v0.163.0) (github.com) - [issue #48600（0.157.1でlog_dirを明示すると起動する報告、9月27日）](https://github.com/openai/codex/issues/48600) (github.com) - [issue #37971（8日間動いていたサーバーのファイルディスクリプタ枯渇）](https://github.com/openai/codex/issues/37971) (github.com) - [issue #49921（macOSデスクトップでHTTP_PROXYを明示しないとタイムアウトする報告）](https://github.com/openai/codex/issues/49921) (github.com) - [issue #50211（macOSのCLIでdiscovery failed）](https://github.com/openai/codex/issues/50211) (github.com) - [PR #52702](https://github.com/openai/codex/pull/52702) (github.com) - [issue #54184（実体は401 token_revokedだった報告）](https://github.com/openai/codex/issues/54184) (github.com) - [Codexのissue一覧](https://github.com/openai/codex/issues) (github.com) - [issue #47456（リモートホストが古いChatGPT認証を保持する報告）](https://github.com/openai/codex/issues/47456) (github.com) - [issue #47034（Windowsでサインイン成功後にduplicate workspaceで落ちる報告）](https://github.com/openai/codex/issues/47034) (github.com) - [issue #25428](https://github.com/openai/codex/issues/25428) (github.com) - [issue #49443（macOSデスクトップがほぼ毎日サインインを求める報告）](https://github.com/openai/codex/issues/49443) (github.com) - [issue #53236](https://github.com/openai/codex/issues/53236) (github.com) - [issue #53520](https://github.com/openai/codex/issues/53520) (github.com) - [GitHubのリリース一覧](https://github.com/openai/codex/releases) (github.com) - [issue #54462](https://github.com/openai/codex/issues/54462) (github.com) - [issue #18064（thread/start failed during TUI bootstrap）](https://github.com/openai/codex/issues/18064) (github.com)