Codex App Browser Use keeps explicit-deny block for allowed calendar.google.com
What version of the Codex App are you using (From “About Codex” dialog)?
Codex App version was not available from the current debugging session. Local bundled plugin evidence:
chrome@openai-bundled: 26.602.40724
browser@openai-bundled: 26.608.12217
Chrome/Edge extension backend id: hehggadaopoacecdllhhajmbjkdcmajg
What subscription do you have?
Unknown from this session.
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
Browser: Microsoft Edge with the Codex extension installed and enabled.
What issue are you seeing?
Codex Browser Use / Edge extension can see and claim a manually opened Google Calendar tab, but any read-only page-content access is rejected by Codex browser security policy as if the user explicitly denied the site.
The rejection persists even after:
- adding
https://calendar.google.comto Codex site permissions withAllow browsing - adding related origins with
Allow browsing - changing the default browsing approval setting to
Always allow - confirming the Edge extension has site access set to
Allowed on all sites - killing/restarting Edge from Task Manager
- restarting the Codex desktop app/session
- opening Google Calendar in a fresh tab that loads successfully
Observed error when calling tab.playwright.domSnapshot() on the claimed Calendar tab:
Browser Use rejected this action due to browser security policy. Reason: The user has requested that https://calendar.google.com should not be used. The agent must not attempt to achieve the same outcome via workaround, indirect execution, raw CDP or browser commands, alternate browser surfaces, or policy circumvention. Proceed only with a materially safer alternative that does not require this blocked browser action; if none exists, stop and request user input.
This appears different from the related enterprise network policy blocks it class of Browser Use issues because the error says the user requested the exact origin not be used, while visible Codex permissions and default approval settings allow it.
What steps can reproduce the bug?
- On Windows, use Codex Desktop with the Edge/Chrome extension backend.
- Set Codex browsing/site permissions so the default approval is
Always allow. - Add explicit
Allow browsingentries for:
https://calendar.google.com
https://accounts.google.com
https://myaccount.google.com
https://ogs.google.com
https://calendar.googleusercontent.com
https://www.google.com
https://www.linkedin.com
https://linkedin.com
- In Microsoft Edge, confirm the Codex extension has Site Access set to
Allowed on all sites. - Open
https://calendar.google.com/calendar/u/0/r/daymanually and confirm it loads normally. - From Codex, initialize the extension-backed browser runtime and list open tabs.
- Observe that the Calendar tab is visible and claimable.
- Attempt a read-only DOM snapshot on the claimed tab.
- Observe that Browser Use rejects access to
https://calendar.google.comwith the explicit user-deny wording above. - Restart Edge and Codex, then repeat; the block persists.
Minimal diagnostic code shape used by the agent:
const { setupBrowserRuntime } = await import('<plugin root>/scripts/browser-client.mjs');
await setupBrowserRuntime({ globals: globalThis });
globalThis.browser = await agent.browsers.get('extension');
const tabs = await browser.user.openTabs();
const calendarInfo = tabs.find(t => (t.url || '').includes('calendar.google.com'));
const tab = await browser.user.claimTab(calendarInfo);
await tab.playwright.domSnapshot();
Observed browser metadata showed the extension backend was reachable and could enumerate/claim tabs:
{
"name": "Chrome",
"type": "extension",
"metadata": {
"extensionId": "hehggadaopoacecdllhhajmbjkdcmajg"
}
}
What is the expected behavior?
If the user explicitly allows https://calendar.google.com in Codex site permissions, and especially when default browsing approval is set to Always allow, Browser Use should permit read-only page access to the manually opened Calendar tab.
If access is intentionally blocked by another policy, Codex should surface the specific overriding policy/source rather than reporting that the user requested the origin not be used.
Additional information
Related but not exact issues found while searching:
- #27160: Chrome Extension connected but page content access blocked by enterprise network policy
- #26298: Browser Use navigation rejected by enterprise network policy
- #21955: Chrome plugin navigation blocked because thread networkAccess persists as false
This report intentionally avoids including account-specific Calendar event data or screenshots with workspace/customer context. The key reproducible symptom is that visible allow settings and default Always allow do not clear the explicit-deny block for https://calendar.google.com.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I can reproduce the same explicit-deny false positive on a current macOS build, with a different domain.
Environment:
26.721.41059(build5848)com.openai.codex26.721.41059150.0.7871.18626.5.2(25F84)arm64)https://justwrite.spaceExact error from a fresh Chrome Browser Use session:
The rejection happens on
tab.goto("https://justwrite.space"), before the page loads.Visible permission state:
Troubleshooting already performed:
This does not appear to be the older
sandbox_workspace_write.network_access = falsecase: the current task has unrestricted filesystem access and network access enabled, and the rejection names the exact origin as a supposed user deny.This looks like a stale or incorrect backend/thread/device-bound explicit-deny decision that is not represented in the visible settings and cannot be cleared by the user.
Could the team expose the source/identifier of the overriding deny decision, or provide a supported way to clear a false explicit-deny state?