›_ Codex Issues
Codex Issues / #30687

Chrome Use blocks local SPA fallback page with ERR_BLOCKED_BY_CLIENT when HTML response has no Content-Type

Open 💬 1 comment Opened Jun 30, 2026 by q43607238

Summary

When using Codex App Chrome Use to open a locally hosted SPA page through a custom hostname mapped to 127.0.0.1, the page can be blocked with:

ERR_BLOCKED_BY_CLIENT

The same URL loads normally in regular Chrome and through Chrome DevTools/CDP-style control. The issue disappears after the local dev server adds this header to the SPA HTML fallback response:

Content-Type: text/html; charset=utf-8

This looks like Chrome Use or Codex App is applying a client-side protection/classification rule that treats an extensionless HTML fallback response without Content-Type as a blocked client resource or download.

Environment

  • Codex App with Chrome Use
  • macOS
  • Chrome
  • Local development server on 127.0.0.1
  • Custom hosts entry, for example:
127.0.0.1 dev.example.test

Reproduction

  1. Add a custom local hostname:
127.0.0.1 dev.example.test
  1. Start a local HTTP server on port 8000.
  1. Serve a SPA fallback route such as:
http://dev.example.test:8000/app/home
  1. Return HTML with 200 OK, but without a Content-Type header:
HTTP/1.1 200 OK
Transfer-Encoding: chunked

<!DOCTYPE html>
<html>
  ...
</html>
  1. Open the URL through Codex App Chrome Use:
http://dev.example.test:8000/app/home

Actual result

Chrome Use shows a browser-level failure:

ERR_BLOCKED_BY_CLIENT

The page does not render.

Expected result

Chrome Use should load the page the same way normal Chrome does, or report a more specific diagnostic explaining why the response was blocked.

Important observation

If the exact same HTML fallback response is changed to include:

Content-Type: text/html; charset=utf-8

then Chrome Use loads the page successfully.

So the minimal difference appears to be:

 HTTP/1.1 200 OK
+Content-Type: text/html; charset=utf-8
 Transfer-Encoding: chunked

 <!DOCTYPE html>

Why this matters

Many local SPA dev servers serve extensionless fallback routes such as /app/home, /dashboard, or /product/foo. If the dev server forgets or fails to set Content-Type on fallback HTML, normal Chrome may still render the page, but Codex Chrome Use blocks it as ERR_BLOCKED_BY_CLIENT.

This creates a confusing debugging path because the error looks like an enterprise policy block, extension/DNR rule, ad-blocker-style client block, or domain restriction, while the root cause appears to be response classification caused by the missing Content-Type.

Suggested improvement

Codex App / Chrome Use could improve this in one or more ways:

  1. Avoid blocking top-level navigations that return 200 OK and start with <!DOCTYPE html> or <html>, even when Content-Type is missing.
  2. Surface a clearer diagnostic, for example: Navigation blocked because the response has no Content-Type and was classified as unsafe or unsupported.
  3. Align behavior with normal Chrome top-level navigation behavior for local development URLs.
  4. Document this requirement for local dev servers using Chrome Use.

Workaround

Ensure the local dev server sets this header for SPA HTML fallback routes:

Content-Type: text/html; charset=utf-8

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗