Browser pane cannot complete HTTP Basic Auth challenge (401 loop, no credential prompt)

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code

### What's Wrong?

The embedded "Browser pane" in the Claude desktop app (the Chromium instance driven via the Claude_Browser__* tools / in-app browser panel) cannot complete an HTTP Basic Authentication challenge. When navigating to a URL whose server requires HTTP Basic Auth, the browser pane receives repeated 401 Unauthorized responses and never displays Chromium's native Basic Auth "Sign in" credential dialog — neither when navigation is driven by Claude's tool calls, nor when the end user interacts with the pane directly (clicking, refreshing). The page is left permanently blank with no way to authenticate.

This differs from the same machine's regular Chrome browser hitting the same URL, which correctly prompts for and accepts Basic Auth credentials.

### What Should Happen?

When a page under automation (via CDP or whatever mechanism drives the Browser pane) receives a 401 with a WWW-Authenticate: Basic challenge, Chromium should either:

Surface its native Basic Auth credential prompt to the human user for them to fill in directly (ideal — Claude itself should never see/handle the credentials), or
At minimum, not silently swallow the challenge and leave the page blank with no indication of what is blocking it.

### Error Messages/Logs

```shell
Failed to load resource: the server responded with a status of 401 (Unauthorized)
net::ERR_ABORTED (for some protected sub-resources)

Also observed: an internal client-side "automatic web logout" retry loop on the target page repeatedly re-attempting and re-failing the same protected calls.
```

### Steps to Reproduce

On a network reachable from the linked device, have a web server/device that protects part or all of its content with HTTP Basic Authentication (in this case, a network switch's embedded web-management UI at http://192.168.5.1/).
In a Claude session linked to that device, use Claude_Browser__navigate (or preview_start) to open http://192.168.5.1/.
Grant the "high-risk site" access prompt when asked (Claude_Browser__request_access).
Observe the page: it renders completely blank.
Call Claude_Browser__read_console_messages — shows repeated entries like:
Failed to load resource: the server responded with a status of 401 (Unauthorized)

for the root document and for protected sub-resources (in this case lib/config.js, stat/sys, config/secure_web_config, config/filter.css), while unprotected static assets on the same origin (.css, .js libs, some .htm shells) return 200/304 normally. 6. Call Claude_Browser__read_page / get_page_text — both return an empty page/body, confirming no content (including no login form) was ever rendered. 7. Ask the end user to bring the Browser pane to the foreground themselves (not via Claude's tools) and manually click into the tab / press refresh. No native "Sign in" dialog appears for the user either — the page remains blank. 8. For comparison, open the same URL in the same machine's regular, non-Claude Chrome browser: Chrome immediately shows its native HTTP Basic Auth credential prompt, which the user can fill in normally, after which the page loads correctly.

### Claude Model

None

### Is this a regression?

Unknown — not tested against a prior version. First observed on 1.49585.0; no earlier version was checked.

### Last Working Version

N/A — not a confirmed regression.

### Claude Code Version

N/A — this is a Claude desktop app / Browser pane bug, not the `claude` CLI. Desktop app version: 1.49585.0 (Electron 44.2.0, Node 24.20.0).

### Platform

Other

### Operating System

Windows

### Terminal/Shell

N/A — GUI desktop app bug (Browser pane), not a terminal or CI context.

### Additional Information

Additional Information
Impact: Any site or embedded device (this case: a managed network switch's web GUI — a common pattern for enterprise/industrial hardware) that uses HTTP Basic Auth for its management interface is completely inaccessible through the Browser pane, even for legitimate, user-approved, read/write administrative tasks the user has explicitly asked Claude to help with. The only workaround today is falling back to a separate, non-Claude Chrome window (losing Claude's click/type automation, read-only screen viewing only) or a non-browser interface (e.g., SSH/CLI) where one exists.
Suggested fix: Implement handling for the CDP Fetch.authRequired event (or equivalent) so a Basic Auth challenge triggers a real, user-facing native credential prompt inside the Browser pane — consistent with the user's regular Chrome — instead of the request being silently failed. Given Claude's policy against ever handling credentials itself, this prompt should be presented purely to the human user, with Claude never given programmatic access to what is typed.
This was diagnosed during a live support session where Claude was directly troubleshooting a network switch (SW2R-GC24XU4WST, Microchip iStaX-based) at the user's explicit request, with the user available throughout to test interactively. The user confirmed their regular Chrome authenticates against this same switch normally.
Device name referenced in logs: win-g44sf99g95g. Date observed: 2026-09-10.

Start by reproducing the 401 challenge through the Browser pane using Claude_Browser__navigate or preview_start, then inspect the CDP Fetch.authRequired path described in the issue. Verify that a user-facing credential prompt appears, the protected page loads after authentication, and credentials are not exposed to Claude.

Vom Indexierungsmodell aus dem Issue-Text verfasst.