[FEATURE] Browser pane: no way to bypass certificate errors for local development hosts (self-signed certs)

[JuliCorso]

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

The embedded Browser pane refuses to load any site whose TLS certificate is not trusted, failing with net::ERR_CERT_AUTHORITY_INVALID. Unlike regular Chrome, there is no "Advanced -> Proceed anyway" interstitial and no per-host exception setting.

This blocks Claude from driving local apps served over HTTPS with self-signed certificates — the out-of-the-box reality for common dev app servers (Payara/GlassFish, Tomcat, WildFly, etc.).

This was previously reported in #48757 (the embedded browser rejected even locally-trusted mkcert certificates), which was auto-closed for inactivity and locked. The bot suggested filing a new issue if still relevant — it is.

In my case there is no workaround at all: I don't have admin rights on this machine, so I can't add the certificate (or a mkcert CA) to the OS trust store. And per #48757, even a system-trusted certificate was rejected, suggesting the embedded browser doesn't inherit the system trust store anyway.

Proposed Solution

A way to accept untrusted certificates for specific hosts in the Browser pane. Any of these would solve it:

1. A per-origin "proceed anyway" prompt, similar to Chrome's certificate interstitial, shown once and remembered for the session (or persisted per project).
2. A setting such as browser.ignoreCertErrorsForHosts: ["mydevhost.example:8181"], ideally restricted to hosts resolving to private/loopback addresses to keep it safe.
3. Inheriting the system certificate trust store, which would at least resolve the mkcert case from [BUG] preview_start embedded browser rejects locally-trusted mkcert certificates #48757.

Alternative Solutions

• Trusting the certificate in the OS keychain (or installing a mkcert CA): requires admin rights, which I don't have on this machine.
• Replacing the server certificate with a properly-named self-signed one (correct CN/SAN): still untrusted, still rejected.
• Testing over plain HTTP instead: not possible — the app's login flow requires the HTTPS port (an OAuth callback redirects to https://...:8181/auth/a).
• Current workaround: abandoning the Browser pane entirely and driving my regular Chrome instead, which loses the isolated-browser workflow.

Priority

High - Significant impact on productivity

Feature Category

Other

Use Case Example

Example scenario:

1. I'm developing a Jakarta EE app on a local Payara Server. HTTPS runs on port 8181 with the server's default self-signed certificate.
2. I ask Claude Code to test the login flow in the Browser pane.
3. The app's OAuth callback redirects to https://mydevhost.example:8181/auth/a — the navigation fails with net::ERR_CERT_AUTHORITY_INVALID and there is no way to proceed.
4. Claude cannot reach any page of the app over HTTPS, so it cannot test or verify anything in the Browser pane.
5. With this feature, I could approve the certificate once for that host and Claude could drive the whole app normally.

Additional Context

• Previous report of the same limitation: [BUG] preview_start embedded browser rejects locally-trusted mkcert certificates #48757 ("preview_start embedded browser rejects locally-trusted mkcert certificates"), auto-closed for inactivity and locked — filing this new issue as suggested by the bot.
• Regular Chrome handles this with its certificate interstitial ("Advanced -> Proceed to site"), remembered per origin. Playwright/Puppeteer expose ignoreHTTPSErrors; Electron exposes app.commandLine.appendSwitch('ignore-certificate-errors')-style opt-ins. A scoped, per-host equivalent in the Browser pane would be enough.
• Security consideration: restricting the bypass to hosts that resolve to loopback/private addresses (RFC 1918) would keep the risk minimal while covering virtually all local development cases.