Codex App Browser Use keeps explicit-deny block for allowed calendar.google.com

Open 💬 2 comments Opened Jun 17, 2026 by jackngai
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.com to Codex site permissions with Allow 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?

  1. On Windows, use Codex Desktop with the Edge/Chrome extension backend.
  2. Set Codex browsing/site permissions so the default approval is Always allow.
  3. Add explicit Allow browsing entries 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
  1. In Microsoft Edge, confirm the Codex extension has Site Access set to Allowed on all sites.
  2. Open https://calendar.google.com/calendar/u/0/r/day manually and confirm it loads normally.
  3. From Codex, initialize the extension-backed browser runtime and list open tabs.
  4. Observe that the Calendar tab is visible and claimable.
  5. Attempt a read-only DOM snapshot on the claimed tab.
  6. Observe that Browser Use rejects access to https://calendar.google.com with the explicit user-deny wording above.
  7. 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.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #27160

Powered by Codex Action

justdoswift · 1 month ago

I can reproduce the same explicit-deny false positive on a current macOS build, with a different domain.

Environment:

  • ChatGPT/Codex desktop app: 26.721.41059 (build 5848)
  • Bundle identifier: com.openai.codex
  • Bundled Chrome plugin: 26.721.41059
  • Google Chrome: 150.0.7871.186
  • macOS: 26.5.2 (25F84)
  • Architecture: Apple Silicon (arm64)
  • Affected origin: https://justwrite.space

Exact error from a fresh Chrome Browser Use session:

Browser Use rejected this action due to browser security policy. Reason: The user has requested that https://justwrite.space 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.

The rejection happens on tab.goto("https://justwrite.space"), before the page loads.

Visible permission state:

  • Codex Browser approval is set to Always allow.
  • The site-specific entry showed Browse, Download, and Upload all enabled.
  • The ChatGPT Chrome extension is allowed On all sites.
  • Full Access is enabled in the desktop app.
  • The user never requested that this origin be blocked and explicitly authorized access multiple times.

Troubleshooting already performed:

  • Removed/reset the site-specific permission entry so the origin falls back to the global Always allow setting.
  • Fully quit and restarted the desktop app.
  • Reconnected Chrome through multiple fresh Browser Use sessions.
  • Retried after repeated explicit user authorization.
  • Confirmed the result is unchanged.

This does not appear to be the older sandbox_workspace_write.network_access = false case: 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?