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

[marcelo-azevedo-br]

What version of the Codex App are you using (From “About Codex” dialog)?

26.506.21252

What subscription do you have?

PRO

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

The Codex Chrome extension remains Disconnected in Chrome, even though the Codex settings page shows Google Chrome as Connected.

Uploaded feedback correlation ID:

7bb8f0ba-bbf8-4ccd-9c45-8ca8b27383c5

Symptoms:

• Codex settings show Google Chrome as Connected.
• The Chrome extension popup shows Disconnected.
• Codex cannot use Chrome-backed browser tasks.
• A Chrome-backed task fails with: Browser is not available: extension.
• agent.browsers.list() only returns Codex In-app Browser; the Chrome extension backend is not listed.
• No extension-host.exe process appears to be running while the extension is disconnected.

This seems inconsistent: the Codex app settings report the Chrome integration as connected, but the Chrome extension itself and Codex runtime both behave as disconnected.

What steps can reproduce the bug?

1. Use Codex App on Windows with Brazilian Portuguese locale.
2. Install or enable the Google Chrome plugin from Codex settings.
3. Install the Codex Chrome extension in Chrome.
4. Open Codex settings > Computer use > Google Chrome.
5. Observe that Codex settings show Google Chrome as Connected.
6. Click the Codex Chrome extension icon in Chrome.
7. Observe that the extension popup shows Disconnected.
8. Try to run a Chrome-backed browser task from Codex.

Result:

Browser is not available: extension

Also, listing available browser backends from Codex only shows:

Codex In-app Browser

The Chrome extension backend is missing.

Troubleshooting already tried:

• Removed and reinstalled the Chrome extension.
• Restarted the PC.
• Confirmed the extension appears installed and enabled in the Chrome Default profile.
• Confirmed the native host manifest exists and points to extension-host.exe.

What is the expected behavior?

If Codex settings show Google Chrome as Connected, the Chrome extension should also show connected and the Chrome extension browser backend should be available to Codex.

Codex should be able to open and control Chrome tabs through the Chrome extension.

Additional information

Possible localization issue:

On Windows pt-BR, reg query ... /ve displays the default registry value label as (padrão). The Codex native host diagnostic appears to look for (Default) literally and reports:

Windows native host registry key does not exist

However, the registry key does exist and points to the native host manifest.

This may be only a diagnostic bug, but it could be related if the Chrome native host connection flow depends on parsing localized reg query output.

[sdecima]

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

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

[marcelo-azevedo-br]

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.

[HppZ]

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