Codexでワークスペース設定を読み込めないとき：ログと操作を分けて切り分ける

Codexで「Couldn't load workspace settings」と表示されたら、config.tomlの変更やアプリの再インストールを始める前に、どの処理が失敗したのかを切り分けます。アプリが開いていてもこの表示は出ますし、同じチャットでモデルの返答を受け取れる場合もあります。表示だけで、設定ファイルの破損、モデルの停止、アカウント停止とは判断できません。

この記事はOfox運営チームによる英語ガイドの日本語版です。AI支援で翻訳・編集しました。対象はデスクトップアプリで新しいチャットを開く際やワークスペースを読み込む際のエラーです。OfoxはAPIサービスを提供していますが、APIサービスへの切り替えはデスクトップのアカウント初期化を修復する方法ではありません。

元の調査は2026年10月16日にOpenAIのCodexリポジトリ内の公開報告を確認したもので、バージョンも失敗の特徴も異なる事例を扱っています。私たちは管理されたテスト環境でこれらの不具合を再現していません。以下の比較表と復旧確認は、報告を基に編集した診断手順であり、すべての報告に効く修復方法ではありません。

2026年10月25日の出典再確認： #52342は現在closedです。10月21〜23日のコメントには、更新後にワークスペースの読み込みが回復したという報告と、その後も別のdot送信エラーが残ったという報告があります。後者の原因が同じとは確認されていません。過去のバージョンでの失敗を現在の全環境に当てはめず、自分のインストールに提供される更新と、失敗している操作を確認してください。

VS Codeパネルのリソースが読み込めない場合や、バックエンドプロセス自体が起動しない場合は、これより前段階の別の問題です。また、正確な表示がPermission mode is unavailableで入力が未送信のままなら、まず送信処理と権限モードを調べます。似た文言だけで同じ原因と結び付けないでください。

1. 表示されたメッセージと、失敗した処理を分ける

再起動前に、About画面のアプリバージョン、OS、タイムゾーン付きの発生時刻、何を開こうとしていたかを記録し、未保存の作業を保存します。必要なのは最初の失敗の記録です。無関係な変更を10回行った後のログだけでは切り分けにくくなります。

観測したこと	そこから分かること	次に調べること
新しいチャットは失敗するが、既存チャットは使える	既存の状態の一部は利用できる	プロジェクトあり・なしの新規チャットを比べる
エラーの出ている新規チャットでも返答を受け取れる	モデルとの会話とワークスペース初期化は同じようには失敗していない	設定・アカウント要求を別に調べる
同時刻にブラウザは動くがデスクトップは失敗する	クライアント間の比較材料がある	同時刻のテスト結果とデスクトップのエラーを記録する
ターミナルのCLIは動く	その経路では操作できる	デスクトップと同じセッションや設定だとは考えない
プロセス自体が起動しない	ワークスペース初期化より前の問題である	app-serverの起動診断に進む

Windowsの公開報告#54168では、エラーの出ている同じ新規チャットで設定読み込みの警告と正常なモデルの返答が共存しています。ログにはワークスペースのルーティングやchallengeのエラーがある一方、ローカル設定の読み取りは成功していました。このため、クライアント全体が使えないと推測するのではなく、実際の操作を確認する必要があります。すべての設定エラーが無害という意味ではありません。

2. 一度にすべてを変えず、小さな比較をする

ツールを呼び出さない無害な入力を使います。

Reply with OK without reading files or running commands.

「ファイルを読まず、コマンドを実行せず、OKとだけ返答してください」という意味です。稼働中の本番作業を復旧テストに使わないでください。利用できない経路は「未テスト」と記録し、表を埋めるためだけに別のクライアントをインストールする必要はありません。

テスト	記録する結果
既存のデスクトップチャット	返答あり／入力がブロック／エラー／未テスト
プロジェクトなしの新規チャット	開けるか、送信できるか、返答を受け取れるか
問題のプロジェクト内の新規チャット	同じ3点を個別に記録
同じ意図したアカウント・ワークスペースのブラウザ	デスクトップでの発生中に動くか、失敗するか
既にインストールされているCLI（該当する場合）	起動するか、認証失敗か、別のエラーか

結果の違いは調査範囲を狭めますが、原因を確定しません。プロジェクトなしなら動くとしても、プロジェクトのファイルが壊れた証拠にはなりません。ブラウザが動いても、デスクトップが同じネットワーク経路や認証フローを使っているとは限りません。

比較中はアカウントとワークスペースを一定に保ちます。アカウント、ネットワーク、アプリバージョンを一度に変えると、エラーが消えても何が効いたのか分かりません。

3. ステータス・経路・エラーを同じ記録で読む

アプリの診断機能や、ローカルに保存されたデスクトップログを使い、テスト時刻付近の失敗から必要なフィールドだけを記録します。参照したmacOSの報告では~/Library/Logs/com.openai.codex/が使われています。現在の公式トラブルシューティングにもmacOSのログ場所が案内されていますが、Windowsや将来のバージョンで同じ場所とは限りません。Windowsではアプリの正式な診断手段やサポートの案内を使い、推測したパッケージディレクトリを削除しないでください。

以下は公開報告に出てくる特徴を整理した表です。私たちのアカウントのログを転載したものではありません。

同じログ記録にあるフィールド	記録が支持する解釈	そこまでは言えないこと
/settings/userまたはアカウント確認、403、cloudflare_challenge	その要求がchallengeに遭遇した	アカウント停止、またはプロキシが確実に原因
アカウント確認、ログ上のstatus=500、devicecheck_token_generation_failed	アプリがデバイストークン生成の失敗を報告した	OpenAIがHTTP 500を返した、または設定エラーがすべてDeviceCheck由来
/settings/user、432、workspace-routingのメッセージ	そのインストールでワークスペースのルーティングが利用できないと報告された	432がすべてのAPIで同じ意味を持つ
設定要求の失敗と並んでローカルのconfig/readは成功	障害中にもローカル設定を読める場合がある	リモート初期化やすべてのファイル操作が成功した
近くにfs/readFile requires an environmentIdがある	ファイル操作に必要な環境情報が欠けている	これが画面の警告の原因だと確定した

DeviceCheckの分岐では、status=500はアプリケーション層で記録された値です。その要求がOpenAIに届いたことや、リモートサーバーがHTTP 500を返したことを示すわけではありません。#52342の10月15日の補足でも、この区別が説明されています。

ある行の403、別の行の経路、さらに別の行のDeviceCheckエラーを結合して、一つの架空の要求を作らないでください。条件に一致するログ行の数も、利用者数や重複のない失敗操作数ではありません。

4. Cloudflare challengeと記録されている場合

#52790には、Windowsで設定・アカウント要求がchallengeに遭遇した報告があります。サインアウトと再サインインで一時的に回復した例がある一方、同じ方法で回復しなかった続報もあります。再認証は範囲を限定した診断の試行であり、永続的な修復とは扱いません。

作業を保存し、サインインし直せることを確認したうえで、通常のアプリ内操作によるサインアウト・サインインを一度行います。新しいチャットを開き、同じ小さなテストを繰り返します。さらに別の新規チャットでも回復が続くか記録してください。ブラウザのCookieをデスクトップへコピーしたり、証明書検証を無効にしたり、challengeトークンを書き換えたりしてはいけません。

#53994では、Chromeは使える一方で、macOSのロック解除後などにデスクトップの失敗が繰り返されています。後続の診断では、異なる要求に複数種類のエラーが確認されています。プロキシモードの変更やブラウザでの成功だけから単一の根本原因は決められません。自分の環境でロック・解除が引き金なら、その手順を報告に含めます。確認していない端末にも共通の引き金だとは書かないでください。

10月25日に確認した#52790の後続コメントには、別のWindows環境で、先行するローカルのプロキシ更新処理がユーザープロキシ設定を変えていたとする説明もあります。これはその端末の調査結果です。元のCloudflare challenge報告と同じ原因だとは確認されておらず、全員にレジストリ変更を勧める根拠にもなりません。

5. DeviceCheckと記録されている場合

#52342の当初の報告は、特定のmacOS環境でデバイストークンのエラーにより新規チャットが失敗するというものでした。CLIは動き、再起動や再認証では解決しなかったとされています。この情報が支持するのは診断の分岐であり、すべての利用者の認証情報をリセットする助言ではありません。冒頭のとおり、後日の更新で読み込みが回復した報告もあります。

アプリとmacOSの正確なバージョン、失敗がトークンの「生成」なのか「登録」なのか、失敗した要求を記録します。通常のアップデーターで、そのインストールに提供される更新を確認してください。更新が表示されなければ、その結果を残します。Issueに書かれたバージョン番号は、古いビルドを入れる指示ではありません。デバイスの検証を回避したり、管理されたセキュリティ制御を外したりしないでください。

6. 復旧手順と、試行を止める基準

1. 保存して記録する。 作業、最初のエラー、アプリバージョン、テスト時刻を残します。アプリの全データ消去で証拠を失わないようにします。
2. サービス状況を見る。 OpenAI Statusで、対象の製品と時刻に関係する障害を確認します。緑色でも、自分のアカウントに固有の経路が正常とは限りません。
3. アプリの更新を確認する。 インストール済みバージョンと、提供される更新の有無を記録します。更新したら、別の変更を加える前に同じテストを繰り返します。
4. 安全な時点で一度再起動する。 作業を保存してから完全終了し、開き直します。次の新規チャットで再発するなら「一時的な回復」であって「修復済み」ではありません。
5. 証拠に合う分岐を進める。 challenge、デバイストークン、ローカル起動の失敗では必要な情報が異なります。再認証は通常の操作だけを使い、再びアクセスできる場合に限って試します。
6. 同じ失敗が残ったら止める。 下の記録票を添えてサポートへ引き継ぎます。データを失う再インストール、アカウント変更、設定書き換えを延々と繰り返さないでください。

ブラウザや既存チャットが使えるなら、適切な作業を一時的に続ける手段にはなります。ただし、意図したワークスペースと利用できるツールを確認します。テキストの返答が来ることは、ファイルへのアクセス、ブラウザ自動操作、同じタスク環境が使えることの証明ではありません。

7. 警告が消えただけで復旧としない

確認する操作は、失敗した操作と対応させます。新規チャットの失敗なら、対象プロジェクトで新しいチャットを開き、無害なテストを送信し、期待するワークスペースが読み込まれたかを確かめます。ファイルアクセスが必要なら、自分が明示的に許可した機密性のないファイルを使い、実際に内容が読み取られたことを確認します。「アクセスできる」というモデルの返答だけで判断しないでください。

元の引き金が新しいウィンドウや画面のロック・解除なら、作業保存後にその操作も再現します。結果は「一度観測できた回復」と記録し、普遍的な安定性の保証とはしません。返答は来ても設定の失敗が残るなら、部分的な回復です。

サポートへの要約には次の記録票を使えます。非公開ログ全体を貼り付ける必要はありません。

製品：デスクトップアプリ（ターミナルCLIだけの問題ではない）
アプリバージョン／OSバージョン：
発生時刻とタイムゾーン：
引き金：新規チャット／新規ウィンドウ／プロジェクト／ロック解除／その他
既存チャット／プロジェクトなし新規チャット／プロジェクト内チャット：
同時刻のブラウザでの結果：
同じログ記録のroute pattern + status + error code：
ローカル設定の読み取り：成功／失敗／未確認
一つずつ試した変更と、それぞれの結果：
回復：なし／一時的／部分的／再テスト合格

共有前にトークン、Cookie、Authorizationヘッダー、アカウント識別子、非公開のパス、会話内容を除きます。機密情報が求められた場合も、適切な非公開サポート経路だけで送ります。目的は再現可能な失敗の説明であり、大量の生ログを公開することではありません。

別のエラーなら、別の段階を調べる

• CLIがbackground-serverの機能設定の不一致を表示する場合は、CLIとdaemonの設定の整合性を調べます。
• 実行中の要求が完了前に切断される場合は、通信の中断を調べます。
• 会話は動くがデスクトップやブラウザの操作が失敗する場合は、Computer Useの権限と接続を調べます。

それぞれ異なる段階の問題です。一つが直っても、ほかの正常性は確認できません。モデルやAPIプロバイダーの変更が、ワークスペース設定の初期化を修復することも示されていません。

英語の元記事と関連する症状別ガイド：Codex couldn’t load workspace settings: a diagnostic checklist