›_ Codex Issues
Codex Issues / #38369

Windows Browser Use blocks raw JSON and CSV with ERR_BLOCKED_BY_CLIENT while HTML works

Open 💬 0 comments Opened Aug 13, 2026 by evdmolen

What version of the Codex App are you using (From “About Codex” dialog)?

26.803.81509

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Browser Use in the Codex Windows desktop app blocks raw JSON and CSV responses with ERR_BLOCKED_BY_CLIENT, while ordinary HTML pages remain accessible.

This has broken a scheduled automation that previously worked correctly. The automation retrieved two machine-readable HTTPS sources twice daily, compared the data with previous runs and generated a statistical report. It worked for several days and then suddenly stopped retrieving the unchanged endpoints.

I created neutral test endpoints to isolate the cause. The results were:

  • HTML on the same domain: accessible
  • Harmless fabricated JSON: ERR_BLOCKED_BY_CLIENT
  • Harmless fabricated CSV: ERR_BLOCKED_BY_CLIENT
  • JSON served with Content-Type: text/plain: ERR_BLOCKED_BY_CLIENT
  • CSV served with Content-Type: text/plain: ERR_BLOCKED_BY_CLIENT
  • Fresh directories with neutral names and new index.php files: ERR_BLOCKED_BY_CLIENT

All endpoints work normally when opened manually in a regular browser.

I also tested two independent public JSON endpoints:

https://jsonplaceholder.typicode.com/todos/1

https://api.github.com/repos/openai/openai-python

Browser Use also blocked both public endpoints with ERR_BLOCKED_BY_CLIENT.

This demonstrates that the failure is not specific to my domain, PHP implementation, filenames, directory names, MIME types or data contents. Browser Use appears to reject raw structured or non-HTML responses more generally.

The same resources previously worked in the scheduled automation. No relevant server-side or automation changes were made before the blocking began. This therefore appears to be a Browser Use policy problem or a regression in the Windows desktop app or scheduled-task runtime.

What steps can reproduce the bug?

  1. Open the Codex Windows desktop app.
  1. Start a Codex conversation with Browser Use available.
  1. Ask Codex to open and read this public JSON endpoint:

https://jsonplaceholder.typicode.com/todos/1

  1. Observe that Browser Use fails with:

ERR_BLOCKED_BY_CLIENT

  1. Repeat the test with this independent public JSON endpoint:

https://api.github.com/repos/openai/openai-python

  1. Observe that Browser Use again returns:

ERR_BLOCKED_BY_CLIENT

  1. Ask Browser Use to open an ordinary HTML page, such as:

https://example.com/

  1. Observe that the HTML page opens successfully.
  1. Optionally create simple public HTTPS endpoints containing harmless fabricated data and serve them using the following content types:
  • application/json
  • text/csv
  • text/plain
  1. Attempt to open these endpoints through Browser Use.
  1. Observe that the JSON, CSV and plain-text data endpoints are blocked with ERR_BLOCKED_BY_CLIENT, while an HTML endpoint on the same server remains accessible.
  1. Configure a scheduled automation to retrieve one of the public JSON endpoints and process its contents.
  1. Observe that the scheduled run is also unable to retrieve the machine-readable response.

The public JSON endpoints can be opened normally in a regular web browser, so the failure occurs specifically through Codex Browser Use.

What is the expected behavior?

Browser Use and scheduled automations should be able to retrieve and read valid JSON, CSV and plain-text responses from ordinary public HTTPS endpoints, just as they can retrieve HTML pages.

For example, Browser Use should successfully open and process:

https://jsonplaceholder.typicode.com/todos/1

https://api.github.com/repos/openai/openai-python

The response format or MIME type should not cause a harmless public resource to be rejected.

If access to a resource is intentionally restricted, Codex should display a clear and actionable explanation identifying the applicable policy and any supported remediation. It should not return the generic ERR_BLOCKED_BY_CLIENT error.

Existing scheduled automations should also continue accessing unchanged HTTPS resources unless a documented restriction applies.

Additional information

I submitted an in-app bug report containing the relevant ChatGPT session logs and the exact private test endpoints.

Feedback ID:

no-active-thread-019ffb12-9f9b-7a52-bcc0-41feaf05d223

The private production and test URLs are intentionally omitted from this public GitHub issue because the production endpoints contain personal affiliate statistics. I can provide the exact URLs privately to an OpenAI team member if required.

Before this problem occurred, the same endpoints were successfully retrieved by a scheduled Codex automation for several days. The automation ran twice daily and produced multiple valid statistical reports. The endpoints remained valid and can still be opened manually in a regular browser.

Related reports involving Browser Use, Windows app or network-policy regressions:

A similar report involving the exact Chromium error in Microsoft Playwright MCP:

These reports may not have the same underlying cause, but they demonstrate similar browser, security-policy and scheduled-runtime failures.

The tests performed so far rule out:

  • The original data provider
  • My hosting provider
  • The PHP implementation
  • The domain itself
  • Directory and filename choices
  • JSON and CSV contents
  • Content-Type headers
  • Download or attachment headers

The same failure with independent public APIs strongly suggests that the blocking occurs within Browser Use or an associated server-side policy.

A related but technically different ERR_BLOCKED_BY_CLIENT report is #30687. That issue concerns HTML without a Content-Type header and is resolved by adding text/html. This report concerns correctly labelled JSON, CSV and text/plain responses, including independent public APIs.

View original on GitHub ↗