Windows Store Codex Browser Use only exposes IAB and blocks all network URLs with enterprise policy

Additional diagnostics after further testing:

• User manually opened and logged into Royal Road in the in-app browser.
• Browser Use can read basic tab metadata:
• itle: Dashboard | Royal Road
• url: https://www.royalroad.com/author-dashboard/dashboard/170109
• Browser Use still rejects all page-inspection/read capabilities with the same enterprise policy error:
• ab.playwright.domSnapshot() blocked
• ab.screenshot({ fullPage: false }) blocked
• ab.dev.logs({ limit: 5 }) blocked
• ab.capabilities.get(pageAssets) only returns the capability object; page read operations remain blocked.

Real codex doctor outside the sandbox reports:

• Auth configured and healthy
• Network sandbox enabled, provider endpoints reachable
• WebSocket connected
• Runtime current

Additional diagnostics after trying the Chrome/Edge extension workaround from #24814:

• Edge has the Codex extension installed: hehggadaopoacecdllhhajmbjkdcmajg, version 1.1.5. Chrome does not.
• Registering HKCU native messaging host for Microsoft Edge made the extension find the host.
• Extension local storage first showed: Specified native messaging host not found; after registering host it changed to repeated Native host has exited.
• Directly running codex.exe app-server proxy failed because the expected control socket did not exist: C:\Users\19099\.codex\app-server-control\app-server-control.sock with Windows error 10050.
• Manually starting codex.exe app-server --listen unix://C:/Users/19099/.codex/app-server-control/app-server-control.sock created the socket and the Edge extension status moved to connected.
• However Browser Use still listed only the in-app browser. Root cause for that layer appears to be that the running node_repl env exposed only BROWSER_USE_MARKETPLACE_NAME; it did not expose BROWSER_USE_AVAILABLE_BACKENDS.
• Codex config was reset back to BROWSER_USE_AVAILABLE_BACKENDS = "iab" and allowlist only marketplace after app restart. I changed it again to BROWSER_USE_AVAILABLE_BACKENDS = "iab,chrome" and NODE_REPL_UNTRUSTED_ENV_ALLOWLIST = "BROWSER_USE_MARKETPLACE_NAME,BROWSER_USE_AVAILABLE_BACKENDS", but this requires a fresh Codex/node_repl restart after the edit to verify.

So the current blocker is not RoyalRoad/login; it is Browser Use backend exposure / app-server/native host wiring on Windows Store Codex.

More diagnostics after a hard restart:

• Codex, Edge, node_repl, and the manual app-server were restarted.
• Edge native host status now reaches connected.
• Windows named pipes show two codex-browser-use-* pipes, but Browser client diagnostics show both are IAB-related, not extension-related.
• Patched diagnostic Browser client output:

{
  "backendCounts": { "cdp": 0, "extension": 0, "iab": 1 },
  "browserCount": 1,
  "candidatePipeCount": 2,
  "failures": [
    "backend-info-request/Browser session does not belong to this IAB pipe"
  ],
  "iabBrowserCount": 1,
  "pipeListingError": null,
  "pipeListingPipeCount": 2
}

So even with the Edge extension native host connected and the app-server socket manually started, no extension backend pipe is exposed/discovered. The only available backend remains the in-app browser, which still hits the enterprise network policy block.

Additional update after trying the Chrome-extension workaround from https://github.com/openai/codex/issues/24814#issuecomment-4568666681:

I followed the reinstall/restart direction and also found the official bundled chrome plugin in the Windows Store app resources. After copying/registering it locally and running the official Chrome plugin checks, Chrome-side setup now appears healthy:

• Chrome is installed and running.
• Codex Chrome Extension is installed and enabled in the selected Chrome profile (Default), extension ID hehggadaopoacecdllhhajmbjkdcmajg, version 1.1.5_1.
• Native messaging host manifest is correct:
• C:\Users\19099\AppData\Local\OpenAI\extension\com.openai.codexextension.json
• HKCU registry key points to the same manifest.
• allowed origin is chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/.
• Chrome extension/native-host connection status became connected and a new extension Browser Use pipe appeared.

However, Codex still generated the current session config/env with only:

BROWSER_USE_AVAILABLE_BACKENDS = "iab"
NODE_REPL_UNTRUSTED_ENV_ALLOWLIST = "BROWSER_USE_MARKETPLACE_NAME"

The local bundled marketplace exposed to Codex contained only browser and latex, not chrome, even though the Store app includes an official chrome plugin. After manually adding chrome@openai-bundled to local config/marketplace, the current Node/browser runtime still only saw the in-app browser until a full Codex reload.

Using a diagnostic client that forces listing extension backends, the Chrome extension backend is discoverable, but attempting to navigate https://example.com or https://www.royalroad.com/home still fails with the same policy error:

Browser Use cannot access ... because enterprise network policy blocks it.

So the extension reinstall/restart workaround gets the Chrome extension/native-host side working, but on this machine it does not resolve the Browser Use network policy block. This looks like either:

1. Codex is not enabling/publishing the bundled chrome plugin/backend in this app build/session, or
2. the enterprise network policy is being applied to Browser Use even when the Chrome extension backend is available.

Follow-up after a full Codex restart and installing the Chrome plugin as a personal/local plugin:

• Created default personal marketplace at C:\Users\19099\.agents\plugins\marketplace.json.
• Copied the official bundled Chrome plugin to C:\Users\19099\plugins\chrome.
• codex plugin marketplace list now recognizes personal.
• codex plugin add chrome@personal succeeds:
• installed plugin root: C:\Users\19099\.codex\plugins\cache\personal\chrome\26.519.81530
• After full Codex restart, codex plugin list shows:
• chrome@personal installed, enabled 26.519.81530
• browser@openai-bundled installed, enabled 26.519.81530
• Chrome extension pipe is present: \\.\pipe\codex-browser-use\...

But the generated runtime config still contains:

BROWSER_USE_AVAILABLE_BACKENDS = "iab"
BROWSER_USE_MARKETPLACE_NAME = "openai-bundled"
NODE_REPL_UNTRUSTED_ENV_ALLOWLIST = "BROWSER_USE_MARKETPLACE_NAME"

And both the normal browser client and the official installed chrome@personal browser client only list the in-app browser. Calling agent.browsers.get("extension") returns:

Browser is not available: extension

So even after installing Chrome as a real local/personal plugin and restarting, the current session/runtime is still being provisioned with only the in-app browser backend.

User-impact update:

This is a paid personal account, not a managed company/school workspace. The local token shows the account organization as Personal with role owner, and the user is physically using Codex from London/UK. The user also recently upgraded/paid for the service and expected browser/computer-use functionality to be available.

In the Codex app UI, the Computer use settings show Google Chrome as disabled with the message:

Disabled by your organization or unavailable in your region

That message is extremely confusing and frustrating for a personal paid account. If Chrome/Computer Use is intentionally unavailable for this account/region/build, the app should clearly say so and explain the remediation. If it is not intentional, this appears to be an entitlement/feature-flag/runtime provisioning bug.

Current observed state after restoring the browser plugin config:

• In-app browser plugin is installed/enabled and the small in-app browser window can open about:blank.
• Any external URL, e.g. https://example.com, is still blocked by Browser Use enterprise network policy.
• Chrome control is disabled in the UI before it can be used.
• Normal runtime still only exposes iab; extension is unavailable.

Please escalate or clarify whether this is expected for a paid personal account in the UK using the Microsoft Store Codex build.

This needs a maintainer clarification because this now looks like a silent availability/rollout change, not a local setup issue.

The user reports that browser/computer-use behavior previously worked or was expected to work, but after recent app updates / paid plan upgrade the UI now shows Google Chrome as:

Disabled by your organization or unavailable in your region

Local facts from this machine:

• Paid personal ChatGPT account, not a managed workplace/school org.
• Token metadata shows Personal org and role owner.
• Current IP geolocation: London, GB.
• Windows HomeLocation: United States; Culture/SystemLocale: en-US.
• Local Codex feature flags show computer_use, browser_use, browser_use_external, in_app_browser, and plugins all enabled.
• Chrome extension and native host are healthy and connected.
• Yet Codex Settings disables Google Chrome, and normal runtime exposes only iab.

I checked release notes and do not see a clear announcement saying that Windows / UK / EU paid users cannot use Chrome Computer Use. Related issues suggest this may be Statsig/feature-gating or bundled marketplace generation filtering out Chrome/computer-use despite the app bundle containing the plugin.

Please clarify explicitly:

1. Is Chrome/Computer Use intentionally unavailable on Windows right now?
2. Is it intentionally unavailable in the UK/Europe for paid personal accounts?
3. If this is expected, where is the official documentation/release note?
4. If this is not expected, can this be treated as a feature entitlement / rollout / bundled marketplace generation bug?

This is extremely user-visible: the app shows an organization/region disablement message to a paid personal account without explaining what to do.

Update after Microsoft Store Codex upgrade:

• Codex app upgraded from 26.519.11010.0 to 26.527.3686.0.
• Browser plugin upgraded to 26.527.31326.
• The official bundled marketplace still exposes only:
• browser@openai-bundled installed/enabled
• latex@openai-bundled not installed
• chrome@openai-bundled is still not present in the active bundled marketplace / plugin list.
• Config still shows BROWSER_USE_AVAILABLE_BACKENDS = "iab".
• Settings still show Google Chrome / Computer Use unavailable/disabled for the user.

So the latest Store update visible to this user did not resolve the Chrome/Computer Use availability problem on Windows.

Additional post-update note: immediately after the update, node_repl initially failed with windows sandbox failed: spawn setup refresh, requiring a clean Codex restart before continuing diagnostics.

Additional repro from another Windows Codex session: Browser Use blocked a normal public SaaS signup/login workflow, not just localhost or a test page.

Environment

• OS: Windows
• Codex app context: desktop app / in-app browser
• Browser plugin used by the session: browser@openai-bundled-beta / 26.519.81530
• Browser backend requested: Codex in-app browser (iab)
• Current visible in-app browser URL before the attempt: about:blank
• Target URL: https://trigger.dev/

User workflow that failed

The user wanted Codex to use the in-app browser to get access to Trigger.dev for a simple webhook automation setup. This is exactly the kind of workflow Browser Use is meant to handle: open a public SaaS site, help with signup/project setup, then continue with coding/configuration.

Action attempted

The agent initialized Browser Use, selected the in-app browser, made it visible, and attempted:

await tab.goto("https://trigger.dev/");

Actual result

Navigation was rejected before page load:

Browser Use rejected this action due to browser security policy. Reason: Browser Use cannot access https://trigger.dev because enterprise network policy blocks it. The agent must not attempt to achieve the same outcome via workaround, indirect execution, raw CDP or browser commands, alternate browser surfaces, or policy circumvention. Proceed only with a materially safer alternative that does not require this blocked browser action; if none exists, stop and request user input.

Expected result

Browser Use should be able to navigate to ordinary public SaaS sites such as https://trigger.dev/, especially when the user explicitly asks the agent to use the Browser plugin for account/project setup.

If this is intentionally blocked by account, region, organization, rollout, or product policy, the app should surface a clear user-facing explanation and remediation path. The current message says "enterprise network policy" even for a personal workflow against a public website, which makes the Browser plugin effectively unusable for normal web workflows.

Impact

This prevented Codex from helping a non-technical user set up Trigger.dev access for a webhook automation. The agent was also explicitly forbidden by the policy message from using fallback browser surfaces, so the work had to stop and be handed back to the user manually.