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

Activity

1. marcelo-azevedo-br

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on May 8, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   browser

   on May 8, 2026
3. sdecima commented on May 8, 2026

   

   sdecima

   on May 8, 2026

   More actions

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

   Correlation id:
   b58004dd-0484-49d6-9ecf-abd4079a42c2
4. marcelo-azevedo-br commented on May 8, 2026

   

   marcelo-azevedo-br

   on May 8, 2026

   Author

   More actions

   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.
5. HppZ commented on May 9, 2026

   

   HppZ

   on May 9, 2026

   More actions

   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
6. william-kerr commented on May 25, 2026

   

   william-kerr

   on May 25, 2026

   More actions

   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.
7. centry4sangchu commented on May 28, 2026

   

   centry4sangchu

   on May 28, 2026

   More actions

   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.
8. Look001122 commented on Jun 14, 2026

   

   Look001122

   on Jun 14, 2026

   More actions

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

   😄React with 😄1Reacted by Look001122
9. kengoedv commented on Jul 15, 2026

   

   kengoedv

   on Jul 15, 2026 – with ChatGPT Codex Connector

   More actions

   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.
10. zemeng5208 commented on Aug 12, 2026

    

    zemeng5208

    on Aug 12, 2026 – with ChatGPT Codex Connector

    More actions

    I maintain WinBridge Recovery for Windows Codex Desktop local bridge diagnostics/recovery: https://github.com/zemeng5208/winbridge-recovery

    This thread is useful because it demonstrates why a recovery tool should not treat the bundled checker's English-text output as ground truth. On localized Windows, reg query /ve can label the default value differently ((padrão), localized equivalents), so “checker says registry key does not exist” is not necessarily the same state as “the HKCU key/value is actually absent.”

    WinBridge validates the Chrome Native Host as separate pieces — the actual user-level manifest, HKCU Chrome/Edge NativeMessagingHosts value, target executable path, plugin cache/latest and v2/runtime state — before deciding whether anything should be rewritten. That lets it distinguish a genuinely missing local bridge from an indeterminate/incorrect diagnostic result and avoids repairing a healthy registry entry just because a localized checker failed to parse it.

    There are also several different root causes mixed into this issue: missing COMSPEC, genuinely missing manifest/registry, WSL bridge limitations, and cases where the Native Host is fully connected but the Chrome backend is still not exposed. WinBridge only targets the local state inconsistencies; it does not claim to fix WSL native-pipe/tool injection or server/region/entitlement filtering when the local bridge is already healthy.

    It does not modify WindowsApps or bypass browser policy.