[Bug] reqwest HTTP clients missing User-Agent override → Cloudflare 403 from HKG edge on Codex Desktop 26.422.x

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• ##17538
• # #17596
• # #17412
• # #17599
• # #17680

Powered by Codex Action

Updated the issue body with post-reset diagnostics.

Key new point: this started immediately after the in-app desktop upgrade, and still reproduces after reinstall, %USERPROFILE%\.codex rebuild, switching networks, forcing an external codex.exe, and full Reset-AppxPackage.

Fresh post-reset logs still show:

• Bundled plugins marketplace has no enabled plugins.
• unsupported feature enablement 'realtime_conversation'

Further diagnostics after forced re-login and workspace-state reset:

Additional update (Apr 24, 2026)

I have more concrete evidence now. The issue is not just account state, and it is not fixed by forced re-login.

New desktop findings:

• I forced a full desktop re-auth by backing up/removing the shared auth files and re-logging into the desktop app.
• Login itself succeeded, but the desktop symptoms still remained unchanged:
• slash commands still do not open
• Chinese / locale behavior is still wrong
• Fast Mode is still missing / not usable
• This strongly suggests the remaining problem is not stale auth or account switching residue.

New workspace-binding findings:

• I reset the desktop workspace state and Electron storage, then re-tested project binding.
• There was a temporary state where the UI appeared to bind D:\luosiwang correctly and I could see the previous project-related content again.
• However, the runtime still continued to generate invalid workspace paths in the background.
• The latest desktop logs now consistently show workspace path resolution failures such as:
• ENOENT: path does not exist: ~
• ENOENT: path does not exist: /mnt/d/luosiwang/d:\luosiwang
• This means the desktop app can appear to bind the project at the UI/state layer, but its runtime path normalization is still broken internally.
• After that, the project picker / secondary project window can open as a blank white window.

Important implication:

• This no longer looks like simple auth corruption or ordinary local cache corruption.
• It looks more like a Windows desktop workspace/path normalization regression, especially on a machine where WSL is installed/enabled.

What I tried on desktop:

• Microsoft Store reinstall
• rebuilding %USERPROFILE%\.codex
• logging out and back in
• switching networks, including a Vietnam mobile hotspot
• forcing an external codex.exe
• Reset-AppxPackage for OpenAI.Codex
• clearing desktop web/session storage:
• Cookies
• Local Storage
• Session Storage
• SharedStorage
• DIPS
• forcing a full auth reset by backing up/removing:
• %USERPROFILE%\.codex\auth.json
• %USERPROFILE%\.codex\cap_sid
• the corresponding WSL-side auth file
• resetting desktop workspace state by clearing:
• electron-saved-workspace-roots
• project-order
• active-workspace-roots
• re-binding D:\luosiwang
• starting the desktop app again with a plain Windows working directory instead of the current shell context

Result after all of the above:

• auth can be re-established successfully
• desktop renderer can load
• plugin/bootstrap calls can partially proceed
• but the app still internally resolves broken workspace paths and the UI behavior remains incorrect

Related VS Code extension findings:

• The VS Code extension on this machine also entered the same broken family of symptoms after newer updates.
• On Windows, the extension required a real WSL distro to behave correctly in agent mode, so I installed Ubuntu WSL and set it as the default distro.
• After that, the extension still behaved badly on the newer version chain, but downgrading the extension to:
• openai.chatgpt-26.5417.40842

restored the extension enough to be usable again on this machine.

• In contrast, the desktop app remains broken even after all of the recovery steps above.
• So at the moment, the VS Code extension can be made usable via downgrade, but the Windows desktop app cannot be reliably recovered locally.

Current conclusion:

• not an entitlement issue
• not just multi-account residue
• not fixed by forced re-login
• not fixed by reinstall/package reset
• appears to be a desktop-app regression involving workspace/project path handling on Windows

Root cause identified — this is a client-side bug, not an environment issue

Diagnosed on the affected machine with curl probes against the same Cloudflare
edge that Codex Desktop is hitting. All symptoms reduce to one cause: some
Rust reqwest HTTP clients inside Codex are not overriding the default
User-Agent, so requests from those clients get 403'd by OpenAI's WAF.

Environment

• Codex Desktop: 26.422.2437.0 (Microsoft Store MSIX,

package OpenAI.Codex_2p2nqsd0c76g0)

• OS: Windows 11 Pro 10.0.28000
• Network: Viettel Vietnam residential ADSL (AS7552), IP 171.244.120.240
• Cloudflare edge: CF-RAY 9f13cf24fae90707-HKG (Hong Kong POP)
• Account works normally on another machine — same account, same region,

different Codex version / different CF routing.

curl probes — same machine, same network, varying only User-Agent

| UA | URL | Status |
|---|---|---|
| Mozilla/5.0 ... Chrome/131 | https://chatgpt.com/ | 200 |
| Mozilla/5.0 ... Chrome/131 | .../backend-api/plugins/featured | 401 (auth needed — OK, CF passes) |
| Codex-Desktop/26.422.2437.0 | .../backend-api/plugins/featured | 401 (OK) |
| codex-desktop / codex/1.0 / Electron/Codex | .../backend-api/plugins/featured | 401 (OK) |
| reqwest/0.12.0 | .../backend-api/plugins/featured | 403 <html>... ❌ |
| curl/8.x (default) | .../backend-api/plugins/featured | 403 <html>... ❌ |
| OpenAI/Codex | .../backend-api/plugins/featured | 403 <html>... ❌ |

Conclusion: OpenAI's Cloudflare WAF (on the HKG POP at least) blocks the bare
reqwest/* UA. Codex-Desktop/... passes. Any Codex internal HTTP client
that forgets to set the UA override falls through to reqwest's default and
gets 403'd.

Matching evidence from ~/.codex/logs_2.sqlite

Cross-posted to OpenAI Community for staff visibility:
https://community.openai.com/t/codex-desktop-windows-msix-hkg-edge-returns-403-reqwest-ua-not-overridden-empty-plugins-marketplace-slash-commands-gone-fast-mode-missing/1379677

Tagging folks who've been most active on Desktop / plugins / Windows issues recently —
apologies for the ping, but this has been open 3 days with no triage response and the
root cause is confirmed (reqwest UA + CF 403 at HKG edge, reproducible via curl):

@etraut-openai — you've been closing the bulk of Desktop bug reports lately
@xli-oai — plugin install writes / marketplace RPC is exactly what's broken here
@iceweasel-oai — Windows-side specialist, this is Windows MSIX specific
@tibo-openai — senior eyes on a client/server CF-WAF interaction issue

TL;DR: curl -A "reqwest/0.12.0" https://chatgpt.com/backend-api/plugins/featured
returns 403 from CF-RAY ...-HKG. Same URL with a browser UA returns 200. Some Codex
reqwest clients aren't setting a UA, so CF blocks them. Either (a) set UA on
codex_analytics, codex_core::plugins::manager::warm_featured_plugins, and
codex_core::plugins::startup_sync, or (b) allowlist reqwest/* at CF edge.

Happy to test any proposed fix from the affected machine.

@etraut-openai / @xli-oai / @iceweasel-oai / @tibo-openai

Additional VS Code extension regression evidence:

I downgraded the VS Code extension back to openai.chatgpt-26.5417.40842-win32-x64, and with that version everything works normally again on the same machine.

After upgrading to the newer VS Code extension version, I can reproduce the same failure family as Codex Desktop. The current installed version on my machine is openai.chatgpt-26.5422.21459-win32-x64.

The VS Code extension logs now show the bundled Codex app-server hitting the same 403 failures:

• codex_core::plugins::startup_sync: https://chatgpt.com/backend-api/plugins/list returns 403
• codex_core::plugins::manager: https://chatgpt.com/backend-api/plugins/featured returns 403
• codex_analytics::client: analytics events also return 403

The response body is Cloudflare challenge HTML, matching the curl User-Agent diagnosis.

I also noticed a new sync symptom in the VS Code extension: chat history does not reliably sync by itself. I have to reopen Codex Desktop before the VS Code extension sees the updated chat history again.

The VS Code logs also show app-server transport pressure after startup, including messages like:

• dropping overload response ... outbound queue is full
• Server overloaded; retry later.

So this looks like the newer VS Code extension and Codex Desktop share the same underlying Codex runtime / HTTP client regression. The older VS Code extension version 26.5417.40842 works normally, while newer versions reproduce the 403/plugin/history-sync failure family on the same machine, same account, same network.

Update after upgrading to 26.422.3464.0 / app-server 0.125.0-alpha.3

Bug not fixed in latest version. Same root cause confirmed, with new evidence:

4 endpoints now confirmed affected (from logs after reboot, fresh build):

• chatgpt.com/backend-api/plugins/featured → 403
• chatgpt.com/backend-api/plugins/list → 403
• ab.chatgpt.com/otlp/v1/metrics → 403 (new)
• chatgpt.com/backend-api/codex/analytics-events/events → 403 (new)

Critical narrowing: REST HTTP requests fail, WebSocket works fine.
The model-streaming WebSocket (responses_websocket via tokio-tungstenite) connects
and streams responses normally — the user can chat with the model. Only the
reqwest-based REST clients fail.

→ This isolates the bug to the Rust reqwest HTTP client stack specifically.
The WebSocket stack uses different connection logic with a different default UA,
which CF doesn't block.

Affected modules from logs:

• codex_analytics::client (analytics-events)
• codex_core::plugins::manager::warm_featured_plugins (plugins/featured)
• codex_core::plugins::startup_sync (plugins/list)
• opentelemetry-otlp HttpMetricsClient (otlp/v1/metrics) — uses reqwest::blocking

Likely upstream cause of #19239 too — enable_i18n feature flag fetch

#19239 reports that Codex Desktop UI doesn't switch language despite
localeOverride=zh-CN and --lang=zh-CN. The reporter (correctly) suspects
a remote feature flag enable_i18n is gated.

This is almost certainly the same CF 403 root cause. The feature-flag
fetch is yet another reqwest HTTP call that's 403'd at the HKG edge → flag
defaults to false → i18n strings never loaded → UI stays English.

So the symptom cluster downstream of this single bug now includes:

• Plugins marketplace empty
• Slash commands missing from UI
• Fast Mode unavailable
• Settings menu broken
• Language switching not working (#19239)
• Analytics events failing
• OTLP metrics failing

Strongly suggest cross-linking #19239 — fixing the reqwest UA / CF allowlist
will likely close that issue too.

I can reproduce a very similar User-Agent-dependent Cloudflare challenge from a Chromebook/Crostini Linux environment.

Environment:

• Platform: Chromebook / Crostini Debian Linux
• Network A: home fiber connection
• Network B: mobile tethering
• Same ChatGPT/Codex account
• macOS on the same home fiber connection works
• Chromebook/Crostini on mobile tethering works
• Chromebook/Crostini on home fiber is blocked

Diagnostic result from the Chromebook/Crostini environment on the home fiber connection:

1. Without an explicit browser-like User-Agent:

• HTTP 403
• cf-mitigated: challenge present

1. With a Chrome-like User-Agent:

• HTTP 401 Unauthorized
• cf-mitigated: challenge absent

This suggests that, at least in my environment, the Cloudflare block is not solely caused by TLS fingerprinting. HTTP-layer signals such as User-Agent appear to affect the decision. The 401 response indicates that the request passed Cloudflare and reached the application layer, while the 403 response was a Cloudflare challenge.

I also searched the Codex repository for user_agent. I could find User-Agent setup in tests, but I could not find clear production code ensuring that all reqwest clients set a Codex-specific User-Agent.

This seems consistent with this issue’s hypothesis that some reqwest-based HTTP clients may be using a default or missing User-Agent and getting challenged by Cloudflare.