Repository navigation
macOS: Chrome tabs can be claimed, but every real-page action fails policy verification #39280
Description
Summary
On macOS Codex Desktop, the bundled Chrome extension can enumerate multiple Chrome profiles, list the correct profile's open tabs, and claim an existing tab, but every interaction with a real webpage is rejected before reaching Chrome with:
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.
The user reports that other Codex tasks on the same Mac can control the same Chrome state. The affected task has no known administrator policy configured.
Environment
- macOS 26.5.2 (25F84)
- Google Chrome 151.0.7922.138
- bundled Chrome-control package 26.814.41407
- extension ID:
hehggadaopoacecdllhhajmbjkdcmajg - extension version: 1.2.27259.19709
- multiple extension-backed Chrome profiles connected
- target profile metadata: profile name
Nathan, ordering4(account details redacted)
Diagnostics that pass
- Chrome is running.
- Extension is installed, registered, and enabled on the target profile.
- Native-host manifest exists and is valid.
- Expected extension origins are present.
agent.browsers.list()returns the target extension instance.browser.user.openTabs()lists the intended existing tabs.browser.user.claimTab(exactTabInfo)succeeds.- Creating an
about:blanktab succeeds. cua.move()onabout:blanksucceeds.
Reproduction
- Initialize the bundled Chrome browser-control runtime.
- Enumerate extension-backed Chrome instances.
- Select the intended current instance from its metadata.
- List open tabs and select an existing signed-in webpage.
- Claim the exact tab object returned by
openTabs(). - Attempt any real-page interaction:
tab.playwright.domSnapshot()tab.dom_cua.get_visible_dom()tab.cua.move(...)- a direct Playwright locator click
- The operation is rejected with the policy-verification error above.
The same rejection occurs on a neutral https://example.com/ tab, so it is not site-specific. An existing Gmail tab can hang until the browser runtime times out and resets.
Expected behavior
Once the correct profile and exact existing tab have been discovered and claimed, real-page DOM reads and input should work. If authorization cannot be established, the product should return a specific diagnostic code and actionable recovery path rather than an unverifiable admin-policy message.
Actual behavior
Discovery and claiming succeed, giving the appearance that browser control is active, but no mouse, DOM, click, or download command reaches real webpage content.
Suspected boundary
The defect appears after extension discovery/tab claiming but before Browser Use page-policy authorization or attestation. This is an inference, not a confirmed root cause. The fact that other Codex tasks reportedly work on the same machine argues against a general Chrome, extension, native-host, account, or target-site failure.
UX impact
The UI/control indicator can make the session appear active even though no page input can be delivered. Please distinguish:
- extension connected
- tab discovered
- tab claimed
- page readable
- input delivered
Related reports
- [Windows][26.721.4979.0] In-app Browser incident during Microsoft Store update-log lookup: startup crash loop, package remediation, and persistent deep-control timeouts #35311: Chrome route can claim tabs but deeper page reads time out
- Windows Codex Desktop cannot control discovered Chrome tab and Computer Use bridge is unavailable #26264: discovered Chrome tabs rejected by enterprise browser security policy
No credentials, cookies, email addresses, recording identifiers, or private URLs are included in this report.
Activity
alexx-ftw commentedon Aug 23, 2026
Cross-platform reproduction: I am seeing the same policy-verification boundary on Linux with the Codex Desktop in-app browser, not the Chrome-extension path described in this issue.
Environment:
Observed sequence:
browser.user.openTabs()returns the intended existing HTTPS tab.browser.user.claimTab(exactTabInfo)succeeds and returns a controllable tab handle.body.innerText()read andtab.dev.logs()inspection—is rejected before page content is returned.The reported error is identical:
I reproduced this against both the apex and a subdomain of the same public web application, across separate attempts. Discovery and claiming consistently work; failure occurs at the page-policy/attestation boundary. No cookies, local storage, credentials, private URLs, or account identifiers were inspected or included.
This suggests #39280 may not be limited to macOS, Chrome profiles, or the extension bridge; the shared real-page authorization path may be involved.
Diagnostic attestation: actor_id
codex-desktop-canary; turn_id01a03080-c032-7a13-b76e-b5d03f13e56e.scole954387 commentedon Aug 25, 2026
Same issue confirmed on macOS
I am experiencing the same policy-verification failure. Codex can discover and claim the correct open Chrome tab, but it cannot read or interact with the page afterward.
Environment
26.5.1(25F80)26.814.41407(build6720)151.0.7922.17426.814.414071.2.27268.51612hehggadaopoacecdllhhajmbjkdcmajgDefaultObserved behaviour
The Chrome connection successfully:
browser.user.openTabs().The first attempt to inspect the claimed page using
tab.playwright.domSnapshot()is then rejected before any page content is returned.Exact error
Local diagnostics
The bundled diagnostic checks report:
com.openai.codexextension.This appears to fail after extension discovery and tab claiming, at the page-policy authorization or attestation stage. It does not appear to be a missing extension, disabled extension, invalid native-host manifest, or inability to communicate with Chrome.
Manfred05 commentedon Aug 25, 2026
Same problem!
skalfa-user commentedon Aug 26, 2026
Confirming the same issue on macOS. The behavior is intermittent: Browser Use worked correctly in the same Codex task and controlled an authenticated Chrome tab, but later stopped working while tab discovery and claiming continued to succeed.
Environment:
Google Chrome: 151.0.7922.174
Codex Chrome extension: 1.2.27268.51612
Bundled Chrome-control package: 26.818.61809
Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
Diagnostics that pass:
Chrome is running.
The extension is installed, registered, and enabled in the selected profile.
The native-host manifest exists and is valid.
The expected extension origins are present.
browser.user.openTabs() returns the intended tabs.
browser.user.claimTab() succeeds.
However, every real-page operation fails immediately afterward, including DOM reads, Playwright evaluation, and visible-page inspection:
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.
The failure occurs after the tab has been discovered and claimed, but before any interaction reaches the page. Keeping the tab open, reopening it, waiting, and retrying did not resolve the problem.
The intermittent nature is especially confusing: the same task and browser session can work normally, then suddenly fail at the policy-verification stage without any Chrome, extension, profile, or website configuration changes.
This looks identical to the authorization/attestation boundary described in this issue rather than a Chrome-extension or native-host failure. It would be helpful if Codex exposed the underlying policy-service or network error and provided an actionable recovery path. The current “admin-enforced policy” wording is misleading when no actual administrator block is known.
I can provide additional redacted diagnostics if needed.
kcc989 commentedon Aug 26, 2026
I’m experiencing what appears to be the same policy-verification failure, but through the Codex in-app browser rather than Chrome extension control.
Environment
Codex In-app Browser(iab)Reproduction
https://github.com/.tab.goto("https://github.com/").The page never loads, so no DOM inspection or interaction is possible.
I retried after reconnecting to the browser runtime and receiving a new in-app-browser instance ID. The result was identical. This was therefore reproducible across two fresh browser sessions.
This differs slightly from the original report: it does not involve enumerating Chrome profiles or claiming an existing tab. The failure occurs during initial navigation in a newly created in-app-browser tab. That may indicate the affected policy-verification boundary is shared by both the in-app browser and Chrome-control paths, rather than being specific to extension-backed tab claiming.
Please let me know if there are diagnostic logs or identifiers I can collect safely to help isolate the failed policy check.
skfq4qnmyy-art commentedon Aug 26, 2026
Windows cross-platform reproduction (built-in Browser and Chrome control)
I am seeing the same policy-verification failure on Windows, including the Codex in-app browser path. This adds a Windows reproduction to the macOS and Linux reports above.
Environment
26200.916826.820.7780.026.820.60940151.0.7922.170Observed behavior
@Browserand Chrome control is rejected before the target page loads with:2026-08-25T22:04:07Z. Manual navigation to the same origin succeeded afterward at approximately2026-08-26T00:50Zand01:50Z. Fresh automated retries failed identically at2026-08-26T22:54:35Z,22:54:55Z, and22:59:21Z.Local diagnostics
That log line is correlated with Browser startup, but I am not claiming it is proven causal.
Expected behavior
An explicitly allowed site that loads in the shared built-in browser should be available to Browser control. If the managed-policy or attestation service cannot be reached or evaluated, the error should expose a specific diagnostic code and supported recovery path rather than implying an intentional administrator block.
This looks consistent with the shared real-page policy/attestation boundary described in this issue, rather than a target-site, login, DNS/TLS, Chrome-extension, or local allowlist failure.
The private URL, credentials, cookies, account identifiers, session identifiers, and raw logs are intentionally omitted.
dan-hook commentedon Aug 27, 2026
Windows corroboration with a clean version boundary:
Manual in-app browsing works, and no local Codex managed-policy files or registry policy were found. Also, DeviceCheck attestation unavailable ... errorCode=1 appeared immediately before a confirmed successful Browser Use action, so that marker alone does not explain the regression.
webolabo commentedon Aug 28, 2026
I can confirm the same policy-verification error on Windows 11.
Environment:
The feature worked previously on the same account and computer.
Relevant Codex log:
GET /accounts/[redacted]/settings -> 401
{"detail":"Must use workspace account for this operation"}
Tab discovery and claiming succeed, but every attempt to read or interact with
the page is rejected before any browser action is performed.
dan-hook commentedon Aug 28, 2026
Following up on my Windows reproduction: this is resolved.
The key was stevendelong’s comment in #24814:
I found the same condition:
CODEX_CLI_PATHpointed to a nonexistent, version-hashedcodex.exe. I removed only that user-level override and fully restarted Codex.After restart:
CODEX_CLI_PATHwas unset in process, user, and machine scope.https://example.com/and read its title and DOM.So, for my Windows reproduction, the “admin-enforced policy could not be verified” message was a misleading symptom of a stale CLI override—not an administrator policy denial. This may not explain the original macOS report or every reproduction.
Suggested product fix: validate environment-supplied CLI paths, ignore or clean up nonexistent overrides during Repair/Reset/reinstall, and surface a direct CLI/config-bridge error instead of the policy-verification message.
webolabo commentedon Aug 28, 2026
Confirmed: my Windows 11 / Personal Pro reproduction is now resolved as well.
I found the same stale user-level CODEX_CLI_PATH override. It pointed to a nonexistent, version-hashed codex.exe.
I backed up the value, removed only the user-level environment variable, fully quit Codex, and restarted it.
Verification after restart:
Additional A/B evidence: bundled Browser version 26.825.32147 still failed before removing CODEX_CLI_PATH. The same Browser version worked immediately after removing the stale override and restarting Codex.
This strongly confirms the stale CLI override as the cause of my Windows reproduction. It does not necessarily explain the macOS or Linux reports.
Thank you, @dan-hook dan-hook and @stevendelong, for the diagnosis.
rsteenwyk commentedon Aug 29, 2026
Linux reproduction where
CODEX_CLI_PATHis validI reproduced this on August 28, 2026:
openai-codex-desktop 26.820.80927-1codex-cli 0.150.0-alpha.8codex-cli 0.150.1Browser control worked within the past few days, but I noticed the failure today. I cannot determine whether today’s desktop update introduced it, whether it began with an earlier build, or whether the timing is unrelated.
The in-app Browser can enumerate an already-open tab and see its URL/title, but any real-page operation such as
domSnapshot()fails with:This also reproduces on
github.com, so it does not appear specific to the original target site.I investigated the stale
CODEX_CLI_PATHexplanation:[mcp_servers.node_repl.env]entry in~/.codex/config.toml./usr/lib/chatgpt/resources/codex.I also compared the cached Arch packages from today’s update:
26.820.71523-1 → 26.820.80927-10.150.0-*prerelease to accepting versions>= 0.150.0-alpha.8.0.150.0-alpha.8, and the running app reports the new26.820.80927build.Therefore, the nonexistent/stale CLI-path explanation does not apply to this Linux reproduction. The current desktop build recognizes the bundled CLI as compatible, but Browser policy verification still fails.
Additional checks:
200./accounts/.../settings → 401; the lower-level policy-verification request does not appear to be logged there.It would help if the Browser policy gate exposed the failing endpoint/status or a diagnostic reason distinguishing entitlement failure, policy-service connectivity, and local configuration problems.
rsteenwyk commentedon Aug 29, 2026
Workaround found: use a standalone task or native Codex local project
For anyone encountering:
I found a reliable workaround on Linux:
The in-app Browser works in both cases. Full Access is not required; the default permissions worked.
The failure remains reproducible only in tasks created from ChatGPT projects. Those tasks use generated local mirrors under:
This does not fix the underlying bug, but it restores Browser Use while the ChatGPT-project integration is being investigated.
Reproduction matrix
One failing ChatGPT project warned that a project source could not be synced. The other showed no sync warning and still failed identically, so the individual source-sync failure does not appear to be the cause.
Environment
26.820.809270.150.0-alpha.80.150.1Browser Use worked within the past few days. I noticed the failure today, although I cannot confirm whether today’s desktop update introduced it.
CLI-path testing
I investigated whether this was the stale
CODEX_CLI_PATHproblem reported elsewhere:config/read,configRequirements/read, andgetAuthStatus.CODEX_CLI_PATHto the0.150.1binary and fully restarting Codex did not fix Browser Use in a ChatGPT-project-backed task.This does not appear to be the stale or nonexistent CLI-path issue in this environment.
Relevant failure logs
During a failed Browser action, the packaged helper logged:
The Browser service then converts the unavailable config/policy result into:
This appears to be a fail-closed presentation of an internal auth/config bridge failure, rather than evidence of an actual administrator restriction.
Desktop-package comparison
I compared the cached previous desktop package with
26.820.80927:Current conclusion
The problem appears specific to tasks initialized from ChatGPT projects. It does not reproduce in standalone Codex tasks or native Codex local projects, even with default permissions.
The likely area to investigate is the ChatGPT-project task bootstrap or mirrored workspace interacting with the Browser helper’s child app-server authentication/configuration bridge.
Until that is fixed, using a standalone task or native Codex local project is an effective workaround for Browser Use.
I also opened a feedback report in app to OpenAI - 01a04a42-2626-73b0-b212-658e12a0a504
mattnna-glitch commentedon Aug 30, 2026
Additional macOS reproduction from a ChatGPT Project task
I am seeing the same browser policy-verification failure on macOS.
Environment:
26.825.32147Observed behaviour:
Exact error:
Checks completed:
CODEX_CLI_PATHis not set in this environment.This reproduction is consistent with the ChatGPT-Project-specific behaviour described above. I have not yet tested the standalone-task workaround on this Mac, but the current failing task is backed by a ChatGPT Project. No private URLs, account identifiers, cookies, local paths, or task IDs are included here.
khichdinetwork commentedon Aug 30, 2026
Same issue macos codex - wont do live updates to anything with internet access (local is okay)
Earlier it used to login to my ssh of server and make live changes, or update my clients websties using ftp or terminal or whatreer - now it suggests to use the inbuilt browser and terminal and fails saying they are not authenticated or working even if logged in. Total mess. This new limitaiton or wall makes all my quick development so slow. I suspect they are doing this on purpose to limit usage for the higher paid plans and people who are now using 5.6 Luna Medium against other versions.
Powered by Codex & OWL
Version 26.825.51511
Released Aug 30, 2026
Manfred05 commentedon Aug 30, 2026
Additional current evidence from macOS Codex Desktop (2026-08-30):
After reconnecting the browser-control runtime, the user reported that three relevant Chrome tabs were open. However, both browser surfaces exposed no usable tabs:
This is a stronger failure mode than the original report: the user-visible Chrome state was not discoverable in the active control session, so there was no exact tab to claim and no safe way to perform the required real-page read. No product edits, saves, checkpoint changes, cookies, credentials, or private URLs were involved.
Please consider recording this as another post-discovery/session-synchronization failure mode, and expose a clear diagnostic distinction between “no tabs discovered in this control session” and “the user has no Chrome tabs open.”
khichdinetwork commentedon Aug 30, 2026
Powered by Codex & OWL
Version 26.715.21425
Released Jul 17, 2026
This version (before the voice Ai option) seems to be working better and most of the time for a new chat allows things to work as before including FTP , Chrome and SSH terminal control.
I had chat gpt get me a reversal process. Sharing it here for who may find it useful.
CHATGPT HELPED ME DOWNGRADE OR ROLL BACK (MAC SILICON USER HERE)
Found it — and this is a much better rollback target.
26.715.21425 (build 5488), released July 18, is immediately before OpenAI's July 23 rollout of Voice in Work/Codex. We also have direct evidence that this exact build successfully restored in-app Browser + Chrome navigation/DOM inspection for users who had lost those tools. OpenAI announced Voice in Work/Codex on July 23.
Even better, a July 17 report specifically says Voice was missing on 26.715.21425, which is exactly the boundary you wanted.
The archived version history confirms 26.715.21425 is a genuine ChatGPT/Codex release in the official build sequence.
Let's install that one
Because you're on Apple Silicon, open Terminal and run these commands one at a time:
cd ~/Downloads
Then:
curl -L "https://persistent.oaistatic.com/codex-app-prod/ChatGPT-darwin-arm64-26.715.21425.zip" -o ChatGPT-26.715.21425.zip
That URL follows OpenAI's documented archive naming scheme; the version itself is independently present in the archived release history.
Then unzip it:
rm -rf ~/Downloads/ChatGPT-old
mkdir ~/Downloads/ChatGPT-old
ditto -x -k ~/Downloads/ChatGPT-26.715.21425.zip ~/Downloads/ChatGPT-old
Before replacing anything, verify what we downloaded:
defaults read ~/Downloads/ChatGPT-old/ChatGPT.app/Contents/Info.plist CFBundleShortVersionString
It must print:
26.715.21425
Then verify Apple's signature:
codesign --verify --deep --strict --verbose=2 ~/Downloads/ChatGPT-old/ChatGPT.app
And:
codesign -dv --verbose=4 ~/Downloads/ChatGPT-old/ChatGPT.app 2>&1 | grep TeamIdentifier
We want:
TeamIdentifier=2DC432GLL2
Do not install it if either verification fails.
If those checks pass, quit ChatGPT completely:
osascript -e 'tell application "ChatGPT" to quit'
Then we'll replace /Applications/ChatGPT.app.
Stop after the signature/version checks and send me the Terminal output. I want to verify those two things with you before we overwrite the application.
And there's another reason I'm optimistic about this build: 26.707.91948, immediately before it, had a known regression where Browser/Chrome/Computer Use disappeared; multiple reports say upgrading specifically to 26.715.21425 restored them.
So 26.715.21425 is not just “some old version.” It's a particularly interesting pre-Voice build with documented working Browser/Chrome tooling.
1noone79 commentedon Sep 3, 2026
I encountered the same exact policy-verification error on macOS, using the ChatGPT desktop app’s built-in browser rather than Chrome.
The affected task was created from a ChatGPT Project. The target website was visible and signed in. The agent could list the tab, but reading the page failed with:
“The admin-enforced policy could not be verified, so access was not granted.”
Browser control is enabled, approval is set to “Always ask,” and no per-site restrictions are listed. Rebooting and starting a new chat in the same project did not resolve the failure at that time.
Feedback ID: 01a06663-323c-7d53-9a50-a6e402d709e3
Update: Later in this same task, the agent successfully read this GitHub issue and opened the GitHub login page in the built-in browser. The original target website has not yet been retested, so this should not be interpreted as a confirmed persistent failure on every site or as a confirmed recovery.
Could you check the uploaded diagnostics and advise on a supported recovery procedure?
tanyapowell commentedon Sep 6, 2026
Adding a related macOS + Chrome reproduction from 6 September 2026: tab discovery succeeds, but selecting an existing HTTPS tab fails before page content is returned with “The admin-enforced policy could not be verified, so access was not granted.” Automation had worked earlier that day.
This task uses a ChatGPT-project local mirror; causation has not been established. Full observations and limitations are in #42466 (comment) . The feedback ID is no longer available to me.
olyaiy commentedon Sep 7, 2026
Additional macOS reproduction on September 7, 2026, with current bundled CLI paths verified.
Environment:
Observed in the affected task's recorded tool outputs:
Error:
Checks:
This may relate to the ChatGPT Project initialization/auth bridge described in #39280 (comment), but that remains a hypothesis here. The known missing-CLI-path explanation does not fit the current registered executable.
Please provide a supported diagnostic that reports the underlying policy/auth/config failure, the selected native-host registration, and an actionable recovery procedure. The present message does not distinguish a real admin denial from a failed local helper or unavailable policy check.
No credentials, financial information, private URLs, account/project/task identifiers, or raw logs are included. No security checks were disabled and no fix is claimed.
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
natashangelica commentedon Sep 9, 2026
macOS reproduction confirming the ChatGPT-project boundary.
ChatGPT/Codex Desktop 26.901.51231, personal account, Apple Silicon.
Browser Use fails in tasks created from a ChatGPT Project, and succeeds in a standalone task on the same machine, same client, same session: example.com loaded and the page title was read without error.
No CODEX_CLI_PATH override in any shell profile. The config.toml entry points to an existing, executable file.
This matches the standalone-task workaround reported above.