Skip to content

Windows Codex App 26.915.4065.0 fails to load openai-bundled plugins, causing Browser, Computer Use, and Image Gen to be unavailable #46744

Open

Description

@UoA-Bryan

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_gen tool 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_gen tool.
  • 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

  1. added
    appIssues related to the Codex desktop app
    on Sep 20, 2026
  2. github-actions commented on Sep 20, 2026

    @github-actions
    Contributor

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

    Powered by Codex Action

  3. abby534706358 commented on Sep 22, 2026

    @abby534706358

    Additional reproduction from another Windows installation (user profile: C:\Users\linhy):

    • The expected bundled marketplace directory C:\Users\linhy\.codex\.tmp\bundled-marketplaces\openai-bundled does not exist, including .agents\plugins\marketplace.json.
    • C:\Users\linhy\.codex\config.toml still points [marketplaces.openai-bundled].source to that missing path.
    • Multiple openai-bundled.staging-* directories remain under .codex\.tmp\bundled-marketplaces; some contain a valid .agents\plugins\marketplace.json, while the final openai-bundled directory is absent.
    • Settings → Browser cannot load 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.

  4. UoA-Bryan commented on Sep 22, 2026

    @UoA-Bryan
    Author

    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.mjs

    C:\Program Files\WindowsApps\OpenAI.Codex_26.917.6896.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled\plugins\chrome\scripts\browser-service.mjs

    Both 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-bundled

    At the same time, config.toml contains:

    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-runtime exists.
    • browser-service.mjs is not present under the primary runtime path.
    • The old ~\.codex\.tmp\bundled-marketplaces\openai-bundled.staging-* directories are no longer present.
    • The packaged Browser resources inside the AppX package are complete.

    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 path

    So #46744 still reproduces on 26.917.51856 / AppX 26.917.6896.0.

  5. WarrenX1688 commented on Sep 23, 2026

    @WarrenX1688

    Additional local reproduction on Windows / Codex Desktop AppX 26.917.6896.0 (app-server reported 26.917.51856):

    • The bundled plugin resources are present in the installed AppX package under app\resources\plugins\openai-bundled.
    • On this machine, source plugin manifest files (including codex-app-tools and browser) have the Windows Encrypted file attribute. cipher /c reports Compatibility Level: Application Protected.
    • The destination under the user’s .codex\.tmp\bundled-marketplaces is not encrypted.
    • Desktop logs repeatedly report [BundledPluginsMarketplace] plugin_marketplace_folder_write_failed, followed by bundled_plugins_marketplace_resolve_failed. The failed operation is Node copyfile from the AppX openai-bundled source into an openai-bundled.staging-<guid> directory; the error is surfaced as UNKNOWN: unknown error.
    • The staging directories are incomplete; the final openai-bundled marketplace and plugin cache are absent. The expected bundled-plugin tools are not exposed in this session.

    This appears consistent with #46582’s report of CopyFile failing 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 CopyFile on Application Protected package resources, or handle this failure clearly and recoverably?

  6. UoA-Bryan commented on Sep 23, 2026

    @UoA-Bryan
    Author

    Update: the issue still reproduces after upgrading again to the latest Windows build available to me.

    Current versions:

    • ChatGPT/Codex Desktop: 26.917.62051
    • AppX package: 26.917.8451.0
    • Codex CLI: 0.155.0-alpha.16.3

    After the update:

    openai-bundled cache exists : False
    Browser service exists      : False
    

    The expected cache directory is still absent:

    C:\Users\ROG\.codex\plugins\cache\openai-bundled

    However, config.toml has already been updated to reference the new version:

    C:/Users/ROG/.codex/plugins/cache/openai-bundled/browser/26.917.62051/scripts/browser-service.mjs

    That 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.mjs

    app\resources\plugins\openai-bundled\plugins\chrome\scripts\browser-service.mjs

    There are also no remaining openai-bundled.staging-* directories under .codex\.tmp\bundled-marketplaces on this build.

    So the current state is still:

    packaged plugin exists -> user plugin cache is not created -> config.toml points to the missing cache path

    Given the other reproductions mentioning Application Protected AppX resources and Node copyfile failures, 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.

  7. UoA-Bryan commented on Sep 24, 2026

    @UoA-Bryan
    Author

    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-use plugin 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.exe is running.
    • A \\.\pipe\codex-computer-use-* named pipe exists.
    • SKY_CUA_NATIVE_PIPE=1 and SKY_CUA_NATIVE_PIPE_DIRECTORY are correctly injected into node_repl.
    • The computer-use plugin.json and SKILL.md are present.

    I then created a new conversation and explicitly instructed Codex to use node_repl and 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 session

    This also explains why explicitly following the bundled SKILL.md instructions works while a normal request such as "Use Computer Use to open Notepad" reports that Computer Use is unavailable.

  8. UoA-Bryan commented on Sep 24, 2026

    @UoA-Bryan
    Author

    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.

  9. sbhal commented on Sep 30, 2026

    @sbhal

    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):

    invalid marketplace file ~/.codex/.tmp/bundled-marketplaces/openai-bundled/.agents/plugins/marketplace.json: marketplace `openai-bundled` is reserved and cannot be loaded from this source
    

    The user-side openai-bundled marketplace JSON and Browser plugin cache (including browser-service.mjs) were present across restarts, and config.toml still had a [plugins."browser@openai-bundled"] section with enabled = true. On a GUI restart, the app log showed:

    [BundledPluginsMarketplace] bundled_plugins_runtime_marketplace_reused ...
    [AppServerConnection] plugin_marketplace_add_failed errorMessage="marketplace `openai-bundled` is reserved and cannot be added from this source"
    [BundledPluginsMarketplace] bundled_plugins_marketplace_add_failed ...
    

    As a diagnostic, removing only the user-level [marketplaces.openai-bundled] entry allowed one GUI startup to log plugin_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/read errors saying chatgpt 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/USER points to /local/home/USER. With no explicit CODEX_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 both marketplace/add and plugin/read with the reserved-marketplace errors above. Setting CODEX_HOME to the canonical location of the same existing .codex directory 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_HOME has now been applied. After restarting that GUI, its actual app-server process has the canonical setting and startup logs show:

    plugin_marketplace_add_succeeded alreadyAdded=true
    bundled_plugin_install_skipped_current pluginName=browser
    bundled_plugins_reconcile_completed
    

    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-key exactly matched the desktop SSH-sync hashing algorithm, which replaces the target marketplace directory and publishes only plugins marked for SSH synchronization. That explains the later visualize-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.

  10. lisheng251219-lgtm commented on Oct 1, 2026

    @lisheng251219-lgtm

    Reproduced again on the current official Windows package, with a completed Store Repair and post-repair verification (2026-10-02, Asia/Shanghai).

    Environment

    • Windows 11 Home, x64, build 26200.
    • OpenAI.Codex 26.928.3736.0; bundled Browser/Chrome 26.928.31416.
    • Chrome is running; extension 1.26.901.11451_0 is installed and enabled in the Default profile.
    • CODEX_HOME is explicitly configured on D:. Both it and the default home directory are ordinary directories, not junctions. Both C: and D: are healthy NTFS volumes with ample free space.

    Reproducible deployment failure

    • Desktop startup logs repeatedly report plugin_marketplace_folder_write_failed (errorCode=UNKNOWN, folderWritePhase=copy_plugins), then bundled_plugins_marketplace_resolve_failed.
    • The source is the installed WindowsApps package's plugins/browser/.codex-plugin/plugin.json. Its attributes are Archive, Encrypted.
    • Node fs.copyFile fails with code UNKNOWN, errno -4094, syscall copyfile in BOTH a fresh C: Temp directory and a fresh D: CODEX_HOME temporary directory.
    • PowerShell Copy-Item independently fails with HRESULT 0x80071770, corresponding to Win32 ERROR_ENCRYPTION_FAILED (6000).
    • Reading the source bytes and writing them to a new diagnostic file succeeds in BOTH locations; SHA-256 matches the original. Diagnostic files were then removed from the test locations.
    • Source/destination paths in the original failing copy are only 153/159 UTF-16 units; no relevant target ACL denial was found.

    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

    • Ran the supported command: winget repair --id 9PLM9XGG6VKS --source msstore --exact --silent --disable-interactivity (no force, no reset).
    • WinGet reports "Leaf command succeeded: root:repair"; the Windows AppX Register operation also succeeded at 00:19:13 local time.
    • After reopening the app, the SAME deployment failure recurred at 00:20:59 local time.
    • Official Chrome bootstrap still fails because %CODEX_HOME%/plugins/cache/openai-bundled/browser/26.928.31416/scripts/browser-service.mjs is missing.
    • Checked the current official ChatGPT-x64.msix manifest via bounded HTTP range reads. It is also OpenAI.Codex 26.928.3736.0, so the current download does not offer a newer version for this machine.

    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.

  11. kigar-gh commented on Oct 3, 2026

    @kigar-gh

    I can confirm a similar issue on a newer Windows 11 Microsoft Store build.

    Current versions and installation layout

    • AppX package: OpenAI.Codex_26.930.3930.0_x64__2p2nqsd0c76g0
    • Browser plugin version referenced in config.toml: 26.930.31730
    • The app is physically installed under E:\WindowsApps. Windows exposes its package through a junction under C:\Program Files\WindowsApps.
    • The user’s .codex directory is on C:.
    • Installing new Store apps on 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 .codex profile 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:

    • Win32 error 6000: “The specified file could not be encrypted.”
    • Node 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 bundled browser and codex-app-tools files from the installed official package into the user-local plugin cache, and decrypts the destination files.

    It restored:

    • browser\26.930.31730 — 384 files copied
    • codex-app-tools\0.1.5 — 5 files copied

    After 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.

  12. 3xachris commented on Oct 3, 2026

    @3xachris

    Additional reproduction on the current Windows package, with a more specific finding in the existing encrypted-copy fallback.

    Versions and symptoms

    • Desktop AppVersion: 26.930.31730.
    • AppX package: OpenAI.Codex_26.930.3930.0_x64__2p2nqsd0c76g0.
    • Built-in Code Review: PR list keeps loading and the app panel reports unavailable.
    • Personal panel: Your computer reports connection unavailable.
    • Rebooting did not resolve the original failure.

    Controlled copy tests

    Tests read only two packaged plugin manifests, codex-app-tools/.codex-plugin/plugin.json (245 bytes) and code-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:

    Method Result
    Read source bytes Success
    Win32 CopyFileW Failure: 6000 / ERROR_ENCRYPTION_FAILED; no destination file
    Node fs.promises.copyFile Failure: code=UNKNOWN, errno=-4094, syscall=copyfile; no destination file
    CopyFileExW with COPY_FILE_FAIL_IF_EXISTS | COPY_FILE_ALLOW_DECRYPTED_DESTINATION Success; destination not encrypted; SHA-256 matches source
    Read bytes, then write a new file Success; SHA-256 matches source

    The source manifests have the Encrypted attribute; 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 Node 22.23.1 / libuv 1.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.js inside app.asar. It already implements a streaming-copy fallback, but its eligibility check is equivalent to:

    const encryptionError = 6000;
    return error instanceof Error && error.errno === encryptionError;

    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 Yc capability preparation function also directly calls recursive fs.cp for app-tools, without this fallback wrapper.

    Application evidence

    • Local Work executor repeatedly fails at the app-tools manifest copy, with UNKNOWN. One desktop session contains 1,333 such startup failures, beginning before any tracing attempt.
    • The same session has 40 bundled marketplace copy failures.
    • The desktop app-server reports code-review@openai-bundled as not installed; its expected local plugin directory is absent.
    • The ordinary local app-server and the cloud WebSocket both completed initialization, so this is not evidence of a general network outage.

    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.

  13. UoA-Bryan commented on Oct 10, 2026

    @UoA-Bryan
    Author

    Update: the bundled marketplace provisioning/reconciliation issue is still reproducible on the latest Windows Desktop build.

    Current environment

    • ChatGPT/Codex Desktop UI: 26.1007.21434
    • AppX package: OpenAI.Codex 26.1007.2314.0
    • Bundled Codex CLI: 0.162.0-alpha.17.2
    • Windows 11 25H2, build 26200.9457

    The 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-bundled

    The packaged plugins were updated on 2026-10-10 and currently contain:

    • browser
    • chrome
    • code-review
    • codex-app-tools
    • computer-use
    • deep-research
    • latex
    • unified-computer-use
    • visualize

    User-side bundled marketplace

    Path:

    C:\Users\ROG\.codex\.tmp\bundled-marketplaces\openai-bundled

    This copy still contains the older plugin set dated around 2026-09-26:

    • browser
    • chrome
    • codex-app-tools
    • computer-use
    • deep-research
    • latex
    • unified-computer-use
    • visualize

    code-review is missing.

    Compare-Object reports:

    code-review <=

    File-content verification

    The packaged and user-side browser-service.mjs files also have different SHA256 hashes.

    AppX copy:

    2BD293312EE752CFC49876601DCC66ED80E9FDF4E588876AA46592E1B0DE612F

    User-side copy:

    BB9CB10FBE3E20514964EBEDFC9151B2464B71D1C52765E81E662C88EA10B267

    So 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-bundled marketplace 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 unchanged

    Current failure signature

    At this point:

    Desktop/App update → OK
    Codex CLI update → OK
    New bundled plugins present in AppX → OK
    Automatic refresh/reconciliation into ~/.codex/.tmp/bundled-marketplaces/openai-bundled → still not occurring

    This 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.

  14. zzzzzqs commented on Oct 14, 2026

    @zzzzzqs

    I can reproduce this on the current Windows Store Codex Desktop version:

    • AppX package: OpenAI.Codex_26.1007.9446.0_x64__2p2nqsd0c76g0
    • Windows
    • Microsoft Store installation

    The bundled marketplace in the AppX package is complete and contains:

    • browser
    • chrome
    • code-review
    • codex-app-tools
    • computer-use
    • deep-research
    • latex
    • unified-computer-use
    • visualize

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbrowserbugSomething isn't workingcomputer-useimagenskillsIssues related to skillswindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions