Windows Chrome plugin install leaves Native Messaging Host missing while extension is enabled
Summary
On Windows, the Codex Chrome plugin appears installed in Codex and the Codex Chrome Extension is installed/enabled in Chrome, but the Native Messaging Host is not created. As a result, Codex cannot communicate with Chrome. Reinstalling the Chrome plugin from Codex and reinstalling Codex Desktop did not restore the native host.
Environment
- OS: Windows
- Codex Desktop plugin: Chrome /
control-chrome - Chrome plugin cache version observed:
26.623.101652 - Chrome extension ID:
hehggadaopoacecdllhhajmbjkdcmajg - Chrome extension version observed:
1.1.5_0 - Chrome profile:
Default
What works
The Chrome extension check reports installed and enabled:
{
"extensionId": "hehggadaopoacecdllhhajmbjkdcmajg",
"selectedProfileDirectory": "Default",
"installed": true,
"enabled": true,
"profiles": [
{
"profileDirectory": "Default",
"installed": true,
"registered": true,
"enabled": true,
"disabled": false,
"versions": ["1.1.5_0"],
"selected": true
}
],
"exitCode": 0
}
What fails
The native host check reports missing registry and manifest:
{
"manifestPath": "C:\\Users\\Administrator\\AppData\\Local\\OpenAI\\extension\\com.openai.codexextension.json",
"registryKey": "HKCU\\Software\\Google\\Chrome\\NativeMessagingHosts\\com.openai.codexextension",
"registryManifestPath": null,
"expectedHostName": "com.openai.codexextension",
"expectedExtensionId": "hehggadaopoacecdllhhajmbjkdcmajg",
"expectedOrigin": "chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/",
"exists": false,
"correct": false,
"problem": "Windows native host registry key does not exist: HKCU\\Software\\Google\\Chrome\\NativeMessagingHosts\\com.openai.codexextension; Native host manifest does not exist: C:\\Users\\Administrator\\AppData\\Local\\OpenAI\\extension\\com.openai.codexextension.json"
}
When trying to use the Chrome plugin from Codex, browser setup / lightweight tab listing fails or times out, and one attempt returned:
Packaged browser documentation directory is missing.
Reproduction / actions attempted
- Installed Chrome plugin from Codex plugin UI.
- Confirmed Codex Chrome Extension exists and is enabled in Chrome.
- Tried uninstalling/reinstalling the Chrome plugin from Codex UI; uninstall showed a Chinese toast equivalent to "plugin uninstall failed".
- Fully exited Codex and Chrome.
- Reopened Codex as administrator and reinstalled the Chrome plugin.
- Reinstalled Codex Desktop.
- Re-ran the extension and native host checks.
The extension remains installed/enabled, but the native host manifest and registry key are still absent.
Expected behavior
Installing or repairing the Codex Chrome plugin should create:
C:\\Users\\Administrator\\AppData\\Local\\OpenAI\\extension\\com.openai.codexextension.jsonHKCU\\Software\\Google\\Chrome\\NativeMessagingHosts\\com.openai.codexextension
Then check-native-host-manifest.js --json should return correct: true, and Codex should be able to list/open Chrome tabs.
Actual behavior
Codex reports/behaves as if the Chrome plugin is installed, but Chrome control is unusable because the Native Messaging Host is missing. Reinstalling the plugin and Codex Desktop does not recreate it.
Impact
The user cannot use the Codex Chrome plugin for logged-in browser workflows such as searching Xiaohongshu from an existing Chrome session.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Disclosure: I maintain WinBridge Recovery, an independent Windows recovery/diagnostic utility for Codex Desktop.
This is a particularly clean match for one of the states the project checks: the Chrome extension is installed/enabled and the bundled plugin cache exists, but the Windows Native Messaging Host layer is absent (
com.openai.codexextensionmanifest + HKCU registration).WinBridge Recovery resolves the currently installed official Codex package and current Chrome plugin version, validates
chrome/latest, the extension-host executable,chrome-native-hosts-v2.json, the Native Messaging manifest, and the registry registration, and can rebuild inconsistent user-side registration state with backup/rollback support.I’m mentioning it as a temporary recovery option, not an upstream fix. It does not modify WindowsApps, change package ownership, or bypass Chrome/enterprise policy. If the manifest/registry pair is genuinely the missing layer in this report, this is within the project’s intended recovery scope; if tool injection still fails after the host is healthy, that would be a separate Desktop/runtime issue.