[Windows] "Organization settings could not be loaded" gate blocks startup; app-server never spawns; codex app-server daemon start fails with os error 5 #50608

Version / platform

Desktop (Microsoft Store MSIX) OpenAI.Codex 26.930.3930.0 (x64), bundled CLI / app-server 0.160.0. codex doctor: 22 ok, 0 fail. ChatGPT Plus, personal workspace (no Business/Enterprise). Windows 11 build 10.0.26200, zh-CN. Internet access requires a local HTTP proxy (system proxy enabled, 127.0.0.1:9674).

What I am seeing

On every launch the desktop app shows the native modal "Organization settings could not be loaded" ("The app is paused until your organization settings can be loaded safely. A network connection, proxy, or firewall may be preventing access. Check your connection and try again, or sign out and use another account..."). Buttons: Retry / Sign out / Quit.

The app never renders its UI, and no Codex backend process is ever spawned.

Retry, Sign out and signing back in, switching proxy exit nodes, resetting the app package data (311.9 MB -> 3.9 MB), and even launching with a fresh empty CODEX_HOME all reproduce it. Codex CLI and Codex on the web work fine on this machine with the same account and network. This started right after the desktop app and the standalone CLI were updated.

Evidence

1. The app fails before its own logging subsystem initializes. Logs normally land in %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\<yyyy>\<MM>\<dd>\codex-desktop-*.log. The last log file is from the last successful run and shows working requirements reads:

info [AppServerConnection] response_routed ... method=configRequirements/read ... durationMs=2   errorCode=null
info [AppServerConnection] response_routed ... method=configRequirements/read ... durationMs=97  errorCode=null

Every launch afterwards (8 launches, including after an app-package reset) produced zero new log files, even though that directory is writable by this user.

2. The app-server is never spawned. Sampling the process tree for 40 s after launch, only the Electron main process plus helpers exist (crashpad-handler, gpu-process, network.mojom.NetworkService, storage.mojom.StorageService):

 5s: ChatGPT.exe 6 processes | codex.exe backend 0
10s: ChatGPT.exe 6 processes | codex.exe backend 0
...
30s: ChatGPT.exe 6 processes | codex.exe backend 0

No renderer process, no \\.\pipe\codex-*, no app-server-control.sock.

3. codex app-server daemon start fails deterministically - this is the exact operation the app needs during startup:

PS> codex app-server daemon start
Installing daemon from CLI version 0.160.0 into C:\Users\<user>\.codex\packages/app-server-daemon...
Error: 拒绝访问。 (os error 5)

PS> codex app-server daemon version
Error: failed to connect to C:\Users\<user>\.codex\app-server-control\app-server-control.sock
Caused by:
    套接字操作遇到了一个已死的网络。 (os error 10050)

This is not a generic filesystem permission problem: the same user can write to that very directory, and the ACL grants FullControl (inherited) to SYSTEM, Administrators and the user:

OK   C:\Users\<user>\.codex\packages\app-server-daemon\releases\_t.tmp
OK   C:\Users\<user>\.codex\packages\app-server-daemon\_t.tmp

4. Cloudflare challenges the workspace-policy endpoint while a sibling endpoint succeeds. Using the account's stored ChatGPT token through the same proxy:

Identical with a Chrome User-Agent, with a codex/0.160.0 User-Agent, and with no User-Agent at all; the body is the Cloudflare interstitial. The app-server itself does honor the system proxy and reaches the backend:

INFO codex_http_client::client: Request completed method=GET
  url=https://chatgpt.com/backend-api/codex/models?client_version=0.160.0 status=200 OK
DEBUG reqwest::connect: proxy(http://127.0.0.1:9674/) intercepts 'https://chatgpt.com/'

What I already ruled out

• config.toml corruption: 3837 bytes, 0 NUL bytes, no BOM, parses cleanly with tomllib; codex doctor reports config.toml parse ok and config loaded.
• Local user-state corruption: launching with a brand-new empty CODEX_HOME reproduces the failure identically.
• Database corruption: codex doctor reports rollout files and state DB thread inventory agree; all SQLite integrity checks ok.
• Auth: stored auth mode: chatgpt, tokens present and valid.
• App package data: reset via Windows Settings, relaunch -> same modal.
• Reinstall / app update: the issue survived both.
• Proxy node switch and sign out / sign in: no change.

Expected behavior

With healthy local data, valid auth and a working network path to the backend, the desktop app should load its workspace requirements and start, as it did before the update.

Suggestions

1. Surface the underlying error (file/line, or the failing fetch with its HTTP status) instead of the generic network/proxy/firewall text - duplicate reports show users reinstalling and renaming data directories for hours.
2. If organization settings cannot be loaded, fall back to unrestricted defaults instead of hard-blocking the app before the renderer starts.
3. Investigate whether codex app-server daemon installation can fail with os error 5 on machines where the target directory is writable, and whether the desktop app reports that failure as a policy-load failure.
4. Treat a Cloudflare challenge (HTTP 403 + Cf-Mitigated: challenge) on /backend-api/accounts/*/workspace_policy as retryable/transient rather than a hard block.

Related reports

#49663, #49469, #50311, #49845