Repository navigation
Browser Use fails on all sites: admin-enforced policy could not be verified #42466
Description
Summary
Browser Use fails on every tested website because the admin-enforced policy cannot be verified. The issue is not specific to one domain.
Steps to reproduce
- Open the ChatGPT desktop app.
- Open Google Chrome with the ChatGPT browser extension enabled.
- Confirm that Chrome displays “Manage” under Settings → Computer Use.
- Start a new Codex chat and mention
@Chrome. - Request a read-only action on an open tab or public website.
Actual result
Browser Use returns:
Browser Use could not complete this action because a browser security check was unavailable. Reason: The admin-enforced policy could not be verified, so access was not granted. Browser use could not verify the admin-enforced policy before accessing the website. This failure may be temporary. The agent may retry after the issue is resolved, but must not bypass browser security controls or use an indirect workaround.
Tested websites
The same error occurred on:
- https://tienda.dm.solar
- https://es.wikipedia.org
- https://example.com
- https://www.openai.com
- https://github.com
Expected result
Browser Use should complete the security verification and obtain access to the selected Chrome tab after permission is granted.
Troubleshooting completed
- Installed the latest official ChatGPT desktop application.
- Removed duplicate and Classic installations.
- Restarted ChatGPT and Chrome.
- Confirmed that the Chrome extension is connected.
- Confirmed that Chrome displays “Manage” under Computer Use.
- Verified that the application signature is valid and accepted by Gatekeeper.
- Tried from a new Codex chat.
- Tested multiple unrelated public domains.
Environment
- ChatGPT desktop app version:
26.901.20858 - Browser: Google Chrome
- Operating system: macOS
Feedback ID
01a065f2-9333-7133-a28b-b84b003998c9
Related issues
This appears to reproduce the same policy-verification failure reported in:
- macOS: Chrome tabs can be claimed, but every real-page action fails policy verification #39280 — matching macOS reproduction; tab discovery works, but every real-page action fails, including example.com.
- Chrome usage failed due to admin enforced policy #41334 — same admin-enforced policy verification error on Windows.
I also checked the possible stale CODEX_CLI_PATH workaround reported by another user. The variable is unset in both the process environment and the macOS launchd environment, so that workaround does not apply to this reproduction.
The issue is still reproducible with ChatGPT desktop app version 26.901.20858.
Activity
github-actions commentedon Sep 3, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
pgienergy commentedon Sep 3, 2026
Related reports: #39280, #41334 and #37721.
My case still reproduces after reinstalling the latest official macOS app,
restarting Chrome, reconnecting the extension and starting new Codex tasks.
CODEX_CLI_PATH is unset in both the process and launchd environments, so the
reported stale CLI-path workaround does not apply.
tanyapowell commentedon Sep 6, 2026
Additional macOS + Chrome reproduction on 6 September 2026, most recently around 13:55 UTC. Browser automation had worked earlier that day.
Observed in this task:
cua.getState()successfully lists Chrome and the existing tabs.cua.getTab(...)fails before page content is returned.This task was created from a ChatGPT project and runs in its generated local mirror. I have not performed a controlled comparison with a native local-project task, so this is context, not a confirmed cause. Multiple Chrome tabs are open; tab count has not been established as a factor.
The failure blocks reconciliation of an existing checkout. No repeat order was submitted and no policy bypass was attempted. The feedback ID is no longer available to me. Exact app/Chrome versions have not been captured for this report.
Related: #39280 and #41334.
Mike-CX83 commentedon Sep 8, 2026
Verified macOS fix for "The admin-enforced policy could not be verified"
I reproduced this exact Browser Use error on macOS using ChatGPT Desktop
26.901.51231and the Codex in-app browser:Browser navigation and even read-only DOM inspection failed on unrelated websites, including Gmail and a public WordPress site. This was not an actual administrator restriction, a website problem, or a sign-in problem.
What fixed it
If one particular website remains blocked, add its origin under Settings > Browser > Site permissions and allow Browse. Download, Upload, and CDP access are not required merely to navigate or read the site.
What I verified
Changing Approval without restarting did not fix the failure. The saved browser configuration changed from
approval_mode = "never_ask"toapproval_mode = "always_ask", but the running application continued returning the same error.After fully quitting and reopening ChatGPT:
Why this appears to happen
The exact internal defect has not been confirmed by OpenAI. Based on this controlled test, the misleading "admin-enforced policy" message can occur when the application cannot complete or refresh its browser-origin approval check.
With Always allow, the saved mode was
never_ask, so the rejected origin-access decision could not be surfaced for manual approval. Switching to Ask changed the mode toalways_ask, and restarting forced the application to reload that policy state.This is a verified macOS recovery procedure, not a claim that every occurrence has the same cause. Some Windows reports involve a separate stale
CODEX_CLI_PATHenvironment variable.CX83 Labs
fmosler-bot commentedon Sep 10, 2026
Additional reproduction on macOS / ChatGPT desktop (2026-09-10):
The same Browser Use policy-verification failure occurs on both a production site and a neutral control site, so this does not appear to be site-specific.
Tested:
Both fail with the same message:
The browser therefore could not open the login flow or inspect any OJS settings. No OJS settings were viewed or changed.
Because the neutral control site fails identically, this reproduction supports the existing report that the failure is in Browser Use policy verification rather than in the target website or its configuration.
tobyscammell commentedon Sep 11, 2026
Additional macOS reproduction on September 11, 2026.
Environment:
Observed behavior:
Browser selection succeeds, but creating a tab for an HTTPS site fails before page content or interaction becomes available:
The tool further reports that access was denied because the admin-enforced policy could not be verified. Multiple attempts and a reset of the supported browser JavaScript session followed by reinitialization produced the same error.
Diagnostics:
Expected behavior:
The browser should complete policy verification and open an authorized page, or provide a specific diagnostic and supported recovery procedure distinguishing a policy denial from an unavailable verification service or configuration problem.
Impact:
An explicitly authorized form-filling task cannot begin. No form data was entered. Private URLs, financial information, credentials, and raw logs are omitted. No security controls were bypassed.
fmosler-bot commentedon Sep 13, 2026
Additional macOS reproduction — September 13, 2026
ChatGPT Desktop Browser / Computer Use blocked by “The admin-enforced policy could not be verified” on macOS
Hello OpenAI team,
I am experiencing a reproducible problem with Browser / Computer Use in the ChatGPT Desktop application for macOS.
Error message
The browser security check blocks access to every website tested, including the neutral test site https://example.com. Therefore, the problem does not appear to be specific to a particular website.
Environment
Browser permissions
In ChatGPT Settings → Browser → Agent permissions:
The affected website was also explicitly set to “Always allow”.
Steps to reproduce
Local diagnostic checks
App integrity appears normal:
Result:
Gatekeeper:
Result:
CODEX_CLI_PATHis not set.During reproduction, macOS Unified Log shows extensive trust/security activity from ChatGPT, Codex and SkyComputerUseService, including:
SecTrustEvaluateIfNecessarySecKeyVerifySignatureSecTrustCopyAppleTrustAnchorsChatGPT also repeatedly emits the macOS runtime warning:
I could not find an explicit HTTP 401 or 403 response in the Unified Log.
These log observations are diagnostic context; they do not establish the root cause or prove that the main-thread warning causes the browser failure.
Timestamp of reproduction
September 13, 2026, approximately 11:00 local time, UTC+02:00.
The issue is completely reproducible and persists after restarting the application. Since example.com is also blocked while Browser permissions are explicitly set to “Always allow”, this appears to involve browser policy/safety verification rather than an individual website permission problem.
An additional test in the current task on September 13 also failed before page content was returned, with:
I can provide the complete Unified Log and screenshots through a private support channel if required. No log files or screenshots are attached to this comment.
Please escalate this to the Desktop / Browser / Computer Use engineering team.
Thank you.
Frank Mosler, MD
Editor-in-Chief on duty
Swiss Journal of Radiology and Nuclear Medicine
fmosler-bot commentedon Sep 13, 2026
Additional diagnostic files for my September 13 report are attached: the sanitized macOS diagnostic log, browser permissions screenshot, and example.com error screenshot.
Personal identifiers have been removed. Relevant diagnostic timestamps, version information, and security/runtime messages have been preserved.
fmosler-bot commentedon Sep 13, 2026
GitHub-42466-sanitized-attachments.zip
nateholritz commentedon Sep 17, 2026
Adding another macOS reproduction from September 17, 2026, this time using the built-in browser, with a directly observed failure → app restart → successful page-read sequence.
This is a recurring disruption to my application development work. I am losing substantial time and productive work repeatedly troubleshooting browser access before I can continue.
Observed sequence today
No project code, browser permission configuration, or website settings were changed by the agent between those failed and successful tests. No alternative browser or security bypass was used.
Scope and limits
26.908.70816(this is the plugin version, not a verified desktop app version).Please investigate why policy verification becomes unavailable and why an app restart temporarily restores it. An actionable diagnostic identifying the failed check, a supported recovery procedure, and a fix status would be much more useful than another generic restart instruction. Reliable browser access is essential to normal development and verification work.
Also reporting this reproduction on #43924, which describes recurring restart recovery.
September 17 follow-up: recovery did not last; remote work remains blocked
The failure recurred later the same day after successful browser work. The user reports being away from the laptop and making no changes to the computer, desktop app, browser, or permission settings during the interval. This is not a report of permission being revoked by the user.
New directly observed evidence:
The user describes this as working one minute and failing shortly afterward without touching the laptop. We have not measured a precise failure interval, established the internal trigger, or proven that sleep/wake, token expiry, network transitions, or policy caching caused it. No permission settings were changed and no security check was bypassed during these latest tests.
Impact: This repeatedly prevents unattended/remote development and live QA when the user is away from the laptop. Requiring a person to return to the machine and restart applications each time is not an adequate solution. Significant work time is being lost to repeated authorization troubleshooting despite prior authorization and successful earlier use.
Please provide a root-cause investigation and fix status, diagnostics distinguishing an actual policy denial from failure to retrieve/verify policy, and a supported recovery method that works remotely without weakening security. The earlier restart recovery was temporary, not a resolution. Private URLs, account identifiers, login links, credentials, and raw logs are intentionally omitted.
nateholritz commentedon Sep 21, 2026
Additional controlled reproduction on macOS, September 21, 2026 (EDT), following my earlier report:
Two conversations on the same laptop behave differently within the same running desktop-app session, using browser plugin version 26.915.31945 and https://example.com.
B's errors:
The admin-enforced policy could not be verified.codex app-server exited before returning initialize.No ChatGPT browser route is available for browser session [conversation B].Supported Chrome diagnostics now confirm Chrome running, the expected extension installed/enabled in the selected profile, and a valid native-host manifest. Earlier repeated app restarts did not provide a durable resolution. B re-established its documented browser bindings during the follow-up test.
This strengthens evidence of a conversation/runtime-specific difference rather than a general outage. The conversations use different project directories, so project configuration versus conversation identity has NOT been isolated. We cannot establish that the Chrome startup failure and policy-verification failure share one cause. Temporary client-new-thread route identifiers appear in both working and failing cases; that format alone is not evidence of a defect.
Could maintainers investigate conversation-to-browser routing and helper initialization for this failure pattern? Detailed timestamps and conversation IDs are being provided privately to OpenAI Support.
chrispotta commentedon Sep 22, 2026
Additional macOS in-app browser case from September 22, 2026:
This adds an in-app tab-discovery-success / page-control-failure example to the existing report. Please investigate whether browser policy or session verification state can become stale and provide an actionable recovery message when verification is unavailable. This report does not establish an administrator denial or a target-site access failure.
Environment: macOS, ChatGPT desktop app with Codex, built-in browser, bundled Codex CLI 0.155.0-alpha.9.2. Private site names, account details, and logs are omitted.
wwoland commentedon Sep 30, 2026
I can reproduce the same policy-verification error on September 30, 2026: macOS 15.6.1, ChatGPT desktop / Codex 26.915.31945 (build 9922), bundled Browser plugin 26.915.31945.
In my case the built-in browser has a manually opened OLX tab, but Browser Use cannot attach to it. Attempting to open community.openai.com also fails with "The admin-enforced policy could not be verified, so access was not granted."
Full Access and a CUA runtime reset did not resolve it. CODEX_CLI_PATH is unset in the command environment and in launchd.
The desktop log also repeatedly reports "No ChatGPT browser route is available for browser session ..." during getInfo. I posted the detailed reproduction and redacted log excerpt here: #47270 (comment)
I have not established whether the missing-route error is the cause or a separate symptom. Is there a supported fix or recovery procedure that preserves the current task?
Update — September 30, 2026: After fully quitting and reopening the desktop app, the already-downloaded update was applied: 26.917.62051 (build 10789). In the same existing task, Browser Use can now attach to the OLX tab and read its page contents; navigation also works. No browser-policy bypass or permission-file edits were used. This reports recovery in my case only; I cannot separate the effect of the full restart from the version update or confirm a general fix.