Desktop on Windows silently runs Codex inside WSL — opaque "error sending request" when WSL DNS returns AAAA-only and IPv6 is unroutable

What version of the Codex App are you using (From “About Codex” dialog)?

26.908.4834.0

What subscription do you have?

PRO

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

On Windows 11, Codex Desktop failed at two independent network operations
while the npm-installed Codex CLI worked perfectly on the same machine, same
account, same network and the same auth.json:

1. Sign-in:
   Token exchange failed: error sending request for url
   (https://auth.openai.com/oauth/token)
   Error code: token_exchange_failed

2. After signing in through the CLI (shared ~/.codex/auth.json), Desktop opened
   already authenticated, but every prompt failed with a request-sending error
   and retried in a loop with no output.

Root cause (found after several hours of diagnosis):

My config.toml contained, under [desktop]:
runCodexInWindowsSubsystemForLinux = true
integratedTerminalShell = "wsl"

So the Desktop app was executing Codex inside WSL, while every diagnostic I ran
(curl.exe, PowerShell, proxy checks, TLS checks) tested the Windows stack —
which was healthy. Inside WSL:

$ getent hosts auth.openai.com
2a06:98c1:310c::ac40:920f  auth.openai.com.cdn.cloudflare.net
2606:4700:4400::6812:29f1  auth.openai.com.cdn.cloudflare.net

$ getent hosts chatgpt.com
2606:4700:4408::ac40:9bd1  chatgpt.com
2a06:98c1:3101::6812:202f  chatgpt.com

AAAA-only. No A records returned. The WSL resolver (10.255.255.254) was being
intercepted by Tailscale MagicDNS (resolv.conf search list contained a
*.ts.net domain). IPv6 on this network is announced but unroutable:

curl.exe -4 POST auth.openai.com/oauth/token -> HTTP 400 in 0.21s
curl.exe -6 POST auth.openai.com/oauth/token -> HTTP 000 in 0.03s

So Codex inside WSL resolved AAAA-only, dialled IPv6, and failed at transport
level before any HTTP response — producing "error sending request" on both
auth.openai.com and chatgpt.com/backend-api.

Setting runCodexInWindowsSubsystemForLinux = false fixed both problems
immediately.

The bug I want to report is not the broken IPv6 — that is my network. It is
that nothing in the Desktop UI indicates that execution happens inside WSL,
and the error message reveals neither the network stack used nor the
underlying transport failure. This made the problem effectively
undiagnosable from the app.

What steps can reproduce the bug?

Preconditions:

• Windows 11 x64, Codex Desktop, WSL2 installed
• config.toml contains [desktop] runCodexInWindowsSubsystemForLinux = true
• Host network announces IPv6 but has no working IPv6 route
• A DNS interceptor (Tailscale MagicDNS in my case) causes the WSL resolver
  to return AAAA records only for auth.openai.com and chatgpt.com

Steps:

1. Launch Codex Desktop, sign in with Google.
   Browser OAuth succeeds; Desktop shows token_exchange_failed.
2. Sign in via CLI instead: npm i -g @openai/codex && codex login -> succeeds.
3. Relaunch Desktop: it picks up ~/.codex/auth.json and opens authenticated.
4. Submit any prompt -> request-sending error, infinite retry loop, no output.
5. Run the same prompt in the CLI -> works normally.
6. Set runCodexInWindowsSubsystemForLinux = false, restart Desktop
   -> both auth and inference work immediately.

Reproduced on two different networks.
No session id / token usage available: failures occur before a session exists.

What is the expected behavior?

1. Surface the real transport error. "error sending request for url (...)"
   should include the underlying cause (DNS resolution, TCP connect, TLS,
   timeout) and the address family actually attempted. The current message is
   indistinguishable between a dead proxy, a Cloudflare block, TLS
   interception and an unroutable IPv6 route — I ruled out the first three
   before finding the fourth.

2. Make the execution environment visible. When Desktop runs Codex inside
   WSL, the UI and error messages should say so. Every diagnostic a user
   naturally runs on Windows tests the wrong stack.

3. Fall back to IPv4 when an IPv6 connection fails fast. Happy Eyeballs
   (RFC 8305) behaviour would have made this invisible: curl and browsers on
   the same host fell back to IPv4 in milliseconds.

4. Stop the infinite retry loop. After N failed attempts the app should
   surface an actionable error instead of spinning indefinitely.

Additional information

Ruled out before finding the root cause (all tested on the Windows stack,
which turned out to be the wrong stack):

Note: HEAD on https://auth.openai.com (root) returns 403 with
cf-mitigated: challenge, which misleads diagnosis. POST on /oauth/token is
not challenged and returns normal JSON, so Cloudflare is not involved.

Environment: Codex Desktop [VERSION], Codex CLI [VERSION], Windows 11 x64,
WSL2, Tailscale running on the host, FRITZ!Box router.

Start with the [desktop] settings in config.toml, especially runCodexInWindowsSubsystemForLinux, and trace the sign-in and prompt request paths when execution uses WSL. Reproduce with the reported AAAA-only DNS and unroutable IPv6 setup, then verify that errors identify the execution environment and transport cause and that repeated failures stop instead of retrying indefinitely.