Codex Desktop dependencies fail to install; browser and computer-use plugins unavailable

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

• #27238
• #27633
• #28317
• #27152

Powered by Codex Action

After clearing AppData/Roaming and AppData/Local/OpenAI/Codex, the browser and computer-use plugins briefly reappeared. After closing and reopening Codex Desktop, they became unavailable again.

On disk, browser and chrome are present in version 26.611.62324, but computer-use remains at 26.527.31326. The config.toml notify entry still points to the old computer-use 26.527.31326 path. The AppData Local OpenAI Codex runtime folder is recreated, but the plugin availability does not persist after restart.

Thanks for the duplicate suggestions. I reviewed #27238, #27633, #28317, and #27152.

This issue is clearly related, especially to #27238, #27633, and #27152, but I am not sure it is an exact duplicate.

Additional detail from my case:

• Browser, Chrome, and Computer Use were previously available and working.
• The issue appeared later as a regression, not since first install.
• Clearing/renaming .codex, AppData\Roaming\Codex, and AppData\Local\OpenAI\Codex temporarily made the plugins reappear.
• After closing and reopening Codex Desktop, the plugins became unavailable again.
• On disk, browser/chrome had newer bundled versions, while computer-use appeared to remain on an older bundled version.
• Workspace dependencies still showed as not installed / failed to reinstall.

So this may share the same root cause as the linked issues, but the temporary recovery followed by failure after restart may be useful additional evidence. I will leave this open unless maintainers prefer to consolidate it under one specific issue.

I performed a full local reset:

• renamed .codex
• renamed AppData\Roaming\Codex
• renamed AppData\Local\OpenAI\Codex
• used Windows Settings > Codex > Reset

After signing in again, the browser/computer-use plugins are still unavailable. This suggests the issue is not caused by the usual local Codex profile/cache folders.

I tested with a brand new Windows user profile on the same machine, same Codex version, and same ChatGPT account. In that fresh Windows profile, the browser and computer-use plugins appear correctly. This strongly suggests the issue is specific to my original Windows user profile, not the Codex installation globally or my account.

Computer Use still reports an internal @oai/sky export missing error in the fresh profile, but the plugins themselves are visible and the in-app browser works.

I found the root cause on my Windows profile.

The issue was caused by a stale/corrupted native extension state in:

C:\Users\<Windows username with an accented character>\AppData\Local\OpenAI\extension

The corrupted manifest contained mojibake in my Windows username path, e.g. the accented character in my username was stored as Fé instead of é.

Renaming the whole folder: extension.backup-20260618 then restarting Codex twice caused Codex to regenerate the extension state correctly. The in-app browser, Computer Use, and Chrome integration are now visible and remain active after restarts.

This explains why reinstalling Codex, resetting .codex, Roaming\Codex, and Local\OpenAI\Codex did not fix the issue: the broken state was stored in AppData\Local\OpenAI\extension.

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

The final root cause reported here is a very useful distinct failure mode: the bundled plugins themselves were not the missing piece. The persistent broken state lived under %LOCALAPPDATA%\OpenAI\extension, where the Native Messaging manifest contained a mojibake/non-ASCII Windows user path (é materialized as é). Recreating that extension state restored Browser, Computer Use and Chrome across restarts.

This is directly relevant to WinBridge's Native Host consistency layer. v3.1.1 validates the manifest path and host executable, Chrome/Edge HKCU NativeMessagingHosts registrations, chrome-native-hosts-v2.json, plugin/cache latest target, and current AppX/runtime paths together. A manifest/registry/v2 entry whose serialized path no longer resolves to the real current executable is treated as inconsistent rather than assuming that “manifest exists” means the bridge is healthy. The recovery path backs up the user-owned Native Host state before rebuilding/validating it.

This case is also a good reason to add explicit non-ASCII/Unicode-path regression coverage to recovery diagnostics. I would not classify the later @oai/sky export error mentioned from the fresh profile as the same problem: once Native Host/plugin visibility is healthy, an internal runtime/export incompatibility is upstream and should be reported separately.

WinBridge does not modify WindowsApps ownership/ACLs, browser policy, credentials, or account state.