Codex Chrome Extension connected but page content access is blocked by enterprise network policy
What version of the Codex App are you using (From “About Codex” dialog)?
Codex 26.602.71036, released 2026-06-09
What subscription do you have?
ChatGPT Plus
What platform is your computer?
Windows
What issue are you seeing?
Codex Chrome Extension shows Connected and can read the current Chrome tab title and URL, but it cannot read page content.
This happens even on https://example.com/.
What works:
Codex Chrome Extension shows Connected.
Codex can see the active Chrome tab.
Codex can read the active tab title: Example Domain
Codex can read the active tab URL: https://example.com/
What fails:
Reading visible page text / innerText fails.
Error message, with local file paths removed:
Browser Use rejected this action due to browser security policy.
Reason: Browser Use cannot access https://example.com because enterprise network policy blocks it.
I did not include the full stack trace because it contains local Windows user paths.
What steps can reproduce the bug?
Open Codex desktop app on Windows.
Enable / connect Codex Chrome Extension.
Open Google Chrome.
Manually open https://example.com/.
Confirm that Codex can read the active tab title and URL.
Ask Codex to read the visible page text / innerText from the current tab.
Page content reading fails with:
Browser Use cannot access https://example.com because enterprise network policy blocks it.
Troubleshooting already tried:
Reinstalled the Codex Chrome Extension from Codex settings.
Restarted Chrome.
Restarted Codex.
Checked Chrome Computer Use settings.
Blocked domains list is empty.
Adding allowed domains did not fix the issue.
Tested without navigation/goto/open: manually opened https://example.com/ first, then asked Codex only to read the current tab.
Feedback ID:
019eabba-35ca-7730-a470-18f43d6184ac
What is the expected behavior?
Since the Chrome Extension is connected and https://example.com/ is a basic public web page, Codex should be able to read the visible page text after permission is granted.
Additional information
The issue does not appear to be a connection problem. The Chrome Extension is connected successfully and can read the tab title and URL. The failure only happens when trying to access page content.
7 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I reviewed the potential duplicate #26298 and the related #24814.
This issue may be related, but my case has one important difference: in my setup, the Codex Chrome Extension backend is connected and can read the active Chrome tab title and URL. The failure only happens when trying to read visible page content / innerText.
This is on a newer Codex version:
So I am leaving this issue open for now in case the newer version / Chrome Extension-specific behavior is useful for debugging. If maintainers prefer to track this under an existing issue, please feel free to mark it as duplicate.
I'm seeing the same behavior on Windows with Codex
26.609.4994.0.Setup:
OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0Enable full CDP Accessis currently offhttps://example.comis explicitly allowlistedMy browser config currently includes:
What works:
What fails:
As soon as Codex tries to navigate to or read page content from
https://example.com, it fails with:I fully restarted Codex and Chrome after changing the browser config, then tested again. The origin stayed allowlisted, but content access still failed with the same enterprise network policy message.
This used to work for me before a recent Codex update. From my side, this does not look like a normal website permission issue, since tab metadata is visible and the origin is explicitly allowed. It looks like the browser policy/content-access layer is rejecting the page after tab discovery succeeds.
Thanks for confirming. This matches my case.
In my setup, the Chrome Extension can also list / see the active tab, read the tab title and URL, but page content access still fails with the same error:
I also tried reinstalling the Chrome Extension, restarting Chrome/Codex, and checking the allowed/blocked domain settings. The issue still happens on
https://example.com/.So it looks like the Chrome Extension connection and tab discovery work, but the page-content access layer is still blocked by the browser security policy.
我也是相同问题
I’m seeing what looks like the same issue.
Setup:
26.609.71450What fails:
When Codex tries to read visible page content / innerText from the current tab, it is rejected with:
In my case, the target is an internal/private web app URL that I can open manually in my local Chrome browser. I also tried different Browser Use surfaces, including the in-app browser and the Chrome Extension, and they appear to be blocked by the same policy.
This does not look like a normal website login or permission issue, because the page is accessible from my local Chrome session and the extension connection/tab discovery works. The failure seems to happen specifically at the page-content access layer.
Adding this report because it seems consistent with the behavior described here: Chrome Extension connection works, but page content access is blocked by enterprise network policy.
I hit the same failure mode on Windows Codex Desktop.
Environment:
Symptom:
Browser Use failed for every site with:
"Browser Use cannot access https://... because enterprise network policy blocks it."
Findings:
configRequirements/readreturnedrequirements: null, so this was not a real managed enterprise policy.CODEX_CLI_PATHin both the process/user environment and%USERPROFILE%\.codex\config.tomlpointed to a missing path:...\vendor\x86_64-pc-windows-msvc\codex\codex.exe...\vendor\x86_64-pc-windows-msvc\bin\codex.exeFix:
%USERPROFILE%\.codex\config.toml[mcp_servers.node_repl.env].CODEX_CLI_PATHCODEX_CLI_PATHenvironment variableResult:
Browser Use recovered. It could navigate to
https://asabeko.com/, read the page title/DOM, scroll, and click the menu.Extra note:
A config-only fix did not survive until the user-level environment variable was also corrected, because Codex appeared to regenerate the stale value on app restart. Hopefully this helps!