Windows: check-native-host-manifest.js falsely reports a missing Native Messaging registry key on non-English Windows (parses localized `reg query` output)

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

26.901.5280.0

What subscription do you have?

20x

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

On a non-English Windows installation (zh-CN display language), the bundled diagnostic
scripts/check-native-host-manifest.js reports

"correct": false,
"problem": "Windows native host registry key does not exist: HKCU\\Software\\Google\\Chrome\\NativeMessagingHosts\\com.openai.codexextension"

even though the registry key does exist and holds the correct value. The failure comes from
the script parsing the localized text output of reg.exe.

This is a false negative, not a connectivity problem — Chrome reads the registry through the
Win32 API and connects fine. But the diagnostic is the tool users are pointed at when the Chrome
extension misbehaves, so it actively sends non-English users chasing a problem that does not exist.

Environment

• Codex Desktop: 26.901.5280.0 (MSIX package OpenAI.Codex_26.901.5280.0_x64__2p2nqsd0c76g0)
• chrome@openai-bundled plugin: 26.901.41600
• ChatGPT Chrome extension: 1.26.901.11451 (hehggadaopoacecdllhhajmbjkdcmajg)
• Chrome: <152.0.7977.82（正式版本） （64 位）>
• OS: <Microsoft Windows 版本 25H2 (OS 內部版本 26200.9168) >, display language zh-CN

Actual vs expected

reg query confirms the key is present and correct:

> reg query "HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension" /ve
HKEY_CURRENT_USER\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension
    (默认)    REG_SZ    C:\Users\<user>\AppData\Local\OpenAI\extension\com.openai.codexextension.json

The manifest at that path is well-formed and points at an extension-host.exe that exists.

The checker nevertheless returns:

{
  "browserFamily": "chrome",
  "manifestPath": "C:\\Users\\<user>\\AppData\\Local\\OpenAI\\extension\\com.openai.codexextension.json",
  "registryKey": "HKCU\\Software\\Google\\Chrome\\NativeMessagingHosts\\com.openai.codexextension",
  "registryManifestPath": null,
  "exists": true,
  "correct": false,
  "problem": "Windows native host registry key does not exist: HKCU\\Software\\Google\\Chrome\\NativeMessagingHosts\\com.openai.codexextension"
}

Expected: "correct": true.

Root cause

scripts/check-native-host-manifest.js shells out to reg.exe and matches the value name against
the hard-coded English string "(Default)":

function readWindowsRegistryDefaultValue(registryKey) {
  let output;
  try {
    output = execFileSync("reg", ["query", registryKey, "/ve"], {
      encoding: "utf8",
      stdio: ["ignore", "pipe", "ignore"],
    });
  } catch {
    return null;
  }

  return readRegistryValue(output, "(Default)");
}

function readRegistryValue(output, valueName) {
  for (const line of output.split(/\r?\n/)) {
    const match = line.match(/^\s*(.*?)\s+REG_\w+\s+(.+?)\s*$/);
    if (match && match[1] === valueName) return stripRegistryString(match[2]);
  }

  return null;
}

On zh-CN, reg.exe prints (默认), so match[1] === "(Default)" is false and the function
returns null. getNativeHostManifestLocation() then sets registryKeyExists: false, and
getNativeHostManifestLocationProblem() reports the key as missing.

Two compounding defects here:

1. Localized value name. (Default) is translated in every non-English Windows UI language.
2. Encoding. reg.exe writes in the console OEM code page (CP936 for zh-CN), but the output is
   decoded with encoding: "utf8", so the value name is mojibake before the comparison even runs.
   A simple translation table would therefore not be enough.

A further consequence: because getNativeHostManifestStatus() returns early once
locationProblem is set, the manifest's name and allowed_origins are never validated on
these systems — the diagnostic silently skips the checks it exists to perform.

Reproduction

1. Use a Windows installation whose display language is not English (zh-CN reproduces reliably).
2. Install Codex Desktop and the chrome@openai-bundled plugin so that
   %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json and the
   HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension key are both created.
3. Confirm both exist (reg query ... /ve, Test-Path ...).
4. Run:

   node "%USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\latest\scripts\check-native-host-manifest.js" --browser chrome --json

5. Observe "correct": false with the "registry key does not exist" problem.

Suggested fix

Don't parse localized text. Options, roughly in order of robustness:

1. Query through PowerShell, whose default-value property name is locale-independent:

   powershell -NoProfile -NonInteractive -Command
     "(Get-ItemProperty -LiteralPath 'HKCU:\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension').'(default)'"

2. Stop matching the value name. reg query <key> /ve returns only the default value, so the
   single REG_* line can be accepted regardless of how its name is spelled:

   function readRegistryDefaultValue(output) {
     for (const line of output.split(/\r?\n/)) {
       const match = line.match(/\s+REG_\w+\s+(.+?)\s*$/);
       if (match) return stripRegistryString(match[1]);
     }
     return null;
   }

This is a minimal change, but still needs the encoding fixed (capture as a Buffer and decode with
the active OEM code page, or invoke chcp 65001 first).

Independently of which fix is chosen, it would help to not short-circuit the manifest content
validation when only the registry probe fails — report the two conditions separately so a
registry-read failure doesn't mask (or fabricate) a manifest problem.

Workaround for affected users

Verify the key with a locale-independent read:

Get-ItemPropertyValue "HKCU:\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension" -Name "(default)"

and validate the manifest content by bypassing the registry branch with the documented override:

$env:CODEX_CHROMIUM_NATIVE_HOST_MANIFEST_PATH = "$env:LOCALAPPDATA\OpenAI\extension\com.openai.codexextension.json"
node "$env:USERPROFILE\.codex\plugins\cache\openai-bundled\chrome\latest\scripts\check-native-host-manifest.js" --browser chrome --json

What steps can reproduce the bug?

1. Use a Windows machine whose display language is not English (zh-CN reproduces reliably).

2. Install Codex Desktop and the chrome@openai-bundled plugin, so that both of these exist:

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

3. Confirm the registry key is present and correct:
   reg query "HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension" /ve
   On zh-CN the value name prints as "(默认)" rather than "(Default)".

4. Run the bundled diagnostic:
   node "%USERPROFILE%.codex\plugins\cache\openai-bundled\chrome\latest\scripts\check-native-host-manifest.js" --browser chrome --json

5. It returns "correct": false with
   "problem": "Windows native host registry key does not exist: ..."
   even though step 3 proved the key exists.

What is the expected behavior?

No response

Additional information

No response

Start with scripts/check-native-host-manifest.js, especially readWindowsRegistryDefaultValue, readRegistryValue, and getNativeHostManifestStatus. Run the provided non-English Windows reproduction command and inspect how reg.exe output is decoded and parsed. Done means the existing registry key is recognized regardless of Windows locale, and manifest content validation is not skipped because of the registry probe.