Windows Chrome plugin: native host launches but extension backend is not registered

Summary

On Windows, the Codex Chrome plugin appears to be installed correctly and Chrome launches the native messaging host, but Codex Desktop never exposes the Chrome extension browser backend.

agent.browsers.list() returns only the Codex in-app browser (type: "iab"), and agent.browsers.get("extension") fails with:

Browser is not available: extension

This looks similar to #24838 and #22264. There may also be a related non-English Windows diagnostic issue similar to #21741.

Environment

• OS: Windows, Korean locale
• Codex Desktop: OpenAI.Codex 26.609.3341.0 from Microsoft Store/AppX
• Chrome plugin cache: openai-bundled/chrome/26.609.30741
• Chrome: 142.0.7444.163
• Codex Chrome Extension: 1.1.5_0
• Selected Chrome profile: Default

Reproduction steps

1. Install/reinstall the Chrome plugin from the Codex plugin UI.
2. Install/enable the Codex Chrome Extension in Chrome's Default profile.
3. Restart Chrome and Codex Desktop.
4. Start a Codex thread and use the Chrome plugin, or run the Chrome backend bootstrap:

const { setupBrowserRuntime } = await import("file:///.../scripts/browser-client.mjs");
await setupBrowserRuntime({ globals: globalThis });
await agent.browsers.list();
await agent.browsers.get("extension");

Expected behavior

Codex should list a Chrome extension browser backend and agent.browsers.get("extension") should return a controllable Chrome browser session, allowing calls such as browser.user.openTabs().

Actual behavior

agent.browsers.list() only returns the in-app browser:

[
  {
    "name": "Codex In-app Browser",
    "type": "iab",
    "metadata": {
      "codexAppBuildFlavor": "prod",
      "codexIabTabMode": "singleTab"
    }
  }
]

Then:

await agent.browsers.get("extension")

fails with:

Browser is not available: extension

Diagnostics

The standard Chrome setup checks pass:

chrome-is-running.js --check
status: ok
Google Chrome running: yes

installed-browsers.js --check
status: ok
Google Chrome 142.0.7444.163

{
  "extensionId": "hehggadaopoacecdllhhajmbjkdcmajg",
  "selectedProfileDirectory": "Default",
  "installed": true,
  "enabled": true,
  "versions": ["1.1.5_0"]
}

{
  "manifestPath": "C:\\Users\\<user>\\AppData\\Local\\OpenAI\\extension\\com.openai.codexextension.json",
  "registryKey": "HKCU\\Software\\Google\\Chrome\\NativeMessagingHosts\\com.openai.codexextension",
  "registryManifestPath": "C:\\Users\\<user>\\AppData\\Local\\OpenAI\\extension\\com.openai.codexextension.json",
  "expectedHostName": "com.openai.codexextension",
  "actualHostName": "com.openai.codexextension",
  "expectedExtensionId": "hehggadaopoacecdllhhajmbjkdcmajg",
  "expectedOrigin": "chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/",
  "allowedOrigins": ["chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/"],
  "exists": true,
  "nameMatches": true,
  "hasExpectedOrigin": true,
  "registryMatchesManifestPath": true,
  "correct": true,
  "problem": null
}

Chrome also starts the native messaging host:

cmd.exe /d /s /c ""C:\Users\<user>\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe" chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/ --parent-window=0" < \\.\pipe\chrome.nativeMessaging.in... > \\.\pipe\chrome.nativeMessaging.out...

extension-host.exe "C:\Users\<user>\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe" chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/ --parent-window=0

The manifest points to an existing host binary:

{
  "name": "com.openai.codexextension",
  "type": "stdio",
  "path": "C:\\Users\\<user>\\.codex\\plugins\\cache\\openai-bundled\\chrome\\latest\\extension-host\\windows\\x64\\extension-host.exe",
  "allowed_origins": ["chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/"]
}

Extra note: localized Windows registry output

On this Korean Windows machine, one diagnostic path previously appeared to misread the default registry value from reg query /ve because the localized default value name is not always parsed as (Default) in the Node REPL child process. Direct PowerShell and direct node scripts/check-native-host-manifest.js --json runs now report the native host manifest as correct, so this may be a separate diagnostics bug. The main issue persists even when the official native host check passes and extension-host.exe is running.

Current workaround

No workaround found for controlling the user's existing Chrome tabs through @chrome. The in-app browser still works, and Playwright can be used separately for new-browser automation, but neither replaces access to the existing Chrome profile/tabs.