[Windows][Desktop browser] Native HTTP authentication dialog closes immediately

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

26.901.41600 (Windows MSIX package 26.901.5280.0)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

When the built-in browser reaches an OIDC identity provider that requests native HTTP authentication, the native Sign in dialog appears with username and password fields but closes approximately 100-150 ms later, before the user can type anything.

The browser then replaces the identity-provider page with its local error page:

This site can't be reached
ERR_INVALID_AUTH_CREDENTIALS

No credentials were entered before the error. The same protected URL and authentication flow work in regular Chrome and Edge on the same Windows computer.

The affected identity-provider hostname, full OIDC URL, state, nonce, and corporate application details are intentionally redacted. The authentication scheme advertised by the server has not been established, so this report does not assume Basic, NTLM, or Negotiate.

What steps can reproduce the bug?

1. On Codex Desktop for Windows, open the built-in browser.
2. Navigate to an OIDC-protected web application whose identity provider triggers Chromium's native username/password authentication dialog.
3. Wait for the redirect to the identity provider.
4. Observe that the native Sign in dialog appears briefly.
5. Before either field can be used, the dialog closes and the tab displays ERR_INVALID_AUTH_CREDENTIALS.
6. Click Reload and observe the same behavior.

The local desktop log recorded three consecutive attempts:

Attempt 1: identity-provider page ready -> local error page after 123 ms
Attempt 2: identity-provider page ready -> local error page after 146 ms
Attempt 3: identity-provider page ready -> local error page after 115 ms

The local error page is a data:text/html navigation generated by Codex Desktop, rather than content returned by the identity provider.

What is the expected behavior?

The native HTTP authentication dialog should remain open until the user submits credentials or explicitly cancels it. A pending authentication challenge should not be replaced by the built-in browser's local error page.

After valid credentials are submitted, the OIDC flow should continue. If credentials are rejected or the dialog is cancelled, the browser may then show an appropriate error or allow another attempt.

Additional information

Local inspection of the packaged desktop application suggests a race between the native authentication prompt and main-frame load-failure handling:

• the main-frame did-fail-load handler handles ERR_INVALID_AUTH_CREDENTIALS;
• it calls the browser error-page loader;
• the loader navigates to a local data: URL with replaceCurrentEntry: true;
• that navigation destroys the still-pending native authentication dialog.

A possible fix is to defer main-frame error-page navigation while an HTTP authentication challenge is pending, or specifically avoid handling ERR_INVALID_AUTH_CREDENTIALS as final until the authentication callback has completed.

Suggested regression checks:

1. A native HTTP authentication challenge keeps the dialog open while user input is pending.
2. Submitting valid credentials continues the original navigation.
3. Cancelling the dialog follows a defined error path without a race.
4. Rejected credentials permit the expected retry behavior.

The raw video and full desktop log contain private corporate URLs and transient OIDC parameters, so they should not be attached without redaction. A sanitized screenshot or focused log excerpt can be provided if needed.

Start with the main-frame did-fail-load handler and the browser error-page loader described in the report, focusing on ERR_INVALID_AUTH_CREDENTIALS and the pending HTTP authentication callback. Trace when the local data: URL navigation replaces the page, then exercise the native challenge with valid, rejected, and cancelled credentials. Done means the dialog remains available, successful authentication continues navigation, and failure or cancellation follows a defined retry or error path.