Repository navigation
Windows Codex App 26.915.4065.0 fails to load openai-bundled plugins, causing Browser, Computer Use, and Image Gen to be unavailable #46744
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.915.4065.0
What subscription do you have?
Free (also reproduced when testing with a Plus account)
What platform is your computer?
Windows 11 25H2, x86_64, build 26200.9457
What issue are you seeing?
After updating/using Codex App on Windows, several built-in tools are no longer available even though the corresponding files and runtimes are present in the installed package.
Observed behavior:
- Browser control is unavailable.
- Computer Use is unavailable.
- Image generation is unavailable in Codex. The model recognizes the Image Gen skill/instruction, but reports that the actual
image_gentool is not attached to the current session. - Restarting Codex, force-reloading skills, terminating all Codex/ChatGPT processes, and reopening the app do not restore these tools.
- Windows App Repair also cannot be triggered reliably and reports that the app is still running, even after all Codex/ChatGPT processes have been terminated.
Diagnostics:
Codex App version:
26.915.4065.0
Embedded CLI:
codex-cli 0.155.0-alpha.9.2
The installed Windows package contains the bundled plugins:
browser
chrome
codex-app-tools
computer-use
deep-research
latex
unified-computer-use
user-writing
visualize
The Computer Use native runtime also exists:
C:\Users\ROG\AppData\Local\OpenAI\Codex\runtimes\cua_node\df473e5367fa2b42\bin\node_modules\@oai\sky\bin\windows\codex-computer-use.exe
However, the active plugin marketplaces only show:
openai-primary-runtime
openai-curated
openai-bundled is missing.
Running:
codex plugin marketplace remove openai-bundled
returns:
Error: marketplace `openai-bundled` is not configured or installed
Trying to manually add the bundled marketplace:
codex plugin marketplace add <path-to-openai-bundled>
returns:
Error: marketplace `openai-bundled` is reserved and cannot be added from this source
The expected user-side bundled marketplace/cache is also missing:
C:\Users\ROG\.codex\.tmp\bundled-marketplaces\openai-bundled
and:
C:\Users\ROG\.codex\plugins\cache\openai-bundled
do not exist.
At the same time, config.toml still contains references to the bundled browser plugin, for example:
NODE_REPL_TRUSTED_SERVICES = '{"browser":"C:/Users/ROG/.codex/plugins/cache/openai-bundled/browser/26.915.31945/scripts/browser-service.mjs","sky":"@oai/sky/service"}'
Logs also repeatedly report:
failed to load plugin: plugin is not installed
plugin="codex-app-tools@openai-bundled"
path=C:\Users\ROG\.codex\plugins\cache\openai-bundled\codex-app-tools
The same logs show that relevant feature flags are enabled, including:
BrowserUse
BrowserUseFullCdpAccess
BrowserUseExternal
ComputerUse
ImageGeneration
Plugins
so the features appear to be enabled, but the actual tools/plugins are not being materialized or exposed to the Codex session.
For Image Gen specifically, Codex reports messages such as:
The current Codex session does not provide the actual image_gen tool, so I cannot generate the image directly.
This also reproduces in a newly opened Codex session.
Expected behavior:
The built-in openai-bundled marketplace should be initialized automatically, and Browser, Computer Use, and Image Generation tools should be available when the account is eligible.
Actual behavior:
The bundled plugin files exist inside the installed AppX/MSIX package, but openai-bundled is not registered/materialized into the user's Codex plugin state, leaving multiple built-in tools unavailable.
What steps can reproduce the bug?
Submitted performance trace: 01a0b816-f125-7471-b435-039af82e6f6c
What is the expected behavior?
Codex should automatically initialize and load the built-in openai-bundled marketplace.
When the relevant features are enabled, Browser, Computer Use, and Image Generation should be exposed as usable tools in Codex sessions.
For example:
- Asking Codex to generate an image should invoke the actual
image_gentool. - Asking Codex to browse the web should make the built-in browser available.
- Asking Codex to control supported desktop applications should make Computer Use available.
The user should not need to manually register or copy bundled plugins from the installed Windows package.
Additional information
This does not appear to be a missing installation file.
The installed Codex package contains the expected bundled plugins, and the Computer Use native runtime is also present.
However, openai-bundled is absent from the active marketplace list and from the user plugin cache.
Relevant environment:
Codex App: 26.915.4065.0
Embedded CLI: codex-cli 0.155.0-alpha.9.2
Windows: Windows 11 x64
The Codex logs also show enabled feature flags including:
BrowserUse
BrowserUseFullCdpAccess
BrowserUseExternal
ComputerUse
ImageGeneration
Plugins
but also repeatedly report:
failed to load plugin: plugin is not installed
plugin="codex-app-tools@openai-bundled"
This suggests that the feature flags are enabled and the bundled plugin files exist, but the bundled marketplace/tools are not being materialized or exposed to the active Codex session.
The issue also persists after:
- restarting Codex,
- creating a new conversation,
- force-reloading skills,
- terminating all Codex/ChatGPT processes,
- and attempting Windows App Repair.
The Desktop folder on this machine is redirected to drive D:, while USERPROFILE, .codex, and Codex runtime data remain under C:\Users\ROG. I am including this in case Windows Known Folder redirection is relevant.
Activity
github-actions commentedon Sep 20, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
abby534706358 commentedon Sep 22, 2026
Additional reproduction from another Windows installation (user profile:
C:\Users\linhy):C:\Users\linhy\.codex\.tmp\bundled-marketplaces\openai-bundleddoes not exist, including.agents\plugins\marketplace.json.C:\Users\linhy\.codex\config.tomlstill points[marketplaces.openai-bundled].sourceto that missing path.openai-bundled.staging-*directories remain under.codex\.tmp\bundled-marketplaces; some contain a valid.agents\plugins\marketplace.json, while the finalopenai-bundleddirectory is absent.browser@openai-bundled.This appears consistent with an incomplete staging-to-final marketplace publication or rename on Windows, rather than the bundled plugin files being absent from the installation. No manual changes were made to these paths during this check.
UoA-Bryan commentedon Sep 22, 2026
Update after upgrading to ChatGPT/Codex for Windows 26.917.51856 (AppX package 26.917.6896.0):
The issue still reproduces, but the failure signature has changed.
The packaged Browser and Chrome plugin resources are present inside the installed AppX package:
C:\Program Files\WindowsApps\OpenAI.Codex_26.917.6896.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled\plugins\browser\scripts\browser-service.mjsC:\Program Files\WindowsApps\OpenAI.Codex_26.917.6896.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled\plugins\chrome\scripts\browser-service.mjsBoth files are present and have size 1,365,738 bytes.
However, the expected user plugin cache is still not created:
C:\Users\ROG\.codex\plugins\cache\openai-bundledAt the same time,
config.tomlcontains:NODE_REPL_TRUSTED_SERVICES = '{"browser":"C:/Users/ROG/.codex/plugins/cache/openai-bundled/browser/26.917.51856/scripts/browser-service.mjs","sky":"@oai/sky/service"}'So the configuration points to a Browser service path that does not exist.
Additional observations:
C:\Users\ROG\.cache\codex-runtimes\codex-primary-runtime\plugins\openai-primary-runtimeexists.browser-service.mjsis not present under the primary runtime path.~\.codex\.tmp\bundled-marketplaces\openai-bundled.staging-*directories are no longer present.This suggests that in 26.917 the old staging behavior has changed, but the bundled plugin provisioning/materialization step from the packaged resources into the user plugin cache still does not complete.
In short:
packaged Browser plugin exists -> user plugin cache is missing -> config.toml still points to the missing cache pathSo #46744 still reproduces on 26.917.51856 / AppX 26.917.6896.0.
WarrenX1688 commentedon Sep 23, 2026
Additional local reproduction on Windows / Codex Desktop AppX 26.917.6896.0 (app-server reported 26.917.51856):
app\resources\plugins\openai-bundled.codex-app-toolsandbrowser) have the WindowsEncryptedfile attribute.cipher /creportsCompatibility Level: Application Protected..codex\.tmp\bundled-marketplacesis not encrypted.[BundledPluginsMarketplace] plugin_marketplace_folder_write_failed, followed bybundled_plugins_marketplace_resolve_failed. The failed operation is Nodecopyfilefrom the AppXopenai-bundledsource into anopenai-bundled.staging-<guid>directory; the error is surfaced asUNKNOWN: unknown error.openai-bundledmarketplace and plugin cache are absent. The expected bundled-plugin tools are not exposed in this session.This appears consistent with #46582’s report of
CopyFilefailing on an EFS/Application Protected source, but I have not independently verified the exact Windows error code on this machine. No files were manually copied or modified.Could the Windows bundled-marketplace provisioning path avoid
CopyFileon Application Protected package resources, or handle this failure clearly and recoverably?UoA-Bryan commentedon Sep 23, 2026
Update: the issue still reproduces after upgrading again to the latest Windows build available to me.
Current versions:
26.917.6205126.917.8451.00.155.0-alpha.16.3After the update:
The expected cache directory is still absent:
C:\Users\ROG\.codex\plugins\cache\openai-bundledHowever,
config.tomlhas already been updated to reference the new version:C:/Users/ROG/.codex/plugins/cache/openai-bundled/browser/26.917.62051/scripts/browser-service.mjsThat target file does not exist.
The installed AppX package still contains the Browser and Chrome plugin resources, including:
app\resources\plugins\openai-bundled\plugins\browser\scripts\browser-service.mjsapp\resources\plugins\openai-bundled\plugins\chrome\scripts\browser-service.mjsThere are also no remaining
openai-bundled.staging-*directories under.codex\.tmp\bundled-marketplaceson this build.So the current state is still:
packaged plugin exists -> user plugin cache is not created -> config.toml points to the missing cache pathGiven the other reproductions mentioning
Application ProtectedAppX resources and Nodecopyfilefailures, this still appears consistent with a failure in the Windows bundled-plugin provisioning/materialization path rather than missing packaged resources.No files were manually copied or modified during this check.
UoA-Bryan commentedon Sep 24, 2026
Additional finding: Computer Use itself is functional; the failure appears to be in bundled-plugin/skill registration rather than the Computer Use runtime.
After manually restoring the missing
computer-useplugin cache, a normal new conversation still reports that no Computer Use tool is available.However, the Computer Use backend is healthy:
codex-computer-use-swift.exeis running.\\.\pipe\codex-computer-use-*named pipe exists.SKY_CUA_NATIVE_PIPE=1andSKY_CUA_NATIVE_PIPE_DIRECTORYare correctly injected intonode_repl.computer-useplugin.jsonandSKILL.mdare present.I then created a new conversation and explicitly instructed Codex to use
node_repland run:const { sky } = await import("@oai/sky");Codex immediately displayed the native Computer Use permission prompt for Notepad, and after approval it successfully opened Notepad and entered
Hello.So the actual Computer Use runtime, native helper, pipe, permission UI, and Windows automation path all work.
The failure appears to be before that layer:
computer-use plugin exists -> Computer Use runtime works -> but the bundled Computer Use skill/capability is not automatically exposed to the sessionThis also explains why explicitly following the bundled
SKILL.mdinstructions works while a normal request such as "Use Computer Use to open Notepad" reports that Computer Use is unavailable.UoA-Bryan commentedon Sep 24, 2026
Still reproducible on Desktop 26.917.71314 / AppX 26.917.9434.0. The app/runtime/config all upgraded successfully, but no 26.917.71314 bundled plugin cache was materialized, the final openai-bundled marketplace is absent, and there are no staging directories. config.toml nevertheless points Browser to the nonexistent 26.917.71314 cache path.
sbhal commentedon Sep 30, 2026
Additional Linux reproduction, with a different failure signature from the Windows cache-copy reports above.
Environment: ChatGPT desktop app 26.928.21956, bundled Codex CLI 0.159.2, Amazon Linux 2023 under NICE DCV.
After installing Browser Use from Settings, relaunching the Linux GUI can make Settings → Browser Use offer to install it again. On another launch, Settings showed (home path shortened):
The user-side
openai-bundledmarketplace JSON and Browser plugin cache (includingbrowser-service.mjs) were present across restarts, andconfig.tomlstill had a[plugins."browser@openai-bundled"]section withenabled = true. On a GUI restart, the app log showed:As a diagnostic, removing only the user-level
[marketplaces.openai-bundled]entry allowed one GUI startup to logplugin_marketplace_add_succeeded, but the GUI recreated that entry, and a subsequent GUI restart hit the same reserved-marketplace error. Browser Use remained unavailable in Settings. This looks like a bundled marketplace registration/validation problem on Linux; unlike the Windows reports here, the user-side marketplace and Browser cache were present.The local Codex host uses an API model provider. The GUI also logged
plugin/readerrors sayingchatgpt authentication required for remote plugin catalog; I cannot tell whether that is related to the bundled marketplace rejection.Update after isolating the Linux failure: the reserved-marketplace error is reproducible with the app's bundled stock CLI/app server, independently of the custom CLI wrapper.
The Linux home directory is a symlink:
/home/USERpoints to/local/home/USER. With no explicitCODEX_HOME, the app server's initialize response reports/home/USER/.codex, while the GUI resolves the bundled marketplace root to/local/home/USER/.codex/.tmp/bundled-marketplaces/openai-bundled. In an isolated filesystem test, this combination fails bothmarketplace/addandplugin/readwith the reserved-marketplace errors above. SettingCODEX_HOMEto the canonical location of the same existing.codexdirectory makes both operations succeed, with the same marketplace contents and native binary. Marketplace add/remove also succeed through the custom wrapper with the correct home setting.A user desktop-launcher override that launches the Linux GUI with the canonical
CODEX_HOMEhas now been applied. After restarting that GUI, its actual app-server process has the canonical setting and startup logs show:The CLI again lists Browser as installed and enabled. Settings UI confirmation and actual browser navigation are still pending; this verifies the marketplace validation failure and its repair, not every Browser Use symptom.
There is also a separate concurrent-client effect: a Mac desktop client connected to this host through SSH replaced the host's temporary bundled marketplace with one containing only
visualize. The resulting.materialization-keyexactly matched the desktop SSH-sync hashing algorithm, which replaces the target marketplace directory and publishes only plugins marked for SSH synchronization. That explains the latervisualize-only marketplace despite the Browser install cache remaining on disk.These findings identify the Linux path mismatch and the shared-marketplace rewrite; they do not establish the root cause of the Windows package-copy failures reported above.
lisheng251219-lgtm commentedon Oct 1, 2026
Reproduced again on the current official Windows package, with a completed Store Repair and post-repair verification (2026-10-02, Asia/Shanghai).
Environment
Reproducible deployment failure
Fallback mismatch
Read-only inspection of the installed windows-file-copy-BC90BUDy.js shows that its encrypted-copy streaming fallback is gated on error.errno === 6000. The actual Node error has errno -4094, so this condition is false. No windows_encrypted_copy_fallback_started/succeeded events appear for these failures.
Repair and verification
Could the Windows error normalization/fallback condition be corrected so this encrypted-source copy failure reaches the existing safe streaming fallback? Please also provide a production-supported recovery path for already-missing bundled plugin assets. The diagnostic suggestion to use Debug > Plugins > Reload bundled plugins is not available in ordinary prod/public-beta builds.
No application code, trust configuration, native-host registration, or Windows security settings were modified. This report contains no browser contents, account details, authentication material, personal directory names, or full logs.
kigar-gh commentedon Oct 3, 2026
I can confirm a similar issue on a newer Windows 11 Microsoft Store build.
Current versions and installation layout
OpenAI.Codex_26.930.3930.0_x64__2p2nqsd0c76g0config.toml:26.930.31730E:\WindowsApps. Windows exposes its package through a junction underC:\Program Files\WindowsApps..codexdirectory is onC:.E:is an intentional Windows storage setting.Symptoms
The built-in browser UI works: I can open a website and browse manually. However, the model cannot read the content of the open tab.
This happened again after the latest update. A previous clean reset of the
.codexprofile and app reinstall did not resolve the issue.Earlier diagnostics
On the previous build (
26.924.2738.0), the bundled Browser files existed in the installed package, but the expected user-local plugin cache was missing. A controlled copy test returned:6000: “The specified file could not be encrypted.”fs.copyFile:UNKNOWN,errno=-4094.The source files were marked
Encrypted / Application Protected. These copy tests have not been repeated on the current build.Workaround and verification on the current build
I reran a local recovery script that reads the expected Browser version from
config.toml, copies the matching bundledbrowserandcodex-app-toolsfiles from the installed official package into the user-local plugin cache, and decrypts the destination files.It restored:
browser\26.930.31730— 384 files copiedcodex-app-tools\0.1.5— 5 files copiedAfter running the script, the model successfully connected to the built-in browser and read the title and visible headlines from my already-open Onet tab. This was a direct read of the existing browser tab, not a separate web request to the website.
The workaround restores functionality, but it has needed to be repeated after app updates. It does not modify the installed WindowsApps package.
3xachris commentedon Oct 3, 2026
Additional reproduction on the current Windows package, with a more specific finding in the existing encrypted-copy fallback.
Versions and symptoms
26.930.31730.OpenAI.Codex_26.930.3930.0_x64__2p2nqsd0c76g0.Controlled copy tests
Tests read only two packaged plugin manifests,
codex-app-tools/.codex-plugin/plugin.json(245 bytes) andcode-review/.codex-plugin/plugin.json(1486 bytes). All test destinations were new files in scratch directories, not the active plugin cache or executor directories.Both manifests produced the same results:
CopyFileW6000 / ERROR_ENCRYPTION_FAILED; no destination filefs.promises.copyFilecode=UNKNOWN,errno=-4094,syscall=copyfile; no destination fileCopyFileExWwithCOPY_FILE_FAIL_IF_EXISTS | COPY_FILE_ALLOW_DECRYPTED_DESTINATIONThe source manifests have the
Encryptedattribute; the app-tools source was also reported as Application Protected. A plain-text control fixture copied successfully using both Win32 and Node in the same scratch directory. The standalone Node test used Node22.23.1/ libuv1.51.0.Existing fallback does not match the observed Node error
Read-only inspection of the installed package found
.vite/build/windows-file-copy-JojxPUv2.jsinsideapp.asar. It already implements a streaming-copy fallback, but its eligibility check is equivalent to:The measured Node error has
errno=-4094, so this check does not match. The bundled marketplace's Windows directory-copy path invokes this wrapper. This independently corroborates the fallback mismatch described in the earlier comment.The Local Work executor's
Yccapability preparation function also directly calls recursivefs.cpfor app-tools, without this fallback wrapper.Application evidence
UNKNOWN. One desktop session contains 1,333 such startup failures, beginning before any tracing attempt.code-review@openai-bundledas not installed; its expected local plugin directory is absent.Scope and remaining limits
No WindowsApps files, permissions, source-file encryption, active plugin files, or application settings were changed as part of these copy tests. No tokens, cookies, keys, personal paths, or full logs are included here.
The tests used separate processes and scratch destinations; they do not directly capture the desktop process's original Win32 error. The standalone Node runtime may differ from the desktop's embedded runtime. We have not completed a production repair or UI acceptance, and do not claim the two UI symptoms are fully proven to share every step of the same failure chain.
Could the encrypted-copy error recognition be corrected, and the executor capability preparation path use the appropriate fallback as well? A supported recovery path for already-missing bundled plugins would also be helpful.
UoA-Bryan commentedon Oct 10, 2026
Update: the bundled marketplace provisioning/reconciliation issue is still reproducible on the latest Windows Desktop build.
Current environment
26.1007.21434OpenAI.Codex 26.1007.2314.00.162.0-alpha.17.226200.9457The Desktop application itself updated successfully through the current in-app updater, and the bundled Codex CLI was also updated successfully.
However, the bundled marketplace under the user profile was not refreshed.
Packaged bundled marketplace
Current AppX path:
C:\Program Files\WindowsApps\OpenAI.Codex_26.1007.2314.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundledThe packaged plugins were updated on 2026-10-10 and currently contain:
User-side bundled marketplace
Path:
C:\Users\ROG\.codex\.tmp\bundled-marketplaces\openai-bundledThis copy still contains the older plugin set dated around 2026-09-26:
code-reviewis missing.Compare-Objectreports:code-review <=File-content verification
The packaged and user-side
browser-service.mjsfiles also have different SHA256 hashes.AppX copy:
2BD293312EE752CFC49876601DCC66ED80E9FDF4E588876AA46592E1B0DE612FUser-side copy:
BB9CB10FBE3E20514964EBEDFC9151B2464B71D1C52765E81E662C88EA10B267So this is not only a timestamp difference: the actual user-side plugin contents are stale.
Important clarification about the existing user-side copy
The
openai-bundledmarketplace currently present under my user profile was not successfully created or refreshed by a later Desktop update.During earlier troubleshooting in late September, after automatic provisioning had failed, I manually restored the bundled plugin state using a repair package/script created specifically for that troubleshooting process.
After that manual repair, the affected bundled plugins, including Computer Use, worked normally.
Therefore, the existing user-side marketplace dated around 2026-09-26 should not be interpreted as evidence that automatic bundled-marketplace provisioning had recovered.
The sequence was effectively:
automatic provisioning failed→
manual repair/restoration succeeded→
bundled plugins worked normally→
later Desktop/AppX versions continued to update→
packaged bundled plugins continued to change→
the manually restored user-side marketplace remained unchangedCurrent failure signature
At this point:
Desktop/App update→ OKCodex CLI update→ OKNew bundled plugins present in AppX→ OKAutomatic refresh/reconciliation into ~/.codex/.tmp/bundled-marketplaces/openai-bundled→ still not occurringThis differs slightly from the original failure mode where the final bundled marketplace could be missing entirely. The current state is that an older manually restored marketplace remains present, but subsequent Desktop/AppX updates do not reconcile or refresh it.
I have not yet confirmed from the latest logs whether the current failure is still caused by the exact same
copyfile UNKNOWN / errno -4094 / ERROR_ENCRYPTION_FAILED (6000)path documented earlier in this issue, so I do not want to assume the underlying cause is identical.What is confirmed is that the automatic bundled-marketplace provisioning/reconciliation problem remains reproducible on the latest build.
zzzzzqs commentedon Oct 14, 2026
I can reproduce this on the current Windows Store Codex Desktop version:
The bundled marketplace in the AppX package is complete and contains:
The package marketplace.json also correctly contains codex-app-tools.
However, Codex Desktop fails while materializing openai-bundled from WindowsApps into:
C:\Users<user>.codex.tmp\bundled-marketplaces\
The logs repeatedly show:
[BundledPluginsMarketplace] plugin_marketplace_folder_write_failed
errorCode=UNKNOWN
errorMessage="UNKNOWN: unknown error, copyfile ..."
followed by:
bundled_plugins_marketplace_resolve_failed
The failures occurred on files such as:
plugins\unified-computer-use.codex-plugin\plugin.json
plugins\chrome.codex-plugin\plugin.json
plugins\browser.codex-plugin\plugin.json
This leaves multiple openai-bundled.staging-* directories and prevents the final
openai-bundled marketplace from being created.
In my case this also affected codex-app-tools, which contains Desktop thread tools
including create_thread, fork_thread, send_message_to_thread, etc.
Workaround:
I manually materialized the complete openai-bundled directory using .NET FileStream
(OpenRead -> File.Create -> CopyTo), instead of Copy-Item / Node fs.copyFile.
After that:
codex plugin marketplace list
correctly showed openai-bundled.
Then:
codex plugin add codex-app-tools@openai-bundled
succeeded, and:
codex plugin list
now shows:
codex-app-tools@openai-bundled installed, enabled 0.1.6
The cached server.mjs SHA-256 exactly matches the AppX copy.
The running app-server also has:
-c plugins.codex-app-tools@openai-bundled.mcp_servers.codex_app.enabled=true
So this appears to still be the WindowsApps/Application Protected -> user directory
copyfile issue, now also affecting codex-app-tools and Desktop thread tools in
26.1007.9446.0.
I have not yet been able to perform the final create_thread runtime test because my
Codex usage quota is currently exhausted.