Codex Desktop in-app browser has no bypass for ERR_CERT_AUTHORITY_INVALID on HTTPS localhost

Open 💬 6 comments Opened May 21, 2026 by sbrin

What issue are you seeing?

Codex Desktop's in-app browser blocks HTTPS localhost development servers that use a self-signed or otherwise locally untrusted certificate with ERR_CERT_AUTHORITY_INVALID, but the browser UI does not provide a way to accept the risk and continue.

In a normal Chrome/Chromium browser, this flow exposes an "Advanced" / "Proceed" bypass for a local development origin. In Codex's in-app browser, there is no equivalent button, so HTTPS-only local apps cannot be inspected or driven from Codex even though the same URL is usable in a regular browser after accepting the warning.

This is especially painful for local apps that intentionally require HTTPS during development, for example because they depend on secure cookies, OAuth callbacks, secure-context APIs, service workers, WebRTC, or production-like TLS behavior. For these cases, switching to HTTP is not a valid workaround, and requiring every project/user to install a local CA such as mkcert is not always acceptable.

Steps to reproduce

  1. Start a local development server that only serves HTTPS on localhost, using a self-signed or locally untrusted certificate.
  2. Open the URL in Codex Desktop's in-app browser, for example https://localhost:3000.
  3. Observe ERR_CERT_AUTHORITY_INVALID.
  4. Look for the usual browser escape hatch to proceed anyway.

Expected behavior

Codex Desktop should provide a local-development certificate bypass for the in-app browser, for example one of:

  • an "Advanced" / "Proceed to localhost (unsafe)" button on the certificate error page;
  • a per-origin trust override scoped to the current Codex browser profile;
  • a Codex setting / launch option equivalent to Chromium's --allow-insecure-localhost or --ignore-certificate-errors, ideally scoped to localhost/private origins rather than globally;
  • a prompt that lets the user explicitly allow this specific localhost origin for the current session.

Actual behavior

The in-app browser stops at ERR_CERT_AUTHORITY_INVALID and does not expose a visible way to proceed. As a result, Codex cannot use the built-in browser for HTTPS-only localhost apps.

Platform

  • Codex Desktop app / in-app browser
  • macOS 15.7.3, arm64
  • Local URL: HTTPS localhost

I could not get a reliable Codex CLI version locally because codex --version fails in this environment with an ENOENT for the bundled vendor binary, but this report is about the Desktop in-app browser UI rather than the CLI.

Additional context

This is a feature request / bug for developer ergonomics. The requested behavior should be explicitly user-driven and scoped, not silently disabling TLS validation for arbitrary public websites.

View original on GitHub ↗

6 Comments

sbrin · 2 months ago

Update: the exact Codex Desktop version from the macOS app About dialog / bundle metadata is:

  • Version 26.513.31313 (2867)
  • Bundle id: com.openai.codex
  • Platform: macOS 15.7.3 arm64

This is the version where the in-app browser shows ERR_CERT_AUTHORITY_INVALID for HTTPS localhost but does not expose a visible "Proceed anyway" / certificate bypass control.

swqsldz · 1 month ago

not only macos, windows version same issue, in-app browser refuse to load my https devserver,

Rowdster · 1 month ago

Same on windows.

sbrin · 1 month ago

Found a workaround:

On MacOS you can launch codex from terminal

open -a Codex --args --allow-insecure-localhost
Rowdster · 1 month ago

I just went through the whole process of trusting the cert locally and that fixed it.

theophanemayaud · 1 month ago

I’m hitting this too in the Codex in-app browser when testing a local HTTPS dev server on https://localhost:xxxx.

There is also a related issue with the Chrome control plugin: Chrome does show the Advanced button and the local bypass flow, but the agent guidance says it must never click through an HTTPS/privacy interstitial, even after the user has been warned and explicitly confirms that they want the agent to proceed.

That feels misaligned for local development. For localhost / 127.0.0.1 dev servers, after a clear warning and explicit user consent (or not even, as its local host), the agent should be allowed to continue. The current alternative is asking the user to trust the generated cert in the OS keychain, which can actually be broader and more persistent than a one-off browser-level bypass for a local dev session. Please let me use my agent how I want, and do not include misaligned instructions in the skill to basically "not respect user decisions". Especially because the alternative it comes up with anyway, is to add the certificate to my keychain, which is much worse security wise: if you force the agent to do dumb things instead of logical, cautious things, it will do them.

Specially the misaligned guidance in the chrome control plugin is Do not bypass paywalls or browser/web safety interstitials I think.