Repository navigation
Windows desktop workspace settings blocked by Cloudflare challenge across restart/update; recovery after normal browser access, token refresh and Retry #51691
Description
The Windows desktop app failed to load workspace settings, blocking the new Work composer before a prompt was sent. This is separate from Responses WebSocket retries in #19821.
Recovery update: after the normal in-app browser access and proactive native account refresh described below, the user clicked the desktop Retry button once and confirmed that workspace settings loaded normally. Earlier post-refresh desktop requests still logged the challenge. The individual cause of recovery, whether all desktop endpoints recovered, and sustained health are not established. The report concerns the observed failure and recovery gap; it does not claim the composer is still blocked or that the platform is permanently fixed.
Observed locally on 2026-10-07:
-
Windows desktop registered/running package 26.1002.7124.0, bundled runtime 0.162.0-alpha.2. The same failure was observed on the previous desktop package.
-
Actual desktop request logs classify HTTP403 for /settings/user and /accounts/check/{version} as cloudflare_challenge. This is the installed client's classification when cf-mitigated is challenge, not an inferred OAuth401. Other desktop requests including /sentinel/heartbeat are also challenged.
-
Restarting into the newly installed package did not restore the composer. Retained failures appeared less than one minute after the new main process started. Earlier launches first logged similar failures about ten minutes after log startup; this is an observation, not a claimed token lifetime.
-
Edge with the same account loaded a normal Work composer and model menu. Account identity comparison was done privately; account values are not included here.
-
A normal in-app browser navigation to https://chatgpt.com/ first displayed a waiting/check page, then loaded ChatGPT automatically. No CAPTCHA interaction, cookie copying, custom headers or challenge bypass was used. Browser and desktop fetch-session equivalence is not established.
-
One supported proactive account/read refreshToken:true request completed through the installed native protocol. Later desktop requests still logged the challenge. This does not establish renderer token adoption or require proof that tokens rotated.
No official app files, authentication values, Cookie stores, routing, endpoint security or user conversations were modified. This report contains no account/chat IDs, private paths, prompts, drafts, screenshots, assets, headers, Cookie/token values, raw logs, precise network addresses or trace payload. The original tasks are preserved.
Please clarify the supported desktop recovery flow for a challenged settings/account response: can the app present the normal first-party challenge in the same request session, then invalidate/refetch workspace policy without losing drafts or replaying work? The inspected fetch-module auth retry predicate handles token-attached HTTP401; this limited source observation does not prove no other recovery handler exists.
Please distinguish client recovery gaps, desktop-specific request validation and network effects. Current evidence does not attribute the underlying challenge to an update, proxy, token expiry or account configuration. Web UI loading is not a proof of long-stream health or permanent repair.
Activity
github-actions commentedon Oct 7, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
0xdevalias commentedon Oct 17, 2026
Related settings-failure evidence and navigation diagnostics: our October 16 macOS sample shows the same workspace-settings warning with HTTP 503 “Unable to fetch authentication verification keys” on
/settings/userand/accounts/check/{version}, rather than the Cloudflare 403s in this report. The app also repeatedly left an existing chat for Home; the navigation timeline is in #53901. The recovery sequence reported here has not been verified for our 503 occurrence.Further read-only inspection on October 17 verified a more specific branch in our installed 26.1007.71326/build 20398 bundle: the Pages/Spaces availability calculation (
t3rinapp-shared-8340f229c2b3.js) explicitly returnsdisabledwhen thechatgptcapability result hasisError. This branch runs before the later feature-gate checks, so a capability error can disable availability without a feature flag itself defaulting off. The inspectedZPsroute guard redirects disabled availability to/; the Page navigation interceptor can forward that destination tonavigateInOwnerWindow.That strengthens the proposed error → disabled availability → Home redirect path. It remains static code evidence: we have not captured the capability state and navigation caller together for our October 16 occurrence, or proven which guard initiated each jump. Regardless of why availability is disabled, an unclaimed hidden prewarm's automatic redirect should not navigate/focus the user's active chat.
Main investigation and detailed diagnostics
See also: related reports
These links group matching symptoms, error responses, and suspected mechanisms for comparison. They do not label every report as a confirmed duplicate or establish a single backend cause.
Only selected technical observations are included. No raw logs, credentials, account/conversation identifiers, private paths, or screenshots are attached. No new live reproduction or verified fix is claimed.
csalvarado commentedon Oct 20, 2026
The browser-access + Retry recovery did not work on Windows with Codex app
26.1013.40934/ package26.1013.4894.0. Opening ChatGPT normally with the same account, refreshing the account session, returning to Codex, and pressing Retry still left the workspace-settings banner blocking the composer. Full restart, project-scoped chats, sign-out/sign-in, update checks, and changing network/VPN also failed. Cross-reference #55489 and #51917. This is an unsuccessful recovery data point, not a claim about the underlying challenge cause.