[Windows App][WSL] ChatGPT sign-in hangs on consent page although localhost:1455 callback listener is reachable

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

26.803.5235.0

What subscription do you have?

ChatGPT Business

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64+"Ubuntu 26.04 LTS"

What issue are you seeing?

Primary issue: WSL sign-in does not complete

Codex Desktop for Windows cannot complete Sign in with ChatGPT when Agent environment = WSL.

The browser-based ChatGPT login reaches the Codex consent/workspace-selection page successfully. After selecting my ChatGPT Business workspace and continuing, however, the page remains on a loading spinner indefinitely and Codex Desktop never becomes authenticated.

Supplementary observation: switching a working Windows-native session to WSL also breaks Codex

This is an additional observation and does not replace the WSL login issue above.

With Agent environment = Windows native, the same Codex Desktop installation, machine, network, and ChatGPT Business account can sign in and use Codex normally. If I then change Agent environment from Windows native to WSL and restart Codex Desktop, the previously working session no longer works. Requests consistently fail with:

stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)

The separate Integrated terminal Shell = PowerShell setting is not the environment being compared here.

Key difference from the suggested duplicates

The primary issue is the WSL-backed OAuth flow hanging on a valid sign-in path. The Windows-native-to-WSL transition is supplementary evidence that the failure is isolated to the WSL-backed Agent environment:

• Windows native is the working control: sign-in completes and Codex works normally.
• A direct sign-in attempt with Agent environment = WSL hangs and never authenticates Codex Desktop.
• A session that already works under Windows native also stops working after switching the Agent environment to WSL and restarting.
• The WSL-backed session then consistently fails at https://chatgpt.com/backend-api/codex/responses.

This differs from #37467, where authentication fails on both Windows and WSL, and from #36490, which reports a Codex CLI token-exchange failure on a specific Windows PC. In this case, the exact same Codex Desktop installation works in Windows native, while both sign-in and post-switch usage fail in the WSL-backed environment.

Importantly, this does not look like a simple case where the local OAuth callback server is missing or port 1455 is blocked.

Evidence 1: successful-auth path hangs even though the callback request is created

During the hanging login attempt, the browser reaches the workspace consent page and a request to the local callback endpoint is visible, but the flow never completes.

<img width="2048" height="1062" alt="Image" src="https://github.com/user-attachments/assets/a1e3cb74-15c6-4b83-b465-6867d5ee284b" />

Evidence 2: the consent page itself is reachable through the proxy

Browser DevTools shows the Codex consent data request succeeds:

GET https://auth.openai.com/sign-in-with-chatgpt/codex/consent.data?...
HTTP 200 OK
Remote address: 127.0.0.1:7897

So the browser can reach auth.openai.com through the configured local HTTP proxy.

<img width="2048" height="922" alt="Image" src="https://github.com/user-attachments/assets/4400b6c6-67cc-4b6c-901e-0ea42bf63ba7" />

Evidence 3: the error path can complete and surface a token-exchange error

With a network/auth path that is rejected by the token endpoint, the callback flow completes far enough to surface this error in both the browser and Codex Desktop:

Sign-in could not be completed

Error code:
token_exchange_failed

Details:
Token exchange failed: token endpoint returned status 403 Forbidden:
Country, region, or territory not supported

<img width="544" height="266" alt="Image" src="https://github.com/user-attachments/assets/1d6a9967-b9dd-433a-ba1b-2bd541d4c898" />

This behavior is particularly interesting because the error path returns a concrete result, while the normal/valid path remains stuck indefinitely.

Evidence 4: the WSL callback server is actually listening on 127.0.0.1:1455

Inside WSL:

LISTEN 0 128 127.0.0.1:1455 0.0.0.0:* users:(("codex",pid=<redacted>,fd=36))

The listener is owned by the codex process.

<img width="1351" height="182" alt="Image" src="https://github.com/user-attachments/assets/4ac4e097-0102-4379-aaea-44a871559811" />

Evidence 5: Windows can establish TCP connections to the callback listener

From Windows, connections to 127.0.0.1:1455 reach ESTABLISHED.

I also checked the Windows excluded TCP port ranges; port 1455 is not in an excluded range.

<img width="1214" height="516" alt="Image" src="https://github.com/user-attachments/assets/17d72485-8e8b-4cf1-9cd7-706884d681b4" />

Why this looks like a WSL/App OAuth handoff or token-exchange issue

The observations above suggest:

• The browser can reach auth.openai.com.
• consent.data returns HTTP 200.
• The WSL codex process successfully binds 127.0.0.1:1455.
• Windows can reach 127.0.0.1:1455 at the TCP layer.
• An OAuth callback request is created during the normal login flow.
• The error path can return a concrete token_exchange_failed result.
• The successful path hangs indefinitely and Codex Desktop never finishes authentication.

One possible cause is that the WSL-backed Codex callback handler receives the authorization code but cannot complete the subsequent token exchange, for example because the app-spawned WSL backend does not inherit the same proxy/network environment as my interactive WSL shell. I have not confirmed this root cause, but it would also be consistent with the stream disconnected before completion failures that begin after switching the Agent environment from Windows native to WSL and restarting.

External HTTP/HTTPS traffic on the machine uses a local HTTP proxy at:

127.0.0.1:7897

localhost / 127.0.0.1 are configured to bypass the proxy.

Expected behavior

After approving the Codex consent page, the OAuth callback on localhost:1455 should complete the token exchange and authenticate Codex Desktop.

If the callback handler or token exchange cannot complete, Codex Desktop should surface an actionable timeout/network/proxy error instead of leaving both the consent page and the desktop app waiting indefinitely.

Related issue

This appears related to the Windows + WSL localhost OAuth class of issues described in #12263, but that report concerns the VS Code extension.

This case occurs in Codex Desktop for Windows with Agent environment = WSL, and the callback listener is present and reachable. The failure appears to occur later in the successful OAuth path.

Environment

• Codex Desktop: latest Microsoft Store build available on 2026-08-09
• Subscription: ChatGPT Business
• Host: Windows 11 x64
• Working Agent environment: Windows native
• Failing Agent environment: WSL2 Ubuntu
• External HTTP proxy: 127.0.0.1:7897
• OAuth callback listener: 127.0.0.1:1455

I can provide Codex Desktop logs or additional network traces if useful.

What steps can reproduce the bug?

A. Primary WSL sign-in failure

1. Launch Codex Desktop on Windows 11.
2. In Codex settings, set Agent environment to WSL.
3. Restart Codex Desktop.
4. Click Sign in with ChatGPT.
5. Complete the browser authentication flow with a valid ChatGPT Business account.
6. On the Codex consent page, select the Business workspace and continue.
7. Observe that the page stays on a loading spinner indefinitely and Codex Desktop never completes sign-in.
8. While the login is hanging, verify inside WSL that Codex is listening on the OAuth callback port:

``text
ss -ltnp | grep 1455
``

This shows a codex process listening on 127.0.0.1:1455.

1. From Windows, verify that connections to the callback port can be established:

``text
netstat -ano | findstr :1455
``

Connections to 127.0.0.1:1455 reach the ESTABLISHED state.

1. In browser DevTools, verify that the Codex consent data request succeeds with HTTP 200.

B. Supplementary Windows-native-to-WSL transition failure

1. Set Agent environment to Windows native.
2. Sign in with the same ChatGPT Business account and verify that Codex works normally.
3. Change Agent environment from Windows native to WSL.
4. Restart Codex Desktop as prompted.
5. Try to use Codex again.
6. Observe that the previously working session now consistently fails with:

``text
stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)
``

These are two related WSL-specific failure paths: direct WSL sign-in does not complete, and switching a working Windows-native session to WSL also makes Codex unusable after restart.

What is the expected behavior?

After the user approves the Codex consent page, the OAuth flow should successfully return to the local callback listener on localhost:1455, complete the token exchange, and authenticate Codex Desktop.

If the callback or token exchange cannot be completed, Codex Desktop should display a clear and actionable error message instead of leaving the consent page and the desktop app waiting indefinitely.

Additional information

Additional observations:

• The primary problem is that valid ChatGPT sign-in does not complete when Agent environment = WSL.
• Separately, Agent environment = Windows native works normally on the same machine and account.
• Switching that working Windows-native environment to WSL and restarting produces:

``text
stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)
``

• Integrated terminal Shell = PowerShell is a separate setting and is not the Windows/WSL comparison described here.
• ChatGPT web access works normally from the same machine and account.
• auth.openai.com is reachable, and the Codex consent .data request returns HTTP 200.
• External HTTP/HTTPS traffic uses a local HTTP proxy at 127.0.0.1:7897.
• localhost / 127.0.0.1 are configured to bypass the proxy.
• Inside WSL, the codex process is listening on 127.0.0.1:1455.
• Windows can establish TCP connections to 127.0.0.1:1455.
• Port 1455 is not included in the Windows excluded TCP port ranges.
• When the token exchange is rejected, the OAuth flow can complete far enough to return an explicit error:

``text
token_exchange_failed
Token exchange failed: token endpoint returned status 403 Forbidden
``

However, with the normal valid authentication path in the WSL-backed environment, the consent page remains stuck on a loading spinner and Codex Desktop never completes sign-in.

This may be related to the Windows + WSL localhost OAuth callback issue discussed in #12263, although that report concerns the VS Code extension. In this case, the issue occurs in Codex Desktop, and the callback listener is present and reachable.

I can provide Codex Desktop logs or additional network traces if needed.