[Windows][In-app browser] HTTP Basic authentication still fails with ERR_INVALID_AUTH_CREDENTIALS on MSIX 26.908.9136.0

What version of the Codex App are you using?

Windows MSIX package: OpenAI.Codex 26.908.9136.0 (verified from the installed package). Packaged owl-app.ini reports AppVersion=26.908.70816. These are package/runtime metadata, not a reading of the About dialog.

What subscription do you have?

Not provided.

What platform is your computer?

Windows, x64.

What issue are you seeing?

The Codex in-app browser cannot complete an HTTP Basic authentication challenge. A protected site is replaced by the browser error page with:

ERR_INVALID_AUTH_CREDENTIALS

There is no usable, persistent credentials-entry flow before the error. The user confirmed that the same protected site can be signed into in a regular browser. The duration or presence of a briefly flashing native dialog was not measured in this reproduction.

Unauthenticated requests to the site, both directly and through the configured HTTP proxy, receive a normal HTTP 401 response with WWW-Authenticate: Basic. The protected site is reachable. No real credentials were guessed or submitted by the diagnostic tools.

What steps can reproduce the bug?

1. On Codex Desktop for Windows, open an HTTP site that responds to an unauthenticated request with 401 Unauthorized and a WWW-Authenticate: Basic realm="test" challenge.
2. Observe that the in-app browser does not provide a usable authentication flow and displays ERR_INVALID_AUTH_CREDENTIALS.
3. For an isolated comparison, run a temporary HTTP server bound only to 127.0.0.1, with a public endpoint returning 200 and a protected endpoint returning the Basic challenge until supplied with synthetic test credentials.
4. Open the public endpoint through Codex Browser Use: it loads successfully.
5. Navigate to the protected endpoint through Browser Use: the server receives the request and responds with 401, but navigation reports net::ERR_BLOCKED_BY_CLIENT. The desktop log records a locally generated error page containing ERR_INVALID_AUTH_CREDENTIALS; Browser Use subsequently remains on the public endpoint.

The loopback test reproduced the authentication failure without depending on the original private service. It was initiated through Browser Use; it is not a measurement of manual native-dialog timing. The temporary test server and tab were cleaned up.

What is the expected behavior?

The browser should keep a Basic authentication prompt available until the user submits credentials or cancels. Valid credentials should allow the original page to load, with defined cancellation and rejected-credential behavior.

Additional information

Related existing reports: #40091 and #43032, including the loopback Basic-auth reproduction in #43032. This may be the same underlying defect; this report records an independent reproduction on the newer Windows MSIX package 26.908.9136.0.

The specific internal cause (for example, early cancellation versus error-page navigation while authentication is pending) was not established. Please consolidate this report with an existing issue if appropriate.

Private site addresses, account credentials, screenshots, raw logs and session transcripts are intentionally omitted. No job or application data was modified during diagnosis.

Start by tracing the Codex Browser Use path that handles a 401 response with a WWW-Authenticate: Basic challenge, then compare the behavior and findings in related issues #40091 and #43032. Done means a Windows in-app browser keeps a usable prompt until credentials are submitted or cancelled, loads the protected page with valid credentials, and handles cancellation or rejected credentials predictably.