You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I maintain WinBridge Recovery, an independent Windows recovery/diagnostic tool for Codex Desktop Browser / Chrome / Computer Use local state.
This symptom is in its core diagnostic scope: Chrome extension installed/enabled, Codex Desktop reinstalled, but the Chrome bridge still does not connect. A reinstall does not necessarily clear or reconcile the user-side plugin cache, latest targets, Native Host manifest/registry/v2 metadata, or local runtime/app-server paths.
One safety point: I would avoid continuing with broad takeown / icacls permission changes as a recovery strategy. WinBridge deliberately does not take ownership of WindowsApps, disable policy, or weaken ACLs. It compares the current official AppX package with the user-owned Browser/Chrome/Computer Use state and, where there is a stale/partial mismatch, rebuilds only the writable state with staging, SHA-256 verification, backup and rollback.
For Chrome specifically it checks the bundled marketplace/cache/version/latest, the Native Messaging manifest and HKCU registration, chrome-native-hosts-v2.json, and the runtime/app-server paths they reference. If all of those are healthy and the extension still cannot establish the Codex backend, that is useful evidence that the remaining failure is upstream rather than a permissions problem.
If anyone on this issue tests it, both success and failure reports help define the real boundary: zemeng5208/winbridge-recovery#4
Activity
github-actions commentedon Jun 18, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
gqiqiang750-spec commentedon Jun 26, 2026
您现在这个问题已经解决了吗
zemeng5208 commentedon Aug 16, 2026
I maintain WinBridge Recovery, an independent Windows recovery/diagnostic tool for Codex Desktop Browser / Chrome / Computer Use local state.
This symptom is in its core diagnostic scope: Chrome extension installed/enabled, Codex Desktop reinstalled, but the Chrome bridge still does not connect. A reinstall does not necessarily clear or reconcile the user-side plugin cache,
latesttargets, Native Host manifest/registry/v2 metadata, or local runtime/app-server paths.One safety point: I would avoid continuing with broad
takeown/icaclspermission changes as a recovery strategy. WinBridge deliberately does not take ownership ofWindowsApps, disable policy, or weaken ACLs. It compares the current official AppX package with the user-owned Browser/Chrome/Computer Use state and, where there is a stale/partial mismatch, rebuilds only the writable state with staging, SHA-256 verification, backup and rollback.For Chrome specifically it checks the bundled marketplace/cache/version/
latest, the Native Messaging manifest and HKCU registration,chrome-native-hosts-v2.json, and the runtime/app-server paths they reference. If all of those are healthy and the extension still cannot establish the Codex backend, that is useful evidence that the remaining failure is upstream rather than a permissions problem.If anyone on this issue tests it, both success and failure reports help define the real boundary: zemeng5208/winbridge-recovery#4