Repository navigation
GPT Struggles to access tabs on browsers #43924
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Codex desktop app: 26.901.41600 (build 7982) - Bundled Codex CLI: 0.153.4
What subscription do you have?
Max
What platform is your computer?
Apple M4
What issue are you seeing?
Codex browser access is completely unavailable across all models and browser routes.
Both GPT-6 Astra and GPT-5.6 Sol fail with:
“Browser Use could not complete this action because a browser security check was unavailable. The admin-enforced policy could not be verified, so access was not granted.”
The extension successfully detects and lists the open Chrome tabs, so the browser connection is working. The failure occurs when Codex attempts to read a page.
This has been reproduced on:
- Chrome
- Brave
- Codex’s built-in browser
- RotaCloud
- ClassForKids
- example.com
Installed versions:
- ChatGPT desktop: 26.901.41600
- Chrome: 152.0.7977.77
- ChatGPT browser extension: 1.26.901.11451
The issue is independent of the selected GPT model, browser, website and website login. Claude can access the same operational websites successfully. This is significantly interrupting normal business workflows and is the main reason I cannot use Codex instead of Claude.
What steps can reproduce the bug?
Feedback ID: 01a082ed-047f-7962-9cff-dc21c13ac635
What is the expected behavior?
To control the tabs on browsers. Its currently says It can see them but I need to restart. I then restart the browser and gpt and it works as it should
Additional information
Restarting both apps makes it work, but after being left for a few hours this needs repeating. Browser use seemed to work fine with Tesco groceries yesterday
Activity
github-actions commentedon Sep 8, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
nateholritz commentedon Sep 10, 2026
Additional reproduction on macOS with ChatGPT desktop 26.903.61454 (Darwin 25.6.0, arm64).
The user reports recurring browser automation failures after putting the computer to sleep and waking it. Manually closing and reopening Chrome or the desktop app has sometimes restored access, but the interruption keeps recurring. Sleep/wake is an observed correlation, not a confirmed root cause.
On September 10, 2026, local diagnostics confirmed an app restart at 12:24 p.m. Eastern. At approximately 12:29 p.m., the in-app browser was discoverable and successfully created an about:blank tab, but navigation failed with:
A later supported in-app browser attempt around 12:38 p.m. successfully navigated and read the page. No security controls were changed or bypassed. Earlier app logs included network-change, disconnected, and timeout errors, but they did not establish why policy verification failed.
Expected: browser authorization recovers reliably after sleep/wake and restored connectivity, or provides a specific diagnostic and supported recovery action. Repeated restarts should not be necessary to continue ordinary development and browser verification.
Please investigate policy-verification/session refresh after inactivity or network transitions. This report intentionally omits private URLs, account details, credentials, and raw logs.
zamuelodg commentedon Sep 10, 2026
I’m experiencing the same issue on macOS with Codex app version 26.903.61454.
Browser control was working normally while I was setting up a Meta Ads campaign, then stopped working. I don’t recall the exact moment it began, so I cannot confirm whether it followed sleep/wake or a network change.
Codex still detects the Chrome tab, but cannot read or control it because the admin-enforced policy could not be verified. The issue persists in new conversations.
Related report: #44621.
fmosler-bot commentedon Sep 11, 2026
Additional reproduction on macOS, September 11, 2026.
The browser integration successfully detects an already-open tab for https://sjoranm.com, so tab discovery/connection appears to be working. However, the very first attempt to access the tab contents fails with:
After that failure, Codex/ChatGPT cannot read the page contents or perform clicks in the detected tab. Nothing on the website is changed.
This reproduces the same pattern described in this issue: the tab itself is visible to the browser integration, but browser control is blocked at the policy-verification step before any DOM interaction can occur.
The affected site is an OJS (Open Journal Systems) installation, but the failure occurs before meaningful website interaction, so this does not appear to be specific to OJS or the site login.
Expected behavior: once the existing tab is detected, browser control should be able to read and interact with the page without failing the policy-verification check.
fmosler-bot commentedon Sep 11, 2026
Additional diagnostic capture from macOS during a live reproduction of the browser-control failure.
Key observations:
requirements_toml_base64in thecom.openai.codexdomain. This alone does not prove a fault, because that key is normally absent on unmanaged/personal Macs.access request result was 1, timeout was 0, so the macOS automation permission path appears to be granted rather than denied.SkyComputerUseService, includingSecKeyVerifySignature,SecTrustEvaluateIfNecessary, and Apple trust-anchor lookups.SecStaticCode network blocked: NO, i.e. the local macOS code-signing path is not showing a network block.no route, but the same blocks also report another viable route / RTT comparison, so this does not look like a complete loss of network connectivity.This narrows the failure toward Browser Use/Codex policy verification or policy/session refresh rather than a normal macOS TCC denial or a site-specific problem.
The raw capture contained local usernames/paths and is intentionally not attached here.
fmosler-bot commentedon Sep 11, 2026
Additional reproduction detail: the same account also reproduces the identical browser-policy failure in ChatGPT Cloud Browser, not only in local macOS browser control.
Observed behavior in both environments:
This is important because Cloud Browser does not depend on the user's local macOS browser-control stack. The identical failure across local macOS Browser Use and Cloud Browser therefore makes a purely local macOS TCC/AppleEvents/browser-integration cause less likely, and points more strongly toward a shared account/workspace/backend policy-verification path.
In the local macOS reproduction, TCC/AppleEvents authorization is granted and macOS reports
SecStaticCode network blocked: NO, yet Browser Use still fails at the higher-level policy-verification step.No website-specific behavior is involved: the failure happens before meaningful interaction with the target site.
fmosler-bot commentedon Sep 11, 2026
Additional scope clarification: direct connector/API actions from ChatGPT continue to work normally on the same account. For example, ChatGPT can successfully use the connected GitHub integration to create and comment on issues without relying on Browser Use or local UI automation.
This suggests the account is not generally unable to perform external actions. The failure appears specific to the Browser Use / Computer Use control path (including the policy-verification layer), rather than to overall account connectivity or external-service access.
scbgk7zjtv-cmd commentedon Sep 12, 2026
Additional reproduction on Windows with ChatGPT/Codex version 26.908.40834.
Platform: Microsoft Windows NT 10.0.26200.0 — x64
Codex detects both Chrome and Edge, but browser control fails when it tries to identify/access the current page URL. Both browsers work normally when used manually.
The issue started on September 11, 2026 and persists on September 12 after multiple retries and restarts.
This is blocking daily production work involving Mercado Livre, Shopee and FullSystem.
Feedback ID: 01a0937c-5460-7470-99c2-c517afdefd6f
The behavior appears consistent with this issue, now reproduced on Windows as well.
scbgk7zjtv-cmd commentedon Sep 12, 2026
Additional diagnostic:
Using the same ChatGPT account, Work Cloud Browser successfully opens and reads example.com, Wikipedia, and Shopee Brazil.
Mercado Livre returns a site-specific page error in Cloud Browser.
FullSystem could not be tested because its authenticated session exists only in the local desktop browser, which is not shared with the separate Cloud Browser session.
Meanwhile, Codex Desktop version 26.908.40834 continues to detect local Chrome and Edge but cannot control/read them.
This further suggests that the main issue is with the Desktop external-browser control path, rather than a general restriction on my ChatGPT account.
Feedback ID: 01a0937c-5460-7470-99c2-c517afdefd6f
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.
Cross-reported on #42466: #42466 (comment)
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.
wwoland commentedon Sep 30, 2026
Another reproduction of 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.
Browser Use fails in the built-in browser on both olx.uz and community.openai.com, with "The admin-enforced policy could not be verified, so access was not granted." A manually opened tab is present, but the agent cannot attach to it. Switching the task to Full Access and resetting the CUA runtime did not help.
Unlike the temporary-recovery case in this issue, I cannot confirm a full app restart fixes my case. CODEX_CLI_PATH is unset in the command environment and in launchd.
The desktop log also shows repeated missing-browser-route errors. Detailed reproduction: #47270 (comment)
Please share any known fixed build or supported recovery that keeps the existing 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.
scbgk7zjtv-cmd commentedon Oct 14, 2026
The same browser-access problem happened again on Windows on October 14, 2026.
Codex desktop app version: 26.1007.71326
The main Codex conversation could not access either Chrome or Edge. The browser window was sometimes reduced or minimized, and Codex reported:
“Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy.”
However, the ChatGPT browser sidebar was able to access the same Shopee page and complete the task successfully. This suggests that the website login and permissions were working, while browser access from the main Codex conversation was not.
I restarted the computer, restarted the Codex app and browsers, and removed and reinstalled the browser extension. The problem has occurred for the second time this week and is causing substantial loss of productive time.
New Feedback ID:
01a085e2-7a21-7cd1-a4b4-1adf789508e3