Codex Couldn't Load Workspace Settings: Diagnose the Desktop Error
Separate Codex desktop workspace-loading failures from broken local config. Check new chats, HTTP 403/432 and DeviceCheck errors, then verify recovery.
Ofox 
If Codex says it couldn’t load workspace settings, identify which request failed before changing config.toml or reinstalling the app. The message can appear while the application is open, and sometimes while the same chat still receives model replies. It does not by itself establish a broken configuration file, an unavailable model or a suspended account.
This guide is for the desktop application’s new-chat or workspace-loading error. A VS Code panel that cannot load its resources belongs to the extension resource-loading guide. A backend process that cannot start belongs to the Windows app-server guide.
Evidence checked on October 16, 2026: public reports in OpenAI’s Codex repository, with different versions and failure signatures. We have not reproduced these desktop failures on a controlled test machine. The comparison worksheet and recovery checks below are an editorial diagnostic method, not a claim that one repair works for every report. Ofox publishes this guide; an API service cannot repair the desktop application’s account initialization.
First separate the visible message from the failing operation
Before restarting, record the app version from its About screen, the operating system, the local time including timezone and what you were opening. Save unfinished work. You need the first failure, not a log collected after ten unrelated changes.
| What you observe | What it establishes | What to check next |
|---|---|---|
| New chat fails; an existing chat still works | Some existing state remains usable | Compare new chats with and without a project |
| The affected new chat can receive a reply despite the banner | Model conversation and workspace initialization are not failing identically | Inspect settings/account requests separately |
| Browser works at the same time; desktop fails | There is a useful client-specific difference | Record simultaneous tests and desktop errors |
| The terminal CLI works | That route can still operate | Do not assume desktop uses the same session or configuration |
| The process never starts | This is earlier than workspace initialization | Use app-server startup diagnostics |
A recent Windows report, #54168, documents a settings banner and a successful model reply in the same affected new chat. Its logs include workspace-routing and challenge errors, while local configuration reads succeed. That is a reason to test the actual operation rather than infer that the entire client is unavailable. It is not proof that all settings banners are harmless.
Run one small comparison instead of changing everything
Use a harmless prompt that does not invoke tools: “Reply with OK without reading files or running commands.” Do not use an active production task to test recovery. Record not tested when a route is unavailable; do not install another client just to complete the table.
| Test | Result to record |
|---|---|
| Existing desktop chat | Reply, blocked input, error, or not tested |
| New desktop chat without a project | Does it open, submit and receive a reply? |
| New chat in the affected project | Same three checks, recorded separately |
| Browser with the same intended account/workspace | Works or fails during the desktop incident |
| Already installed CLI, if applicable | Starts, authentication fails, or another error |
A different outcome narrows the investigation; it does not assign the cause. For example, a projectless chat working does not prove a project file is corrupt. Browser success does not show that the desktop follows the same network path or authentication flow.
Keep the account/workspace constant when comparing. Do not switch accounts, networks and app versions together: even if the error disappears, you will not know which change mattered.
Read the status, route and error together
Use the application’s diagnostics or locally stored desktop logs. Record only the relevant fields from the failure near your test time. The macOS reports below use ~/Library/Logs/com.openai.codex/; this is a reported location, not a guaranteed Windows or future-version path. On Windows, use the installed app’s supported diagnostics or OpenAI Support’s instructions rather than guessing a package directory and deleting it.
The following table summarizes reported signatures. It is not a copied log from our account.
| Fields in the same application log record | Interpretation supported by the record | Unsupported conclusion |
|---|---|---|
/settings/user or account check, 403, cloudflare_challenge | That request encountered a challenge | The account is banned or the proxy is definitely at fault |
Account check, logged status=500, devicecheck_token_generation_failed | The app reports a device-token generation failure | OpenAI returned an HTTP 500, or all workspace errors are DeviceCheck failures |
/settings/user, 432, workspace-routing message | That installation reports unavailable workspace routing | 432 has the same meaning on every API |
Successful local config/read alongside a settings request failure | Local config access can succeed during the incident | Remote initialization and all file operations succeeded |
fs/readFile requires an environmentId nearby | A file operation lacks required environment context | This is proven to cause the visible banner |
For the DeviceCheck branch, status=500 is an application-layer logged status; it does not establish that a request reached OpenAI or that the remote server returned HTTP 500. The October 15 clarification in issue #52342 explicitly makes this distinction.
Do not combine a 403 from one line, a route from another and a DeviceCheck error from a third into one invented request. A count of matching log lines is also not a count of users or unique failed actions.
If the record says Cloudflare challenge
Issue #52790 reports challenged settings/account requests on Windows. Signing out and back in helped one occurrence temporarily; other follow-ups did not recover that way. Treat reauthentication as a bounded diagnostic attempt, not a persistent fix.
After saving work and confirming you can sign back in, use the normal in-app sign-out/sign-in flow once. Reopen a new chat and repeat the same small test. Record whether recovery survives another new chat. Do not copy browser cookies into the desktop client, disable certificate verification or modify challenge tokens.
Issue #53994 describes recurring macOS failures, including after lock/unlock, while Chrome remained usable. Later diagnostics identify multiple error classes on different requests. Neither changing proxy modes nor browser success establishes a single root cause. If lock/unlock is your trigger, include that sequence in the report; do not label it an established trigger on machines you have not tested.
If the record says DeviceCheck
Issue #52342 describes new-chat failure with device-token errors on a specific macOS installation. The reporter’s CLI worked, and restarts and reauthentication did not resolve that case. This supports a separate diagnostic branch, not advice to reset every user’s credentials.
Record the exact app and macOS versions, whether the error is token generation or registration, and the failing request. Check for an eligible update through the normal updater. If no update is offered, preserve that result; an issue’s version number is not an instruction to install an old build. Do not bypass device attestation or remove managed security controls.
A recovery sequence with a stopping point
- Save and record. Preserve your work, first error, app version and test time. Do not erase the evidence by clearing all application data.
- Check service status. Look at OpenAI Status for an incident relevant to your product and time. A green status page does not prove your account-specific route is healthy.
- Check the app updater. Record the installed version and whether an eligible update exists. If you update, repeat the same test before making another change.
- Restart once when safe. Fully quit and reopen after active work is saved. A brief recovery that fails on the next new chat is temporary, not fixed.
- Follow the matching evidence branch. A challenged request, a device-token failure and a local startup failure require different information. Use reauthentication only through the normal flow and only when you can restore access.
- Stop if the same signature remains. Escalate with the worksheet below. Do not keep cycling through destructive reinstalls, different accounts and configuration rewrites.
If the browser or existing chat remains usable, it can be a temporary way to continue an appropriate task. Confirm the intended workspace and available tools; a working text reply does not establish file access, browser automation or the same task environment.
Verify more than a disappearing banner
Recovery should match the activity that failed. For a new-chat failure, open a fresh chat in the relevant project, send the harmless test and verify that the expected workspace is loaded. If file access is required, use a non-sensitive file you explicitly authorize and verify its contents were actually read. Do not infer success from a model saying it has access.
If the original trigger was a fresh window or lock/unlock, repeat that trigger only after saving work. Record the result as one observed recovery, not a universal stability guarantee. If a reply works but settings still fail, label the result partial recovery.
Use this support summary without including private logs:
Product: desktop application, not just terminal CLI
App version / OS version:
Failure time and timezone:
Trigger: new chat / new window / project / unlock / other
Existing chat / new projectless chat / project chat:
Simultaneous browser result:
Route pattern + status + error code from the same record:
Local config read: succeeded / failed / not checked
Changes tried, one at a time, with outcomes:
Recovery: none / temporary / partial / retest passedRemove tokens, cookies, authorization headers, account identifiers, private paths and conversation text before sharing diagnostics. Send sensitive material only through an appropriate private support channel when requested. The goal is a reproducible failure description, not a large public log dump.
Where to go if the error is different
- A CLI dialog about incompatible background-server features: compare the CLI and daemon settings.
- A running request disconnects before completion: diagnose the transport interruption.
- Chat works but desktop or browser control fails: check Computer Use permissions and connections.
These are different stages. Fixing one does not validate the others, and changing the model or API provider is not a demonstrated repair for workspace-settings initialization.
