[Sites] Public deployment returns Cloudflare 403 on both default and active custom domains

What version of the Codex App are you using?

Codex Desktop 26.715.72359 (build 5718)

Sites plugin: openai-bundled/sites 0.1.30

What subscription do you have?

Paid ChatGPT plan with Sites access (exact tier not confirmed in this report)

What platform is your computer?

• macOS 26.3 (build 25D125), Apple Silicon (arm64)
• Safari 26.3 (build 21623.2.7.11.6)

What issue are you seeing?

A successfully published public ChatGPT Site returns a Cloudflare WAF block page (HTTP 403, “Why have I been blocked?”) for both:

• the generated Sites hostname: https://neplach-tech.mrziiz.chatgpt.site
• an attached custom hostname: https://tech.neplach.com

The Sites API reports:

• site status: active
• access mode: public
• custom domain status: active
• provider status: active
• SSL status: active

The custom hostname DNS records resolve correctly and are DNS-only:

• tech.neplach.com CNAME custom-domains.chatgpt.site.
• both Sites validation TXT records resolve correctly

Despite this, normal browser and curl requests are blocked at the Cloudflare edge before the application is reached.

Steps to reproduce

1. Create a one-page Site using the bundled Sites plugin.
2. Save and deploy the version successfully.
3. Change access to public and publish the version publicly.
4. Open the generated *.chatgpt.site URL in Safari.
5. Observe a Cloudflare 403 WAF block page.
6. Attach a custom domain with the exact CNAME and TXT records returned by Sites.
7. Wait until Sites reports domain, provider, and SSL statuses as active.
8. Open the custom domain in Safari.
9. Observe the same Cloudflare 403 block page.

Expected behavior

A Site with access_mode=public, a successful production deployment, and an active custom domain/SSL certificate should return the published website to normal browser requests without requiring ChatGPT authentication.

Actual behavior and evidence

All requests return HTTP/2 403, server: cloudflare, and the generic WAF block page.

Ray IDs:

• User Safari screenshot: a1fb74191a8e8d9f
• Safari-UA probe, generated Sites hostname: a1fb980089e1f468-HEL
• Safari-UA probe, active custom domain: a1fb98013c44dfd7-HEL

The second reproduction came from a separate Codex execution network (Cloudflare trace: DE, Datacamp Limited AS60068), so this is not isolated to the user’s home ISP or one browser session.

Additional information

This may be adjacent to #18456, but it is materially different: the blocked requests here are ordinary browser-style GET requests to successfully deployed public Sites hostnames, not internal reqwest/* clients.

Impact: the public Sites deployment is unusable for visitors even though all deployment, access, DNS, custom-domain, and SSL states report success.

Please inspect the WAF/security event associated with the Ray IDs above and verify whether the public Sites/custom-domain hostnames are being evaluated by an unintended managed rule or IP/ASN policy.