Chrome plugin fails after reinstall: browser-client is not trusted / native pipe bridge unavailable

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #23831
• #23414
• #22463
• #23222
• #22598

Powered by Codex Action

Adding another Windows reproduction/data point.

Environment / local state observed:

OS: Windows
Chrome: 148.0.7778.168
Chrome plugin path: C:\Users\16684\.codex\plugins\cache\openai-bundled\chrome\0.1.7
Codex Chrome Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
Codex Chrome Extension version: 1.1.5_0
Native host manifest: C:\Users\16684\AppData\Local\OpenAI\extension\com.openai.codexextension.json
Native host registry key: HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension

The local Chrome/extension/native-host setup appears healthy:

• Chrome is running.
• The Codex Chrome Extension is installed/enabled/registered.
• The native host manifest exists and points to the expected Codex extension host.
• The registry native host entry exists.
• extension-host processes are running.

But the active Codex thread does not appear to receive the trusted Chrome/browser runtime tool surface. In this thread, the available tools do not include Chrome/browser control APIs such as browser.user.openTabs(), browser.user.claimTab(...), node_repl, or equivalent browser-client execution tooling. Recent files under:

C:\Users\16684\.codex\cache\codex_apps_tools

also contain no chrome, browser, openTabs, claimTab, or node_repl entries.

Attempting to import the cached Chrome browser-client.mjs from a normal PowerShell/Node process fails with:

privileged native pipe bridge is not available; browser-client is not trusted

I understand that direct shell import is expected to be untrusted. The important part is that the current Codex session does not expose any trusted injected browser tool path to use instead, so the Chrome skill cannot reach the extension backend at all.

This matches the same class of issue described here: local Chrome extension/native host checks can pass, but the active Codex Desktop runtime/tool injection layer still does not provide the trusted native pipe/browser-client surface.

Adding another Windows data point for the same class of Codex Desktop browser/Computer Use plugin issue.

Environment observed:

OS: Windows
Codex Desktop package: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
Bundled plugin cache version observed locally: 26.527.31326
Plugins involved: browser@openai-bundled, chrome@openai-bundled, computer-use@openai-bundled

Symptoms seen before local workaround:

privileged native pipe bridge is not available; browser-client is not trusted
Computer Use native pipe is unavailable
Computer Use native pipe path is unavailable
browser@openai-bundled / chrome@openai-bundled can regress to not installed after restart
codex mcp get node_repl initially showed missing env entries needed by the runtime
plugin repair while Codex Desktop was running hit native file/cache locks
failed to copy plugin file: 无法加密指定的文件。 (os error 6000)

The important behavior is that official bundled plugins can appear installed/enabled, but the active Codex Desktop runtime does not consistently expose the trusted Browser/Chrome/Computer Use runtime surface after restart.

Local workaround that made the system usable:

• Ensure NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S exists under mcp_servers.node_repl.env.
• Ensure SKY_CUA_NATIVE_PIPE_DIRECTORY points to the current \\.\pipe\codex-computer-use-* pipe.
• Repair missing bundled plugin cache/manifest entries when Browser/Chrome disappear after restart.
• Keep a local watchdog that refreshes the Computer Use pipe path after Codex/Desktop restarts.

After the workaround, smoke tests could pass:

• Browser runtime listed both Chrome and Codex In-app Browser.
• Browser tabs listing succeeded.
• Computer Use listed desktop windows/apps.

Why this still seems like a product bug rather than normal configuration:

• These are official bundled plugins.
• A normal user should not need to maintain dynamic native pipe paths inside config.toml.
• config.toml ends up mixing stable settings, plugin enablement, project trust records, and session-specific pipe state.
• On restart, Codex Desktop and local repair/watchdog logic can both rewrite config.toml, making the state fragile.

Expected behavior:

• Browser/Chrome/Computer Use should recover after Codex Desktop restart without user scripts.
• The Desktop runtime should discover the active native pipe/backend itself.
• If plugin cache/manifest state is broken, Codex should expose a clear diagnostic and self-repair path.
• Dynamic runtime pipe IDs should not require user-managed persistent config edits.

I maintain WinBridge Recovery, an independent Windows Codex Desktop local recovery/diagnostic tool: https://github.com/zemeng5208/winbridge-recovery

There appear to be two layers mixed together in this thread, and WinBridge is only intended to repair the local one.

The local-repairable signals include bundled plugin cache/manifest entries disappearing after restart, Native Host state drifting, file/cache locks during repair, and the 无法加密指定的文件 (os error 6000) / Application Protected copy failure seen while trying to rematerialize official bundled plugin files. WinBridge v3.1.1 checks the current Store AppX resources against the generated marketplace, versioned Browser/Chrome/Computer Use caches, latest, CUA runtime, Node REPL paths, Native Host manifest/registry/v2 state, and uses verified staging + SHA-256 + rollback for user-owned recovery.

Its byte-stream copy path is relevant to the protected-file research in this failure family, but I still consider Application Protected/EFS handling experimental rather than a guaranteed fix across machines/Store versions. WinBridge does not decrypt, take ownership of, change ACLs on, or patch WindowsApps.

The second layer is different: if the local Chrome extension, Native Host, marketplace/cache/runtime and Node REPL configuration all validate but the current Codex thread still does not receive the trusted browser/node_repl tool surface, that is an upstream Desktop/tool-provisioning problem. WinBridge should report that boundary and stop rather than trying to manufacture a trusted pipe or bypass the host lifecycle.

I am reproducing this on Windows 11.

Codex desktop: 26.814.5167.0
Browser/Chrome plugin: 26.814.41407
Chrome extension: 1.2.27259.19709
Feedback/session ID: 019e8b6b-8172-79d1-8a26-e0e65a53c8d3
Approximate time: August 19, 2026, 12:30 AM Central

Exact error:
Trusted RPC dependency must resolve within a configured trusted code path:
file:///C:/Users/patri/.codex/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-service.mjs

The official checks all pass:

• Chrome is running.
• Extension is installed and enabled in the correct profile.
• Native-host manifest and registry registration are correct.
• Expected extension origins are present.

Attempted without success:

• Restarted Chrome and Codex.
• Removed/reinstalled the Chrome extension.
• Disabled/re-enabled the Chrome plugin.
• Codex reports "Failed to uninstall plugin" when removal is attempted.
• Windows App Repair.
• Full Codex uninstall/reinstall.
• Windows App Reset and reboot.
• Regenerated the Browser plugin cache.
• Reproduced in brand-new Codex tasks with fallbacks prohibited.
• The built-in Browser fails with the same service error.

Additional finding:
I changed NODE_REPL_TRUSTED_SERVICES to the bundled-marketplace
browser-service.mjs path. A fresh task did not pick it up until restart, and
Codex startup then automatically rewrote the registration back to the rejected
plugins/cache path. The exact error returned again.