[Codex Desktop] In-app browser forces HTTPS for HTTP-only local virtual hostnames

What version of the Codex app are you using?

The exact Desktop build number is not available to the workspace-side agent. The issue was reproduced in Codex Desktop on September 14, 2026.

What platform are you using?

Codex Desktop with the built-in in-app browser.

What issue are you seeing?

The Codex in-app browser changes an explicitly entered http:// URL to https:// for a local development virtual hostname.

The development hostname intentionally provides HTTP only. It has no TLS certificate and no HTTPS service. Direct HTTP requests reach the local development gateway, but the in-app browser replaces the scheme with HTTPS and the application becomes unreachable.

The application is not issuing an HTTPS redirect:

• A direct HTTP request reaches the expected service.
• The HTTP response has no Location header that points to HTTPS.
• The HTTP response has no Strict-Transport-Security header.
• An authentication redirect explicitly returns an http:// URL, but the in-app browser changes that navigation to HTTPS as well.

Codex currently exposes no visible per-host setting that allows this HTTP-only development hostname to remain on HTTP.

Steps to reproduce

1. Map a synthetic local development hostname such as dev.example.test to a development gateway.
2. Serve the application on http://dev.example.test only. Do not configure TLS, an HTTPS listener, or an HTTPS certificate.
3. In the Codex in-app browser, enter http://dev.example.test/path.
4. Observe that the browser changes the URL to https://dev.example.test/path.
5. Observe that the working HTTP application cannot be reached because the virtual hostname has no HTTPS service or certificate.

The same behavior occurs when an HTTP response redirects to another explicit http://dev.example.test/... URL.

Isolation results

The behavior was checked against each relevant layer:

• A direct HTTP request reaches the expected service with status 401; there is no HTTP Location header and no HSTS response header.
• A completely new standalone Chromium 153 profile reproduces the upgrade, so ordinary browser cache and previously stored site data are not required.
• Chromium's HSTS query reports Not found for the tested hostname.
• The browser-generated redirect has status 307 and Non-Authoritative-Reason: HttpsUpgrades.
• In the isolated Chromium profile, generated.https_first_mode_enabled starts at 3 (Enhanced). Setting it to 0 (Standard) allows the failed HTTPS attempt to fall back to HTTP; the final URL remains HTTP and the expected 401 application page loads.

This proves that clearing ordinary cache does not address the cause. In the standalone Chromium UI, opening chrome://settings/security, keeping the Standard security bundle selected, and clicking Reset to defaults changes generated.https_first_mode_enabled from 3 to 0; HTTP fallback then works. However, chrome://settings/security is not accessible in the Codex in-app browser, so this standalone Chromium workaround cannot be applied there. Codex's workspace configuration schema also exposes no HttpAllowlist, HttpsUpgradesEnabled, or HttpsOnlyMode field. The remaining inference is that Codex's in-app browser uses the same HTTPS-first setting or an equivalent client-side policy; the workspace-side agent cannot inspect or change that private desktop-client profile directly.

Expected behavior

Codex should preserve an explicitly entered HTTP scheme for an HTTP-only local development hostname, or provide a per-host control that allows HTTP for that hostname. Chromium already defines the relevant controls: HttpAllowlist for a narrow hostname exception, and HttpsUpgradesEnabled=false together with HttpsOnlyMode=disallowed for a global disable. Codex should expose an equivalent app setting, preferably the per-host exception.

Actual behavior

Codex forces the navigation to HTTPS, so the HTTP-only local development environment cannot be opened in the in-app browser.

Privacy note

The hostname above is synthetic. No customer, company, employee, repository, or private network identifiers are included in this report.

No source file or test is named; start at the Codex Desktop in-app browser navigation path and investigate the HTTPS-first behavior identified by Chromium's generated.https_first_mode_enabled setting. Done means an explicitly entered HTTP URL remains HTTP, or a per-host control allows the synthetic local hostname to bypass HTTPS upgrades.