Windows Desktop: Chrome plugin unavailable in Norway/EU even though extension is connected

Summary

Codex Desktop on Windows does not expose the Chrome plugin / @Chrome route for a user in Norway, even after the Chrome extension is installed and shows Connected.

This may be related to a regional rollout/gating issue for EU/UK users, but the local evidence also points to Desktop feature/plugin filtering: the extension/native bridge works, while the Codex chat runtime only advertises the in-app browser backend (iab) and the Plugins UI cannot discover Chrome.

Related issues: #19251, #16808, #16783.

Environment

Region/location: Norway (Europe/Oslo), possible EU/UK availability concern reported by users on X
Platform: Windows
Codex Desktop package: OpenAI.Codex_26.506.2004.0_x64__2p2nqsd0c76g0
Desktop version shown in process logs: 26.506.20924
Embedded CLI/runtime: codex-cli 0.129.0-alpha.15
Model in use: gpt-5.5
Chrome extension version: 1.1.4
Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg

Expected behavior

The official docs say the Chrome extension is set up from Codex → Plugins → Add Chrome plugin. After setup and a new thread, @Chrome should be invokable and Codex should be able to use the user’s Chrome profile.

Docs: https://developers.openai.com/codex/app/chrome-extension

Actual behavior

Codex Desktop → Plugins search for Chrome shows no Chrome plugin / no matching result.
The “Built by OpenAI” selector cannot be cleared; it is the only selected marketplace source.
Manually installed Chrome extension shows Connected.
Clicking the gear in the Chrome extension opens Codex settings, so the extension can deep-link back into Codex.
Starting a completely new Codex chat still leaves @chrome list my open tabs as plain text, with no plugin/mention route.
Browser runtime exposed to the turn only lists the in-app browser backend:

{
  "x-codex-browser-use-available-backends": ["iab"]
}

Attempting to acquire the Chrome extension backend fails:

Browser is not available: extension

Local diagnostics

codex features list reports the relevant features as enabled:

browser_use              stable true
browser_use_external     stable true
computer_use             stable true
in_app_browser           stable true
plugins                  stable true

The packaged Windows app contains the Chrome plugin and marketplace entry:

%ProgramFiles%\WindowsApps\OpenAI.Codex_26.506.2004.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled\plugins\chrome

But Desktop session logs repeatedly show the runtime bundled marketplace being written without Chrome:

bundled_plugins_runtime_marketplace_written pluginCount=2 pluginNames=["browser-use","latex-tectonic"] targetMarketplaceRoot=%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled

Then Chrome is uninstalled/removed from the bundled plugin set:

bundled_plugin_uninstall_requested pluginId=chrome@openai-bundled pluginName=chrome reason=not_in_bundled_marketplace_plugin_names

The Chrome native host is registered and points at a valid host manifest:

HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension
%LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json

The manifest points to the installed extension host executable under the local Codex plugin marketplace.

Why this looks like a Codex Desktop gating/availability bug

The extension side is installed and connected.
The native host registration exists.
The packaged app contains the Chrome plugin.
The runtime says browser_use_external is enabled.
But Desktop only advertises iab to the chat turn and filters Chrome out of the bundled marketplace cache.

If Chrome is intentionally not available yet in EU/UK/EEA accounts, the app/docs should state that clearly. If it is supposed to be available, Desktop should not hide/remove the Chrome plugin while the extension shows Connected.

Repro steps

Use Codex Desktop on Windows from Norway / Europe.
Open Plugins and search for Chrome.
Observe no Chrome plugin result.
Install/load the Codex Chrome extension manually; confirm Chrome popup shows Connected.
Start a new Codex chat.
Type @chrome list my open tabs.
Observe no @Chrome mention/plugin route is available.
Inspect available browser backends for the turn; only iab is present.

Requested fix / clarification

Please clarify whether the Chrome plugin is region-gated for EU/UK/EEA users. If not, please fix Codex Desktop so the Chrome plugin is discoverable/enabled and the chat runtime advertises the Chrome/extension backend when the extension is connected.

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

Computer Use does not appear in Settings despite plugin and helper existing #21579
Intel macOS: Computer Use unavailable because computer-use bundled plugin is missing #19932

Powered by Codex Action

Additional context: this increasingly looks like a regional availability / rollout communication issue, not a local install failure.

Public corroboration:

A third-party Codex writeup states that the Codex Computer Use plugin was not officially opened in the UK and Europe, with the visible symptom being Computer Use plugin unavailable: https://ecwuuuuu.com/post/enable-codex-computer-use-plugin-outside-us/
A Reddit thread reports the same class of issue from Europe: Codex Computer Use not available in Europe?: https://www.reddit.com/r/codex/comments/1sp9jug/codex_computer_use_not_available_in_europe/
Another Reddit discussion says Computer Use is not available in EU without workarounds: https://www.reddit.com/r/codex/comments/1sz1ozr/what_are_you_actually_using_computer_use_in_codex_for/

For this Windows/Norway user, the confusing part is that the Chrome extension itself can show Connected, while Codex Desktop still does not expose the Chrome/extension backend to chats and the Plugins UI gives no clear regional-availability explanation.

If EU/UK/EEA users are intentionally excluded for now, the Desktop UI and official docs should say that explicitly instead of leading users through plugin/extension setup that cannot complete in-region.

Same issue here in Albania — Chrome extension not available.

Same here from Germany on macOS.

Specs: Codex App 26.506.21252 (2575), codex-cli 0.128.0, macOS 15.7.5 (24G624), arm64

Chrome does not appear in the Plugins tab/search, and my local plugin cache does not include a chrome plugin entry.

I’m seeing the same issue on Windows. The Chrome extension is installed, enabled, and shows Connected, but Codex cannot acquire the Chrome backend.

Environment:

OS: Windows 11 Version 23H2, Build 22631.6199
Chrome: 139.0.7207.2, 64-bit
Chrome executable: C:\Users\Ke_yo\AppData\Local\Google\Chrome\Application\chrome.exe
Chrome profile: C:\Users\Ke_yo\AppData\Local\Google\Chrome\User Data\Profile 5
Codex Chrome extension version: 1.1.4
Extension ID: hehggadaopoacecdllhhajmbjkdcmajg

Local checks:

The Codex Chrome extension is visible in chrome://extensions, enabled, and has the expected ID:
hehggadaopoacecdllhhajmbjkdcmajg
The extension popup shows Connected.
Native Messaging host registry exists from my normal PowerShell session:

HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension
(Default) REG_SZ C:\Users\Ke_yo\AppData\Local\OpenAI\extension\com.openai.codexextension.json
The manifest exists:
C:\Users\Ke_yo\AppData\Local\OpenAI\extension\com.openai.codexextension.json
The manifest points to:
C:\Users\Ke_yo.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe

Observed Codex runtime behavior:

The turn metadata includes both browser backends:

x-codex-browser-use-available-backends = ["chrome", "iab"]
But agent.browsers.list() only returns the in-app browser:

Codex In-app Browser / type: iab
Trying either backend ID fails:

agent.browsers.get("chrome")
=> Browser is not available: chrome

agent.browsers.get("extension")
=> Browser is not available: extension

Additional note:

Codex shell commands appear to run under a sandbox user:

whoami = yonghongke\codexsandboxoffline

while my interactive PowerShell is my normal desktop user. This may explain why Codex-side registry checks don’t see the same HKCU values, but Chrome itself is running under my normal user and the extension shows Connected.

This looks like the Chrome feature is allowed for the turn (chrome appears in available backends), but the actual Chrome extension backend is not discovered/registered as a browser. It does not look like a wrong Chrome profile or missing extension issue.

Yup, same here (Baltics). No Chrome or Computer Use plugin available.

They could just at least say that it is not available and done deal. Wouldn't spend hour of trying to find what's wrong

same in egypt. how do i manually install it?

Same in México, please, fix this.

Similar issue

Windows 10
Codex Desktop
Chrome Extension 1.1.4
Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
native host check-native-host-manifest.js: correct true
check-extension-installed.js: installed/registered/enabled true
extension-host.exe running
Chrome popup shows Connected
browser-client.mjs imports successfully
setupAtlasRuntime({ globals }) times out

where did you guys got the extension from? I can't even find that. I'm the UK.

Same in Italy.
No Luck. The really wrong thing is to receive advertising from Openai for a service that you cannot use!

thanks Tomodovodoo it works

…

On Mon, May 11, 2026 at 1:22 PM Tom ***@***.***> wrote: *Tomodovodoo* left a comment (openai/codex#21598) <#21598 (comment)> I have a workaround, which might be of interest! https://x.com/Tomodovodoo/status/2053781991397429742 — Reply to this email directly, view it on GitHub <#21598 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAFJB2Y7UJGS4XG33MWKHT42GSWXAVCNFSM6AAAAACYVHJYU2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DIMJZGY4TSMRSGM> . You are receiving this because you commented.Message ID: ***@***.***>

For a weird reason this worked for me "Install and activate the computer use plugin"
Or "Install and activate the chrome use plugin" He did it.

Adding another reproduction from a Windows Codex Desktop session.

Observed behavior:

The user invoked [@Chrome](plugin://chrome@openai-bundled) in a thread.
The assistant runtime did not receive chrome@openai-bundled as an active/callable plugin.
The available plugin/tool surface only exposed the bundled in-app Browser (browser-use / IAB-style local browser capability), not the external Chrome plugin.
As a result, the assistant responded that the Chrome plugin was not available and could not use the user's Chrome session.

This matches the class of failures described here: the UI/thread can reference Chrome, but the actual model/runtime tool list does not include the Chrome plugin. I do not have evidence from this session that the Chrome extension or native host is misconfigured; the failure is at the Codex runtime/plugin exposure level.

No official workaround confirmed in this session. Related workarounds mentioned above (VPN before opening Codex, asking Codex to install/activate the Chrome or Computer Use plugin, fully closing Chrome/extension-host before restarting Codex) appear user-reported and not guaranteed.

I’m seeing a very similar issue on Windows + WSL2 with the current Codex desktop app.

Environment / local state:

Codex app package: OpenAI.Codex_26.513.4821.0_x64__2p2nqsd0c76g0
Codex model/session: GPT-5.5 in Codex Desktop, local workspace running through WSL2
~/.codex/config.toml has [plugins."chrome@openai-bundled"] enabled = true
Chrome extension is installed and enabled in the Windows Chrome Default profile:
- extension ID: hehggadaopoacecdllhhajmbjkdcmajg
- version: 1.1.4_0
Native Messaging Host registry/manifest exists:
- HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension
- manifest path: C:\Users\takara\AppData\Local\OpenAI\extension\com.openai.codexextension.json
- manifest points to C:\Users\takara\AppData\Local\OpenAI\extension\codex-chrome-host\windows\x64\extension-host.exe
extension-host.exe is running.
Windows named pipes are present:
- chrome.nativeMessaging.in.*
- chrome.nativeMessaging.out.*
- codex-browser-use\...
- codex-ipc

Observed behavior:

The Chrome extension / native host side appears healthy.
However, in the Codex session, @chrome does not expose any Chrome/browser automation tools.
Tool discovery only exposes unrelated app tools such as Canva/Acrobat/Photoshop, not Chrome openTabs/claimTab/extension browser backend functionality.
This is after restarting Codex and Chrome.

This looks like the same class of issue described here: Chrome integration is installed/connected locally, but the Desktop chat runtime does not advertise or route the Chrome extension backend into the turn. In my case the problem does not look like a missing extension, missing manifest, or dead native host; it looks like plugin/backend routing or feature gating in the Codex Desktop runtime.

I’m seeing what looks like the same availability/gating issue from Portugal/EU on Windows.

Environment:

Region/location: Portugal / EU
Platform: Windows
Codex Desktop package: OpenAI.Codex_26.513.4821.0_x64__2p2nqsd0c76g0
Chrome: 148.0.7778.178
Bundled Chrome plugin present locally: chrome 0.1.7
Codex Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg

User-visible behavior:

Chrome plugin does not appear normally in Codex Plugins.
Attempting to accept a plugin install prompt from Codex showed: Could not load this plugin right now.
Opening the documented Chrome Web Store URL for the extension shows the Chrome Web Store page in Portuguese with: Este item não está disponível.
As a result, the extension cannot be installed through the supported flow.

Local diagnostics:

The installed Windows app package contains the Chrome plugin under the bundled OpenAI marketplace resources.
On Codex startup, the generated runtime bundled marketplace still filters Chrome out and only exposes Browser and LaTeX:

bundled_plugins_runtime_marketplace_written pluginCount=2 pluginNames=["browser","latex"] targetMarketplaceRoot=%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled
bundled_plugins_marketplace_added marketplaceName=openai-bundled marketplacePluginNames=["browser","latex"]

Logs also show repeated feature sync failures for auth_elicitation:

unsupported feature enablement `auth_elicitation`: currently supported features are apps, memories, mentions_v2, plugins, remote_control, tool_search, tool_suggest, tool_call_mcp_elicitation

Chrome is installed and running, but because the extension is unavailable in the Chrome Web Store, the extension/native host checks remain missing:

check-extension-installed.js --json: installed=false, registered=false, enabled=false
check-native-host-manifest.js --json: registry key missing; native host manifest missing

This looks like the same EU/Windows rollout or feature-gating problem described here, plus the Web Store listing itself is not available for this user/account/region.

Same issue in Malta, installs with a VPN but doesn't work properly. Many actions fail to trigger.

Same issue in the Netherlands😢 I guess we will need to wait for official support. Is there an ETA when it is expected?

Adding another closely matching reproduction / cross-reference: #24969

Observed on Windows Microsoft Store Codex 26.519.11010.0, paid personal account, current IP London/GB:

Codex Settings → Computer use shows Google Chrome disabled with: Disabled by your organization or unavailable in your region.
Account metadata is personal (Personal org, role owner), not a managed workplace/school org.
Local feature flags report computer_use, browser_use_external, browser_use, in_app_browser, and plugins enabled.
Chrome extension and native host checks pass; extension local state shows connected.
Normal runtime still exposes only Codex In-app Browser / iab; extension is unavailable.
In-app browser can open about:blank, but all network URLs fail with enterprise network policy.

This strongly resembles a rollout/region/backend-provisioning issue rather than a user install problem. Please clarify whether Windows and/or UK/EU paid personal accounts are intentionally excluded, since I cannot find a release note or docs page explaining this disablement.

Would also like to know about the ETA

Adding another closely matching reproduction from a German-language Codex/Chrome setup.

Observed behavior:

Codex Settings -> Computer Use lists Google Chrome but the toggle is disabled.
The disabled reason shown in the UI is: Von deiner Organisation deaktiviert oder in deiner Region nicht verfügbar (Disabled by your organization or unavailable in your region).
The Chrome extension had previously been installed and showed connected, but after uninstalling it the documented Chrome Web Store URL is no longer installable.
Direct URL tested: https://chromewebstore.google.com/detail/codex/hehggadaopoacecdllhhajmbjkdcmajg
Chrome Web Store redirects to /detail/hehggadaopoacecdllhhajmbjkdcmajg/error and shows: Dieser Artikel ist nicht verfügbar (This item is not available).
In the active Codex session, tool/plugin discovery does not expose a callable Chrome/browser-extension backend, only the non-Chrome local/tool surfaces available to the session.

This matches the pattern reported above: the local Chrome state can appear connected at one point, but the Codex Desktop runtime and/or Web Store availability still prevents Chrome Computer Use from being usable. The UI currently leaves users unable to tell whether this is intentional regional gating, a rollout flag mismatch, or a broken plugin provisioning path.

Correction: this report was initially posted here before the failure boundary was fully isolated. It is not another instance of the general plugin/region availability problem tracked by this issue. The exact bug concerns existing Codex Desktop conversations failing to acquire Chrome-tab visibility and control when reopened in the ChatGPT Chrome side panel. That distinct report is now tracked in #37309. Please use #37309 for this reproduction.

Clarification on my previous comment: after narrowing the reproduction, this is not the same primary failure as this issue's general plugin/region availability problem. It specifically affects existing Codex Desktop conversations when they are reopened in the ChatGPT Chrome extension side panel: tab metadata transfers, but the resumed thread does not acquire tab visibility/control. I filed the exact thread-origin/resume bug separately as #37309.

thanks everyone for the detailed reports here

on june 16, computer use and the codex chrome extension rolled out to users in the eea, uk, and switzerland: release notes

Navigation Menu

Repository navigation

Windows Desktop: Chrome plugin unavailable in Norway/EU even though extension is connected #21598

Summary

Environment

Expected behavior

Actual behavior

Local diagnostics

Why this looks like a Codex Desktop gating/availability bug

Repro steps

Requested fix / clarification

6 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Windows Desktop: Chrome plugin unavailable in Norway/EU even though extension is connected #21598

Description

Summary

Environment

Expected behavior

Actual behavior

Local diagnostics

Why this looks like a Codex Desktop gating/availability bug

Repro steps

Requested fix / clarification

Activity

github-actions commented on May 7, 2026

EirikViking commented on May 7, 2026

arditlleshi commented on May 8, 2026

morganschp commented on May 8, 2026

btnd99-stack commented on May 8, 2026

xmasterg commented on May 9, 2026

sharabash commented on May 9, 2026

memowii commented on May 9, 2026

bingohu commented on May 10, 2026

ovidb commented on May 10, 2026

6 remaining items

dreinn commented on May 12, 2026

sharabash commented on May 12, 2026

memowii commented on May 14, 2026

Culacco commented on May 14, 2026

takara-tb commented on May 18, 2026

tpereira2005 commented on May 20, 2026

lukaspechar commented on May 20, 2026

Rednas83 commented on May 27, 2026

centry4sangchu commented on May 28, 2026

diogovalada commented on Jun 1, 2026

simfor99 commented on Jun 1, 2026

NathanR-85 commented on Aug 6, 2026

NathanR-85 commented on Aug 6, 2026

chess-oai commented on Aug 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions