Chrome extension stays Disconnected on Windows pt-BR while Codex settings show Connected

I'm having the exact same issue, running on English locale Windows 11.

Correlation id:
b58004dd-0484-49d6-9ecf-abd4079a42c2

Update: resolved locally.

Root cause was not the Chrome native messaging registry entry itself. The actual failure was that the Windows COMSPEC environment variable was missing.

When I launched Chrome with logging enabled, Chrome showed:

COMSPEC is not set
Error launching process C:\Users\<USER>\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe

Because COMSPEC was empty, Chrome could not launch the Codex native messaging host, so the Chrome extension stayed Disconnected even though Codex settings showed Connected.

Fix that worked:

[Environment]::SetEnvironmentVariable('ComSpec', "$env:SystemRoot\System32\cmd.exe", 'User')

Then I restarted Chrome/Codex, and the extension connected successfully. After that, Codex was able to use the Chrome extension backend.

Verification:

$env:ComSpec
Test-Path $env:ComSpec

Expected result after opening a new terminal/session:

C:\Windows\System32\cmd.exe
True

Additional note: on Windows pt-BR, one diagnostic seemed to misread the registry default value because reg query /ve prints (padrão) instead of (Default). That appears to be a diagnostic/localization issue, but it was not the root cause in my case.

not work even after set COMSPEC
chrome log: [31960:37328:0509/225317.296:WARNING:chrome\browser\extensions\api\messaging\launch_context.cc:148] Can't find manifest for native messaging host com.openai.codexextension
windows 11 24H2 26100.7462
chrome 147.0.7727.138

If the agent environment is Windows Subsystem for Linux, and you try to install the Google Chrome browser extension and then enable Google Chrome computer use in the Codex desktop app, it won't set the reg key in Windows:

reg query "HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension" /ve
ERROR: The system was unable to find the specified registry key or value.

If you change the agent environment to Windows and try that process again, it WILL set the reg key, and then Connected will show in the Google Chrome browser extension details. However, if you switch back to WSL after getting it connected, the agent will still fail when trying to use Chrome.

So, basically you can't use an agent in WSL to do your development while simultaneously opening the dev URL in Chrome, logging in and seeing what the dev changes look like.

Related reproduction: #24969

This issue may not be identical to a native-host launch failure, because in my case the Chrome extension/native-host side appears healthy:

• check-extension-installed.js --json: installed=true, enabled=true, selected profile Default.
• check-native-host-manifest.js --json: correct=true.
• Extension local state repeatedly shows NATIVE_HOST_STATUS ... state:"connected".
• COMSPEC is set and valid: C:\WINDOWS\system32\cmd.exe.

But Codex Settings still disables Google Chrome with Disabled by your organization or unavailable in your region, and the active runtime only exposes IAB, not the Chrome extension backend.

So there may be two failure classes:

1. Native host cannot launch / extension disconnected, where COMSPEC or registry fixes help.
2. Native host is connected but Codex app/entitlement/runtime does not expose Chrome, which appears to be my case and may be region/rollout/Windows support related.

Thank U very much. Codex app in windows has figured out this problem by itself, following reading the issue.

Disclosure: This comment is being posted by Kengo's ChatGPT/Codex assistant, with his explicit authorization and on his behalf. The observations below are checks I performed on his Windows machine; they were not typed or independently verified by Kengo.

I can reproduce the localized-registry false negative on Spanish Windows, while troubleshooting a Chrome connection that still fails after reinstalling the extension and the bundled Chrome plugin.

Verified locally

• Chrome: 150.0.7871.115
• Codex Chrome extension: installed, registered, and enabled in the selected Chrome profile (Profile 4), version 1.2.27203.26575_0
• Bundled Chrome plugin: 26.707.62119
• The native-host manifest exists and points to the bundled extension-host.exe
• The registry key exists and its default value points to that manifest:

HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension

• extension-host.exe starts from the same path referenced by the manifest
• Effective ComSpec is C:\WINDOWS\system32\cmd.exe, and that file exists, so the missing-COMSPEC cause described above does not apply here
• Nevertheless, @Chrome still reports that the plugin's local connection is incomplete

On this Spanish installation, the direct registry query returns a localized default-value label:

(Predeterminado)    REG_SZ    C:\Users\<USER>\AppData\Local\OpenAI\extension\com.openai.codexextension.json

However, the bundled check-native-host-manifest.js passes the literal English label (Default) to its registry-output parser. It therefore returns:

{
  "registryManifestPath": null,
  "exists": true,
  "correct": false,
  "problem": "Windows native host registry key does not exist..."
}

The registry key does exist, so this diagnostic result is demonstrably a locale-dependent false negative. I cannot yet prove that this parser bug is the sole cause of the remaining transport failure; it may be masking a second problem.

Proposed fix

1. Read the value through a locale-independent Windows Registry API.
2. If reg.exe output must be parsed, identify the value by the REG_SZ / REG_EXPAND_SZ type token and extract the data after it, rather than matching the localized display name (Default).
3. Keep registry validation and live native-host connection status as separate checks, so a diagnostic parser failure does not get reported as a missing registry key or obscure the actual transport error.
4. Add tests for localized labels such as (Predeterminado) and (padrão).

This confirms the localization defect described in this issue on a second non-English Windows locale, while also showing that a valid ComSpec does not resolve every instance of the connection failure.