Skip to content

Chrome connection fails: Unable to load browser request-header policy #45678

Open
Open
Chrome connection fails: Unable to load browser request-header policy#45678
Labels
appIssues related to the Codex desktop appbrowserbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

Description

@ilnur1976uno-beep
ilnur1976uno-beep
opened on Sep 15, 2026

Chrome browser connection consistently fails in multiple Codex chats.

Exact error:
Unable to load browser request-header policy. Retry the browser command.

Environment:

  • Windows
  • ChatGPT Chrome extension version: 1.26.901.11451
  • Extension is installed and enabled
  • Side chat opens successfully
  • Settings → Computer Use shows Google Chrome as installed with “Manage”
  • Chrome is absent from the @-mention menu

Already tried:

  • Restarting Chrome
  • Restarting the desktop app
  • Restarting the computer
  • Testing in a new chat
  • Reinstall option opens Chrome Web Store with “This item is unavailable”

Feedback ID:
01a0a4a0-7953-7151-b5f8-2d07f6f54683

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    browser
    on Sep 15, 2026

  2. github-actions commented on Sep 15, 2026

    @github-actions
    github-actionsBot
    on Sep 15, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. wxywy commented on Sep 25, 2026

    @wxywy
    wxywy
    on Sep 25, 2026 – with ChatGPT Codex Connector

    Additional Windows / Chrome reproduction

    Feedback ID: 01a04685-703d-7fc3-85b6-94800e8743b8

    This is another reproduction of the same failure. The useful new evidence is a same-machine comparison between the external Chrome connector and the Codex in-app browser, plus an exported chrome://policy review.

    Environment

    • Windows 11 25H2, build 26200.9457
    • Google Chrome 153.0.8010.53
    • Codex Desktop 26.917.71314, build 10954 (up_to_date when checked)
    • Browser/Computer Use component 26.917.71314
    • ChatGPT Chrome extension 1.26.901.11451_0
    • Extension installed and enabled in the Chrome Default profile
    • Native Messaging host diagnostic: correct: true

    External Chrome result

    A minimal request to open https://example.com in Chrome failed before a tab could be created or read. The operation took about 21 seconds and returned:

    Unable to load browser request-header policy. Retry the browser command.

    The same result persisted after extension reconnects, Chrome/Codex restarts, and updating Codex Desktop.

    In-app browser comparison

    On the same machine and network, the Codex in-app browser opened https://example.com in about 4.3 seconds and exposed the expected accessibility content:

    Title: Example Domain
Heading: Example Domain
Link: Learn more

    This narrows the failure to the external-browser request-header-policy / extension path rather than general Codex network access.

    chrome://policy export review

    The exported policy JSON contains no Policy errors field or error records. Its browser user status reports:

    {"error": false, "status": "policy cache healthy"}

    Extension-install policy arrays and per-extension policy records are empty. The only Chrome policy names present are:

    ChromeDataRegionSetting
GenAiDefaultSettings
MandatoryExtensionsForIncognitoNavigation
UserSecurityAuthenticatedReporting
UserSecuritySignalsReporting

    No policy shown in the export directly blocks the ChatGPT extension or request headers.

    Redacted transcript excerpt

    The source session is over 60 MB and includes unrelated private work, so the complete raw JSONL is not suitable for a public issue. The following entries are extracted from the matching session and redacted to remove local usernames/paths, account identifiers, business URLs, ad data, authentication material, screenshots, and unrelated conversation text.

    2026-09-24 21:01:10 +08:00  Chrome extension diagnostic
  browserFamily: chrome
  installed: true
  enabled: true
  selectedProfileDirectory: Default
  extensionVersion: 1.26.901.11451_0

2026-09-24 21:09:19 +08:00  Codex update check
  installedVersion: 26.917.71314
  build: 10954
  status: up_to_date

2026-09-24 21:09:46 +08:00  External Chrome minimal test
  requested URL: https://example.com
  elapsed: approximately 21 seconds
  result: Unable to load browser request-header policy. Retry the browser command.
  tab created: no

2026-09-24 21:11:10 +08:00  chrome://policy export
  policy error records: none present
  user policy status error: false
  extension policies: none

2026-09-24 21:15:14 +08:00  Codex in-app browser control test
  requested URL: https://example.com
  elapsed: 4.3154 seconds
  result: success
  visible title/heading: Example Domain

2026-09-25 latest retest  External Chrome
  result: Unable to load browser request-header policy. Retry the browser command.

    No matching transcript was found under ~/.codex/archived_sessions; the matching source was under ~/.codex/sessions.

    Expected behavior

    When the extension and native host are healthy, Codex should initialize the request-header policy and create/read the authorized Chrome tab. If the policy service is unavailable, the error should expose the underlying cause and a retry should perform a fresh initialization attempt.

    Privacy note

    Only the diagnostic excerpt above is being shared. No cookies, tokens, account IDs, browsing history, private page content, advertising data, or user-specific filesystem paths are included.

  4. uzbekistanian1986-creator commented on Oct 2, 2026

    @uzbekistanian1986-creator
    uzbekistanian1986-creator
    on Oct 2, 2026 – with ChatGPT Codex Connector

    Additional macOS observation with the same error message; this does not establish a shared root cause.

    On 2026-10-02, Chrome profile Ozod through supported CUA repeatedly failed at getState with 'Unable to load browser request-header policy' and 'Timed out waiting for Statsig values'. The Mac is connected and unlocked; local code execution works. Browser QA cannot start. No private task data, secrets or source exports are needed.

    Failing review task: task01a0fabf-6d01-7430-b550-8b8d66674054.

    Separate observation: A separate cloud Chrome test of a synthetic local app failed with ERR_BLOCKED_BY_CLIENT. This is an observation, not a confirmed common cause of the supported CUA failure.

    No diagnostics, logs, screenshots, credentials, or source exports are attached.

  5. ltuswwnnwnw-blip commented on Oct 5, 2026

    @ltuswwnnwnw-blip
    ltuswwnnwnw-blip
    on Oct 5, 2026

    Adding a Windows reproduction from a current build:

    • Codex Desktop/AppX: 26.930.3930.0
    • Browser plugin package: 26.930.31730 (bundled Statsig JS SDK 3.33.1)
    • After restarting Codex, one read-only attempt to bind an existing Chrome tab at 2026-10-05 01:54:38 -04 returned: Unable to load browser request-header policy. Retry the browser command.

    This reproduces the same user-visible error, but I could not capture the SDK initialization result, readiness state, authenticated HTTP status, or correlation ID. Could a maintainer confirm whether runtime diagnostics are available for this build to identify the policy fetch/initialization result? I have no evidence that this reproduction shares the response-size or Brotli cause suggested in other reports.

  6. veerthetiguy commented on Oct 8, 2026

    @veerthetiguy
    veerthetiguy
    on Oct 8, 2026 – with ChatGPT Codex Connector

    Additional reproducible Windows desktop evidence, submitted at the affected user's request.

    Environment: Codex desktop release 26.1002.52244 (app logs); Windows Store package 26.1002.7124.0 verified from the running executable; bundled CLI 0.162.0-alpha.2; cua_node runtime 3dd31cfff853001c. Observed October 7 evening Pacific / October 8 UTC.

    Chrome reproduction

    1. Open Chrome with the existing browser extension connected.
    2. Supported browser discovery detects Chrome with the extension backend.
    3. Request a new Chrome tab at an authenticated YouTube Studio dashboard through cua.createBrowserTab('chrome', ...).
    4. Both the initial attempt and one instructed retry fail:
    Unable to load browser request-header policy. Retry the browser command.

    Chrome is detected in this case; merely opening/reconnecting it does not resolve the policy-loading failure.

    Additional observations (not asserted to share one cause)

    • In-app browser navigation times out; binding an existing tab times out at CDP Emulation.setFocusEmulationEnabled.
    • A supported browser-session reset and a fresh tab did not resolve those timeouts.
    • App logs around 2026-10-08T06:31Z repeatedly report No ChatGPT browser route is available for browser session <session-id>.
    • Opening the browser panel through the supported app tool returned queued. Navigating to the owning chat returned navigated:true, but subsequent Chrome navigation and browser inventory each timed out after 30 seconds and reset the JavaScript kernel.
    • Updating/restarting the app was verified; these symptoms persisted on the newer package.
    • A separate forced-workspace sandbox diagnostic also reproduces the bundled runtime sharing violation reported in Windows 26.1002.52244: sandbox ACL refresh fails on running node_repl.exe (error 32), blocking browser and shell #51965. That standalone probe is not proof of the browser's execution mode or of a common root cause.

    Expected: detected Chrome should be controllable after policy initialization, and the owning chat's browser route should be recoverable without repeated restarts.

    This blocks an authorized browser workflow before any upload or website mutation. No policy bypass, security relaxation, or runtime binary patch was applied. Personal paths, site/channel identifiers, session IDs, credentials, and full transcripts are omitted. Please advise on a supported recovery path or fix.

  7. mustafakarademir1011-design commented on Oct 11, 2026

    @mustafakarademir1011-design
    mustafakarademir1011-design
    on Oct 11, 2026 – with ChatGPT Codex Connector

    Reproduced on Windows in Codex desktop on 2026-10-11 with the Chrome extension provider.

    • Browser inventory detected Chrome, and selecting it returned the browser API documentation.
    • browser.tabs.list(), browser.tabs.new(), and browser.user.openTabs() each failed before any tab content or navigation was available with: Unable to load browser request-header policy. Retry the browser command.
    • After reinstalling the Chrome extension, Codex detected a new extension instance, but the same commands still failed with the same error.

    Expected: Codex can list/open and control Chrome tabs. The underlying cause is not confirmed. No logs, session content, or private browser data are attached.

  8. Louie-vibecoding commented on Oct 13, 2026

    @Louie-vibecoding
    Louie-vibecoding
    on Oct 13, 2026

    Additional Windows/Chrome reproduction, verified 2026-10-13.

    Environment:

    • Codex app updater: version 26.1007.21434, build 13901, prod, up_to_date.
    • Running Windows package: OpenAI.Codex 26.1007.2314.0.
    • Bundled CLI: 0.162.0-alpha.17.2.
    • Chrome extension: 1.26.901.11451, Default profile, installed and enabled.

    Observed:

    • Supported cua.getState discovers the Chrome extension but reports:
      Unable to load browser request-header policy. Retry the browser command.
    • Reproduced in a fresh CUA kernel under the currently running app process, which started at 2026-10-13 10:23 +08:00.
    • The earlier daily run failed at nameSession on the initial attempt and two bounded retries, before any target page was accessed.
    • Chrome running check, extension check, and native-host manifest check all pass.
    • Current updater reports up_to_date.
    • The in-app browser rendered a local diagnostic report earlier the same day; this does not verify external Chrome.

    Narrow evidence:

    • The installed browser-service throws this exact error when the Statsig readiness result is unsuccessful/missing or loadingStatus is not Ready.
    • Re-reading the policy awaits the existing initialization/readiness state; it does not itself force a new initialization.
    • The app log separately records "Timed out while fetching post-login Statsig bootstrap" at 2026-10-13T02:25:10.758Z, attemptNumber=6, in an avatarOverlay renderer. This is corroborating evidence only: that renderer uses /wham/statsig/bootstrap and is not proven to be the same failing browser request.
    • Credential-free HTTPS probes through the existing local proxy reached ab.chatgpt.com and chatgpt.com in less than 0.5 seconds, both HTTP403. This proves TCP/TLS/edge reachability only, not authenticated initialize success.
    • No underlying authenticated Statsig HTTP status, response-byte count, or SDK failure details are exposed in the inspected diagnostics.

    Please provide a supported diagnostic or fixed build that preserves the actual initialization error, response size/encoding and timing, and distinguishes request failure from cached unsuccessful readiness. Related timeout/size/Brotli reports are hypotheses for this installation, not confirmed causes.

    No browser-service patch, policy relaxation, credential extraction, or alternate browser workaround was applied. This report contains no account identifiers, private site content, local usernames/paths, raw transcripts, cookies or tokens.

  9. TouchFishPrince commented on Oct 13, 2026

    @TouchFishPrince
    TouchFishPrince
    on Oct 13, 2026 – with ChatGPT Codex Connector

    Additional macOS / Chrome reproduction with narrow diagnostics, verified 2026-10-13. The affected user authorized publishing this redacted report.

    Environment

    • Desktop updater: ChatGPT/Codex 26.1007.30912, build 20156, prod; status up_to_date.
    • macOS 26.6.2 (25G83), arm64.
    • Google Chrome 155.0.8059.40.
    • Supported browser discovery identifies Chrome with the extension backend. The extension version was not independently recorded.

    Reproduction and observed impact

    1. With an existing Chrome tab open, cua.listBrowsers() returns Chrome as an extension provider.
    2. Bind that existing tab with cua.getTab({url: "<redacted target URL>"}, {browser: "<detected Chrome ID>"}), or list tabs using cua.listTabs({browser: "<detected Chrome ID>"}).
    3. Both fail with:
    Unable to load browser request-header policy. Retry the browser command.
    1. Reproduced across several user-requested, bounded reconnection cycles. Individual observed failures took approximately 10–28 seconds. No target form writes or submission occurred.
    2. A later supported cua_repl.js_reset completed. The first tab-binding attempt after that reset instead failed with nodeRepl.fetch request failed (about 4.8 seconds). The reset did not restore browser access; the second error is not asserted to have the same root cause.

    Local evidence and limits

    • Read-only inspection of the installed browser-service implementation found that the exact policy error is raised when awaited Statsig readiness is unsuccessful or its loading status is not Ready, before reading codex_browser_use_agent_request_header.
    • The extension request path checks this prerequisite before sending the actual session request to Chrome. This is consistent with browser discovery succeeding while tab access fails.
    • The associated policy service base is https://ab.chatgpt.com/v1. A credential-free HEAD request to the public root domain reached HTTPS and returned HTTP 403 in about 2 seconds. This proves only root-domain TCP/TLS/edge reachability, not success of the policy initialization request.
    • Narrow searches of the relevant desktop logs did not expose the underlying browser-policy initialization exception, HTTP status, response details, or correlation ID.
    • User configuration has the browser/computer-use plugins enabled; no explicit browser-disabling feature entry was present in the inspected user config. This is not a claim that every effective policy source was inspected.
    • No browser-service patch, feature-gate override, security-policy relaxation, proxy alteration, credential extraction, extension reinstall, or whole-browser shutdown was performed. The desktop app was not fully restarted during this diagnostic run.

    Request

    Please provide a supported recovery path or fix, and preserve the actual initialization failure reason in diagnostics (timeout vs transport/HTTP vs response decoding vs readiness state). Repeatedly instructing the user to retry currently yields the same aggregate message without an actionable cause.

    This comment adds a current macOS reproduction to the existing report rather than opening a duplicate issue. No private website URLs, account identifiers, local usernames, cookies, tokens, screenshots, task materials, or full session transcripts are included.

  10. 970lab commented on Oct 13, 2026

    @970lab
    970lab
    on Oct 13, 2026

    Also reproducing the same error on macOS, not only Windows.

    Environment verified locally on 2026-10-13:

    • macOS 27.0.1 (26A434)
    • ChatGPT desktop app, bundle com.openai.codex, version 26.1007.30912 (20156)
    • Chrome extension browser is discovered; the user confirms the extension is connected.

    Minimal reproduction:

    1. Select the discovered Chrome browser using cua.getBrowser.
    2. Call browser.tabs.list().
    3. After approximately 10–20 seconds, the tool returns:
      Unable to load browser request-header policy. Retry the browser command.

    A discovery attempt also returned Timed out waiting for Statsig values.

    Expected: tabs can be listed and authorized browser work can proceed.
    Actual: browser control fails before a target website can be inspected. Repeated attempts across turns and resetting/reinitializing the CUA session did not resolve it. Native accessibility reads worked separately. This does not establish an extension disconnection or a failure of the target websites.

    No policies were disabled or bypassed. Root cause remains unknown: possibly the desktop control runtime or its configuration-service connectivity. App restart completion was not independently verified and is not claimed as a tested fix.

    No screenshot is attached: the agent's computer-use tool explicitly refuses to access the desktop app itself. The exact errors above were transcribed from tool responses; no simulated screenshot was created. Account identifiers, cookies, credentials, private task content and session logs are excluded.

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