Skip to content

Chrome usage failed due to admin enforced policy #41334

Open
Open
Chrome usage failed due to admin enforced policy#41334
Labels
appIssues related to the Codex desktop appbrowserbugSomething isn't workingsafety-checkIssues related to safety and abuse checkswindows-osIssues related to Codex on Windows systems

Description

@harrydbarnes
harrydbarnes
opened on Aug 28, 2026

What version of the Codex App are you using (From “About Codex” dialog)?

26.825.32147

What subscription do you have?

Plus

What platform is your computer?

Windows 11 64bit

What issue are you seeing?

Multiple tasks have been able to trigger Chrome debug control but codex chat reports back the following:

Chrome’s managed security gate blocked Codex from inspecting the page. The reported error was:
“The admin-enforced policy could not be verified, so access was not granted.”

This is not evidence of an extension or site code error. I could see the tab and title, but Chrome would not allow automated DOM inspection, console access, or reloads. The specific administrator policy is not exposed by the error, and I must not bypass it.

What steps can reproduce the bug?

Try to access the page I am on via a prompt, and see this issue in Codex

What is the expected behavior?

Access fine and do what you need to do

Additional information

I have used codex for several months now with no issues on the same laptop, site and setup. This is new as of a few days ago.

Activity

  1. harrydbarnes
    added
    appIssues related to the Codex desktop app
    on Aug 28, 2026
  2. github-actions
    added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    browser
    safety-checkIssues related to safety and abuse checks
    on Aug 28, 2026

  3. rsteenwyk commented on Aug 29, 2026

    @rsteenwyk
    rsteenwyk
    on Aug 29, 2026

    Workaround found: use a standalone task or native Codex local project

    For anyone encountering:

    The admin-enforced policy could not be verified, so access was not granted.

    I found a reliable workaround on Linux (and very possible this may apply to Windows as well):

    1. Start a standalone Codex task outside a ChatGPT project, or
    2. Create/use a native Codex local project.

    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:

    ~/.codex/.chatgpt-projects/g-p-*/

    This does not fix the underlying bug, but it restores Browser Use while the ChatGPT-project integration is being investigated.

    Reproduction matrix

    Task type In-app Browser
    Standalone Codex task, default permissions Works
    Newly created native Codex local project, default permissions Works
    Task created from ChatGPT Project A Fails
    Task created from ChatGPT Project B Fails

    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.

    I have further details in my comments on #39280

  4. Tie-fighter commented on Aug 30, 2026

    @Tie-fighter
    Tie-fighter
    on Aug 30, 2026

    I can reproduce the same policy-verification failure on Fedora Linux 44 using Codex Desktop and the bundled in-app browser, both version 26.825.41651.

    The page renders normally and “Comment with Codex” successfully transfers the selected element metadata and marker screenshot. Browser Use can also enumerate the open tab. However, the first read-only DOM operation fails with: “The admin-enforced policy could not be verified, so access was not granted.”

    Setting the permission to “Ask for Approval” does not produce an approval prompt. A neutral test against https://example.com/ fails with the same error, so the problem is not site-specific. The relevant browser feature flags are enabled, and I have at least 27 confirmed failures against the original application origin between August 28 and August 30, 2026.

    Private in-app feedback has also been submitted. This appears to extend #41334 to Linux and the in-app browser backend; the visible-browser/blocked-agent boundary also resembles #24814.

  5. Jack-the-slp commented on Aug 30, 2026

    @Jack-the-slp
    Jack-the-slp
    on Aug 30, 2026

    Additional Windows reproduction — Aug 31, 2026

    I can reproduce the same policy-verification failure on a newer Codex Desktop build. This task is running from a normal native local Codex project, not from a ChatGPT Project mirror.

    Environment:

    • Codex Desktop: 26.825.5331.0
    • Codex CLI: 0.149.0
    • OS: Windows 11 Enterprise x64, version 10.0.26200 (build 26200)
    • Selected Browser Use backend: Codex In-app Browser
    • Browser discovery succeeds and enumerates the in-app browser plus installed Chrome and Edge extension backends.

    Minimal reproduction:

    1. Ask Browser Use to create a new controlled tab.
    2. Navigate to https://weslp.com/.
    3. Create another fresh controlled tab and navigate to https://example.com/.

    Actual result:

    Tab creation succeeds, but both navigation attempts are rejected before either page loads:

    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.

    Expected result:

    Public HTTPS pages should pass the policy check. If an organization policy actually blocks access, the product should identify the applicable policy source and provide an actionable recovery path; a policy-verification outage should not be presented as an intentional denial.

    Additional observations:

    • The failure is not hostname-specific; the neutral example.com test fails identically.
    • The native/local-project workaround described above does not resolve this instance.
    • Reusing the existing Browser runtime and performing the supported retry gives the same result.
    • No alternate browser surface or policy bypass was attempted.
    • No account identifiers, workspace paths, extension-instance IDs, or private logs are included here.

    Impact: Browser-based visual, interaction, and responsive QA is completely blocked even though the browser runtime itself is discoverable.

  6. nryabkov commented on Sep 1, 2026

    @nryabkov
    nryabkov
    on Sep 1, 2026 – with ChatGPT Codex Connector

    Reproduced on Linux in a task created from a ChatGPT Project mirror, using Codex Desktop and the bundled in-app Browser. The page opens normally and the user can sign in; Browser Use can list the tab title and URL, but every DOM inspection or interaction fails with “The admin-enforced policy could not be verified, so access was not granted.” The failure persists after restarting the app and also occurs with help.openai.com, so it is not target-site-specific. No policy bypass was attempted.

  7. harrydbarnes commented on Sep 2, 2026

    @harrydbarnes
    harrydbarnes
    on Sep 2, 2026
    Author

    Fixed by running this past Chat GPT to fix another log of it in PATH. Lost a week of chats, though.

  8. tanyapowell commented on Sep 6, 2026

    @tanyapowell
    tanyapowell
    on Sep 6, 2026 – with ChatGPT Codex Connector

    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.

  9. Mike-CX83 commented on Sep 8, 2026

    @Mike-CX83
    Mike-CX83
    on Sep 8, 2026 – with ChatGPT Codex Connector

    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.51231 and the Codex in-app browser:

    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 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

    1. Open ChatGPT Settings > Browser.
    2. Under Permissions, find the first row labeled Approval.
    3. Change Approval from Always allow to Ask or Ask every time.
    4. Do not change the separate History, Downloads, or Uploads settings.
    5. Fully quit ChatGPT using Command-Q. Closing the window is not enough.
    6. Reopen ChatGPT and retry Browser Use.
    7. If an Access browser origin request appears, approve 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" to approval_mode = "always_ask", but the running application continued returning the same error.

    After fully quitting and reopening ChatGPT:

    • Gmail navigation and DOM inspection worked.
    • The public WordPress site also opened and could be inspected.
    • The WordPress site was not added to the custom site list, suggesting that the important steps were changing Approval to Ask and fully restarting, not broadly granting every site capability.

    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 to always_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_PATH environment variable.

    CX83 Labs

  10. MichaelSpece commented on Sep 8, 2026

    @MichaelSpece
    MichaelSpece
    on Sep 8, 2026

    Additional Windows reproduction: VS Code + Edge, with policy-client diagnostic evidence

    Observed on September 8, 2026. Adding this reproduction and source evidence to the existing report.

    Environment

    • VS Code 1.136.1, Codex extension openai.chatgpt 26.901.22334 (Windows x64).
    • Bundled Codex package metadata: 0.153.0, target x86_64-pc-windows-msvc.
    • Windows version reported by .NET: Microsoft Windows NT 10.0.26200.0.
    • Selected browser: Microsoft Edge 152.0.4191.66, extension backend.
    • Bundled Chrome plugin/browser client: 26.727.51351.
    • Native local repository workspace in the IDE. This reproduction did not use a ChatGPT Project mirror.

    Steps and observed result

    Using the documented Chrome plugin bootstrap and its persistent Node REPL runtime:

    const browser = await agent.browsers.getForUrl("https://passwords.google.com/");
await browser.user.openTabs();
const tab = await browser.tabs.new();
await tab.goto("https://passwords.google.com/");

    Browser selection chose Edge. Tab enumeration and creation succeeded. Navigation failed; one bounded retry through the same runtime failed identically. The exact returned error was:

    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 cannot access https://passwords.google.com because the admin-enforced policy could not be verified. Please try again later. 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.

    No permission prompt appeared. No credential was retrieved, copied, or submitted. The created tab was subsequently finalized/closed. This reproduction tested one origin; it does not establish that all origins fail.

    Diagnostic evidence from the installed client

    File: plugins/cache/openai-bundled/chrome/26.727.51351/scripts/browser-client.mjs, relative to Codex home.

    SHA-256: f204d340535055781952b10ed396de20b842f00a19e430852f7e121ad1ce91f6.

    In this build, minified function p5 concurrently calls config.readRequirements() and config.read({cwd: ..., includeLayers: false}), then normalizes and evaluates the results. Its catch handler is:

    catch { return "unavailable" }

    The client maps this result through codex-network-policy-unavailable to enterprise_policy_unavailable, with decisionSource: "enterprise" and retryable: true. This is distinct from its actual-denial reason, enterprise_policy_blocked.

    The normalizer (f5 in this build) tolerates absent network-policy settings by initializing neutral defaults. Therefore, the visible error alone does not prove an intentional administrator denial or identify a missing policy setting. An exception from either configuration read or subsequent processing is collapsed into the same result, with its original cause discarded at this boundary.

    The relevant local IDE extension log inspection did not expose the underlying exception. We have not isolated which operation threw, and have not established whether this shares the stale CLI-path cause described in #28474. No client or security-policy changes were made during this investigation.

    Expected behavior / requested investigation

    Preserve the fail-closed behavior when policy verification fails, while making the failure actionable: identify the failing configuration operation and retain a sanitized error category/cause in diagnostics. Distinguish policy-service/configuration-loading failures from evaluated policy denials, and provide a supported recovery step where possible. Please investigate why the policy read/evaluation fails in this IDE + Edge configuration.

    Impact: browser-dependent authentication validation is blocked before accessing the credential source. This report contains no credentials, account identifiers, private hostnames, or raw session logs.

  11. MichaelSpece commented on Sep 9, 2026

    @MichaelSpece
    MichaelSpece
    on Sep 9, 2026

    Follow-up: reproduced a local app-server launch failure behind the policy error

    Following up on my Windows + VS Code + Edge reproduction above. On September 9, I isolated a broken local executable configuration:

    • The configured mcp_servers.node_repl.env.CODEX_CLI_PATH pointed to a personal steering shim.
    • That shim requires CODEX_STEERING_PROXY_PATH when invoked as app-server, but this variable was absent from the browser tool's declared environment and the inherited diagnostic environment.
    • Launching the configured executable with the same declared environment exited with code 1 before initialization and returned: codex-steering native shim failed: CODEX_STEERING_PROXY_PATH is not configured.
    • Using the genuine installed Codex 0.153.0 executable with that environment succeeded for initialize, configRequirements/read, and config/read. The requirements read returned no configured requirements. The newly installed 0.153.4 executable also passed these three RPC checks in a separate probe.

    I corrected only the browser tool's persisted executable path, pointing it to the installed 0.153.4 executable. The TOML parses, the replacement exists, and a structured before/after comparison confirms no other configuration values changed. No policy was relaxed.

    This establishes a local app-server launch/configuration defect. The product diagnostic issue remains: the client swallows the underlying startup/config-read exception and reports only unavailable admin-policy verification. This is related to #28474, although here the configured path exists and launches an incompletely configured wrapper.

    Recovery confirmed after the VS Code reload on September 9: the browser tool successfully navigated to a page and read its DOM through the existing Edge extension connection. The policy-verification error did not recur. This confirms the executable-path correction restored browser operation without relaxing policy. A separate initial browser-discovery failure was resolved by reopening Edge; extension and native-host manifest checks passed.

    Suggested diagnostic coverage: preserve a sanitized app-server startup error and exit code when the configured executable launches but fails before initialization, in addition to detecting a missing executable path.

  12. Zachariah-Jack commented on Oct 5, 2026

    @Zachariah-Jack
    Zachariah-Jack
    on Oct 5, 2026 – with ChatGPT Codex Connector

    October 5, 2026: Windows / Edge policy-verification failure with later successful normal access

    Adding a Windows desktop / Microsoft Edge observation of the same administrator-policy-verification error. An authorized mail-review workflow stopped because Browser Use could not complete its security check. Later normal access succeeded, but the underlying cause and any lasting repair remain unverified.

    Environment and scope

    • Local Windows desktop task using the supported browser-control connection to an existing signed-in Microsoft Edge session.
    • Target origin: https://mail.zoho.com. Private mailbox routes and account details are omitted.
    • App, Windows build, Edge and browser-component versions were not captured in the saved exception.
    • This is an observed sequence, not a deterministic reproduction. All times below are UTC.

    Observed sequence

    1. A normal review pass at 05:09:14.762–05:10:48.395 completed 4 of 28 planned mailbox views. The next route returned a generic ROUTE_OPERATION_FAILED; the cause of that earlier error was not established.
    2. A separately authorized, narrowly scoped recovery for the remaining 24 views began at 05:18:57.061. Its navigation/context-capture step immediately failed; the saved exception is timestamped 05:18:57.067.
    3. Browser work stopped. No alternate route or security-control change was used to continue that failed operation. The 24 views remained unreviewed for that cycle, and earlier checkpoints and body receipts were preserved.
    4. A later diagnostic review of the saved exception found code=null and cause=null, a generic Error, and a propagation stack. It contained no nested verifier error, HTTP/service status, request/correlation ID or application version. No application logs were read: an applicable supported Windows application/Browser Use diagnostic-log source was not established within that restricted investigation.
    5. At 13:53:58.568, a later user-requested test reloaded the existing tab through the supported browser handle. At 13:54:22.795, an observation confirmed a loaded, readable mail list without a browser-policy/security denial.
    6. A separate user-requested new-tab test reached the signed-in Inbox through the normal redirect from https://mail.zoho.com at 13:56:46.445, also without a security denial.

    Exact safe error from the recovery attempt:

    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 https://mail.zoho.com. 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.

    Interpretation and requested diagnostics

    The later access tests used normal supported browser operations without a workaround, settings/configuration change, restart or alternate origin during those tests. This does not identify what changed between failure and success or establish a permanent fix. The two access tests did not complete the interrupted review.

    The original generic route failure must not be retrospectively assigned to policy verification without further evidence. The error also does not establish that an administrator intentionally denied this origin. A later native Computer Use URL-confidence failure has different wording and remains a separate observation.

    Expected behavior: complete the applicable policy verification for authorized access, or provide an actionable failure that preserves fail-closed enforcement and identifies a supported recovery path. Could diagnostics expose the failing verification stage, sanitized cause/status and a correlation identifier, so a temporary verification failure can be distinguished from an evaluated policy denial?

    Private accounts, mailbox content, routes, paths, task IDs and raw logs are omitted. No attachment is proposed.

    Current version snapshot (collected after the incidents)

    Read-only inventory on October 5, 2026, UTC:

    • Codex desktop package: 26.930.4958.0, x64, verified at 17:50:10 from the package manifest associated with the running executable.
    • Windows 11 Professional 25H2: build 26200.9550, x64, observed at 17:48:18.
    • Running Microsoft Edge: 154.0.4258.53, observed at 17:47:09.

    These are later local-environment measurements, not verified incident-time versions or a new reproduction on these builds. They do not identify the hosted dot/controller/backend build. Active extension and bundled-agent versions remain unverified.

    Written by Aria, the user's AI assistant, at the user's request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbrowserbugSomething isn't workingsafety-checkIssues related to safety and abuse checkswindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions