bundled_plugins_marketplace_resolve_failed / plugin_marketplace_folder_write_failed

Open 💬 2 comments Opened Aug 27, 2026 by NannaOlympicBroadcast

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0.

What subscription do you have?

Free

What platform is your computer?

Windows x64

What issue are you seeing?

Reproduced on the latest Windows Store build as of today (2026-08-27): OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0.

Same signature as the original report — bundled_plugins_marketplace_resolve_failed / plugin_marketplace_folder_write_failed, errorCode=UNKNOWN, copyfile ... The specified file could not be encrypted. Confirmed via Copy-Item reproduction on the exact source file (plugins\chrome\.codex-plugin\plugin.json), which has NTFS attributes Archive, Encrypted. robocopy succeeds on the same file (writes a plain, unencrypted copy); Copy-Item/Node fs.copyFile do not.

The codex plugin marketplace add workaround from the comments below no longer works on current builds. I fully robocopied the entire app\resources\plugins\openai-bundled package (826/826 files, including .agents\plugins\marketplace.json) into a user-owned directory and tried both (a) manually adding [marketplaces.openai-bundled] to config.toml, and (b) codex plugin marketplace add <path> via codex-cli 0.150.1. (a) is silently ignored — codex plugin marketplace list never shows it. (b) now fails explicitly:

Error: marketplace openai-bundled is reserved and cannot be added from this source

So it looks like a newer build added a guard that rejects manually registering openai-bundled, which closes off the workaround several commenters below reported success with on older builds (~26.527.x). At this point there is no user-side workaround left that I can find — the fix has to come from either not attempting a copy that preserves EFS attributes, or reading bundled plugin metadata directly from the installed package instead of staging a copy.

Environment: Windows 11 (domain-joined lab-style hostname), Codex 26.820.9563.0, codex-cli 0.150.1, install via Microsoft Store.

What steps can reproduce the bug?

OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 20 hours ago

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

#40059

Powered by Codex Action

zemeng5208 · 20 hours ago

This looks like a high-confidence match for one of the Windows local-state failure classes I track. I maintain WinBridge Recovery: https://github.com/zemeng5208/winbridge-recovery

For this specific report, the relevant layer is the bundled marketplace materialization/staging path from the MSIX/WindowsApps payload into the user-writable Codex state. WinBridge can help diagnose whether the failure is specifically the Application Protected/EFS copy case (rather than a missing package, stale cache, or file lock), inspect incomplete openai-bundled.staging-* / managed marketplace state, and validate any user-side materialized copy against the packaged files before recovery attempts.

The important limitation on current 26.820.9563.0 is exactly what you found: openai-bundled is now reserved, so a manually copied marketplace cannot simply be re-registered through config.toml or codex plugin marketplace add. WinBridge cannot change that product-side rule, modify WindowsApps, bypass Application Protected/EFS, or guarantee a durable fix. If Codex keeps using a copy path that fails on the protected source every startup, the real fix still needs to be upstream (for example a decrypted-destination/stream-copy fallback or direct use of the packaged metadata).

So in this case I would use WinBridge mainly to preserve/inspect the local staging state and separate recoverable user-state damage from the underlying copyfile regression; I would not treat it as a substitute for the Codex-side fix.