Repository navigation
[Windows] Chrome plugin fails: browser-client not trusted and Native Host registration missing #53246
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.1007.2314.0
What subscription do you have?
ChatGPT Plus
What platform is your computer?
10.0.26300.0 x64
What issue are you seeing?
Summary
On Windows, the Codex App Chrome plugin is installed and enabled, but browser initialization consistently fails with:
privileged native pipe bridge is not available; browser-client is not trusted
The failure occurs before Chrome tabs can be retrieved.
The bundled Chrome Native Messaging Host executable exists, but its manifest and registry registration are missing.
Reinstalling the Chrome plugin from the Codex plugin UI does not resolve the issue.
Environment
- OS: Windows x64
- Codex App Windows package: 26.1007.2314.0
- Internal app version reported in config: 26.1007.21434
- Chrome plugin version: 26.616.32156
- Browser plugin version: 26.616.32156
- Subscription: ChatGPT Plus
Steps to Reproduce
- Open the Codex Windows App.
- Enable the bundled Chrome plugin.
- Start a new Codex session.
- Ask Codex to list open Chrome tabs using the official Chrome plugin.
- The Node REPL loads
browser-client.mjsand attempts to initialize it. - Initialization fails before any Chrome tab information is retrieved.
Actual Behavior
The following error is consistently reproduced:
privileged native pipe bridge is not available; browser-client is not trusted
The official Native Host diagnostic reports:
{
"registryManifestPath": null,
"exists": false,
"correct": false,
"problem": "Windows native host registry key does not exist; Native host manifest does not exist"
}Both the expected HKCU and HKLM Native Messaging Host registry keys are absent.
The expected manifest file is also missing:
%LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json
Additional Diagnostics
node_repl.exeexists and multiple Node REPL processes are running.extension-host.exeexists in the bundled Chrome plugin directory.- The Chrome plugin's
latestjunction correctly points to version 26.616.32156. - Both bundled
browser-client.mjsfiles have the same SHA-256 hash. NODE_REPL_TRUSTED_SERVICESis configured with the browser service.- The Chrome plugin remains installed and enabled.
- A fresh Codex session reproduces the failure.
- Chrome installation detection returned
installed_browsers: [], but this result alone does not establish that Chrome is missing. - The Chrome running state could not be verified because the diagnostic
tasklistcommand failed.
Troubleshooting Already Attempted
- Reinstalled the Chrome plugin through the Codex plugin UI.
- Verified bundled plugin files and junction targets.
- Verified Node REPL executable and running processes.
- Ran the official Native Host manifest checker.
- Tested browser initialization in a new Codex session.
The issue persists.
No manual registry changes, configuration modifications, or unsupported Native Host installation attempts were performed.
Expected Behavior
The Codex Chrome plugin installation should correctly register its Native Messaging Host.
The official browser client should be trusted by the Codex runtime and receive access to the privileged Native Pipe Bridge, allowing Chrome tab enumeration and browser interaction.
Request
Please investigate:
- Why the bundled Chrome plugin installation does not create the Native Host manifest and HKCU registry registration.
- Why the official
browser-client.mjsis not trusted by the Node REPL runtime. - Whether the Native Host installation failure and privileged Native Pipe Bridge failure share a common root cause.
- Whether a supported repair procedure or application update can resolve the issue.
Related reports: #28950 and #21781.
What steps can reproduce the bug?
- Launch the Codex Windows App (package version 26.1007.2314.0).
- Verify that the bundled Chrome plugin is installed, enabled, and displayed as managed.
- Open a new Codex session.
- Ask Codex to list the currently open Chrome tabs using the Chrome plugin.
- Codex attempts to initialize the official
browser-client.mjsthrough Node REPL. - Initialization fails with the following error:
privileged native pipe bridge is not available; browser-client is not trusted
- The Chrome tab list cannot be retrieved.
Reproducibility: Consistently reproducible, including in new Codex sessions.
Troubleshooting already performed:
- Reinstalled the Chrome plugin from the Codex plugin UI.
- Verified that the bundled plugin files exist.
- Verified that
node_repl.exeis running. - Confirmed the same initialization error after reinstalling the plugin.
The issue persists.
What is the expected behavior?
The Codex Windows App should successfully initialize the official Chrome browser client through Node REPL.
The bundled Chrome plugin should automatically install and register its Native Messaging Host, including the required manifest file and Windows registry entry.
The browser client should be recognized as trusted and have access to the privileged Native Pipe Bridge.
Codex should then be able to retrieve open Chrome tabs and perform supported browser interactions without initialization errors.
Additional information
Environment
- Windows x64
- Codex App package: 26.1007.2314.0
- Internal app version reported in config: 26.1007.21434
- Chrome plugin: 26.616.32156
- Browser plugin: 26.616.32156
- ChatGPT Plus
Native Host diagnostics
The official check-native-host-manifest.js --json reports:
"registryManifestPath": null
"exists": false
"correct": false
Missing registry key:
HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension
The equivalent HKLM key is also absent.
Missing manifest file:
%LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json
Plugin and runtime checks
- Bundled
extension-host.exeexists. - Bundled
installManifest.mjsexists. - Chrome plugin
latestjunction correctly targets version 26.616.32156. - Both bundled
browser-client.mjsfiles have identical SHA-256 hashes. - Multiple
node_repl.exeprocesses are running. NODE_REPL_TRUSTED_SERVICEScontains a browser-service entry.NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256Swas not found in the inspected configuration.- Chrome installation detection returned
installed_browsers: [], but Chrome installation status remains unconfirmed by that diagnostic.
The bundled troubleshooting documentation explicitly advises against manually installing or repairing the Native Host.
No unsupported manual repair or registry modification was performed.
Investigation requested
Please investigate whether the missing Native Host registration and the privileged Native Pipe Bridge trust failure originate from the same Windows Codex App initialization problem.
Activity
github-actions commentedon Oct 12, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
vtohoho commentedon Oct 12, 2026
Additional finding: v2 runtime catalogues exist but contain zero entries
Following the automated duplicate detection referencing #52939, I checked both v2 runtime catalogue files on my Windows installation.
Both files exist:
%LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json%USERPROFILE%\.codex\chrome-native-hosts-v2.jsonBoth files have identical results:
Unlike #52939, the v2 runtime catalogue files are present, but neither contains any registered runtime entries.
Additionally, the ordinary Chrome Native Messaging Host manifest and HKCU registration remain missing.
The browser-client initialization still fails with:
This suggests that the native host/runtime provisioning lifecycle may not be completing successfully.
The relationship between the empty v2 catalogues and the browser-client trust failure has not yet been established.
All checks were read-only. No manual repair or configuration modification was performed.
Please investigate whether the empty v2 catalogues, missing Native Messaging registration, and privileged Native Pipe Bridge failure are related.
0xdevalias commentedon Oct 26, 2026
The current macOS investigation distinguishes trusted-service bootstrap, Native Messaging registration/executable reachability, and v2 side-panel registration. detailed investigation may help localize these layers, but it does not repair the absent Windows manifest/registry or empty v2 catalogues documented here.
Related investigations and reports
Grouped by diagnostic boundary; these links do not imply a shared root cause or that every report is fixed.
browser-client is not trusteddespite extension and native host checks passing #27186