Skip to content

Bundled marketplace under .tmp is repeatedly overwritten with incomplete contents, causing Chrome plugin to fail loading #25780

Open

Description

@Zl-sketch-jpg

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

Codex Desktop: 26.527.7698.0

What subscription do you have?

plus

What platform is your computer?

Windows 11

What issue are you seeing?

openai-bundled marketplace is configured to a temporary directory under .codex.tmp. The directory is repeatedly rewritten into an incomplete state. After manually restoring the full marketplace from a valid copy, the directory is overwritten again and loses .agents\plugins\marketplace.json and all .codex-plugin\plugin.json files.

As a result, enabled bundled plugins remain configured, but plugin loading fails, especially chrome@openai-bundled.

What steps can reproduce the bug?

Restore a complete openai-bundled marketplace into:
C:\Users\ZL.codex.tmp\bundled-marketplaces\openai-bundled
Verify it contains:
.agents\plugins\marketplace.json
and plugin manifests for browser, chrome, computer-use, latex.
Continue using Codex Desktop / plugin list / Chrome plugin.
Re-check the directory.
The directory is overwritten back to an incomplete state with only Chrome extension-host content.

What is the expected behavior?

Bundled marketplace refresh should be atomic and complete. It should not leave .tmp\bundled-marketplaces\openai-bundled in a partial state. If refresh fails, Codex should retain the previous valid marketplace/cache or fall back to a stable bundled source.

Additional information

WARN codex_core_plugins::loader core-plugins\src\loader.rs:67
failed to load plugin: missing or invalid plugin.json
plugin="chrome@openai-bundled"
path=C:\Users\ZL.codex\plugins\cache\openai-bundled\chrome\26.527.60818
WARN codex_core_plugins::loader core-plugins\src\loader.rs:346
configured non-curated plugin no longer exists in discovered marketplaces during cache refresh
plugin="browser" marketplace="openai-bundled"

WARN codex_core_plugins::loader core-plugins\src\loader.rs:346
configured non-curated plugin no longer exists in discovered marketplaces during cache refresh
plugin="chrome" marketplace="openai-bundled"

WARN codex_core_plugins::loader core-plugins\src\loader.rs:346
configured non-curated plugin no longer exists in discovered marketplaces during cache refresh
plugin="computer-use" marketplace="openai-bundled"
The bundled marketplace writer/refresh path appears to treat .tmp\bundled-marketplaces\openai-bundled as both a temporary build output and the configured persistent marketplace source. When the refresh writes only part of the bundled Chrome extension host, it removes or fails to restore the marketplace manifest and plugin manifests, breaking plugin discovery and loading.

Activity

  1. added
    appIssues related to the Codex desktop app
    on Jun 2, 2026
  2. added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    skillsIssues related to skills
    on Jun 2, 2026
  3. github-actions commented on Jun 2, 2026

    @github-actions
    Contributor
  4. Statusnone420 commented on Jun 4, 2026

    @Statusnone420

    I can confirm a very similar failure shape on Windows 26.601 as well.

    Environment:

    Codex Desktop: OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g0
    Desktop/internal CLI: codex-cli 0.136.0-alpha.2
    Bundled plugin version: 26.601.21317
    

    Current good state after recovery:

    [marketplaces.openai-bundled]
    source_type = "local"
    source = '\\?\%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled'
    

    The critical file that determines whether openai-bundled is discoverable is:

    %USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled\.agents\plugins\marketplace.json
    

    When that file and the bundled plugin folders are present, the Desktop/internal CLI sees the marketplace and Browser/Computer Use work:

    MARKETPLACE             ROOT
    openai-bundled          %USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled
    
    browser@openai-bundled       installed, enabled  26.601.21317
    computer-use@openai-bundled  installed, enabled  26.601.21317
    chrome@openai-bundled        not installed
    

    Runtime validation from the same recovered session:

    Browser: opened https://example.com/, title=Example Domain, expected heading found
    Computer Use: list_apps succeeded with 40 apps, 5 running apps, 5 targetable windows
    Computer Use: list_windows succeeded with 5 windows
    

    Earlier in the same debugging sequence, opening/restarting Codex Desktop was the event that made bundled plugins disappear from Settings / plugin discovery. Reboot alone did not appear to erase them. Manually restoring/copying the bundled marketplace contents from the installed app package back into the .tmp\bundled-marketplaces\openai-bundled path restored discovery until the next time the transient marketplace became incomplete.

    This lines up with the theory in this issue: Desktop appears to use .codex\.tmp\bundled-marketplaces\openai-bundled as both a generated/transient output and the registered marketplace source. If that directory is cleared or only partially written, consumers see a configured marketplace path but no valid .agents\plugins\marketplace.json, which makes bundled plugins look unavailable even though the app package still contains the full bundled marketplace.

    Expected behavior from the user side: the Desktop-owned bundled marketplace should either live in a durable cache path, or the .tmp rewrite should be atomic/complete and fall back to the previous valid marketplace if materialization fails.

  5. D2Rich commented on Jun 12, 2026

    @D2Rich

    GitHub issue #25780 feedback draft

    Validated follow-up workaround on Windows 11 / Codex Desktop 26.609.3341.0 (bundled plugins 26.609.30741).

    The failure still appears related to incomplete bundled-marketplace materialization and Chrome native-host file locks. One stale Chrome cache had a latest junction targeting a deleted .tmp\bundled-marketplaces\openai-bundled\plugins\chrome directory.

    A working split setup was:

    • Keep computer-use@openai-bundled installed/enabled and do not clear its cache or change its helper path.
    • Copy the complete official bundled marketplace from the installed app package to a durable user directory.
    • Create a second local marketplace, openai-chrome-local, containing only Chrome.
    • Write its marketplace.json as UTF-8 without BOM; Windows PowerShell Set-Content -Encoding UTF8 caused expected value at line 1 column 1.
    • Install chrome@openai-chrome-local and re-enable the Codex Chrome Extension.

    End-to-end runtime validation succeeded:

    computer-use@openai-bundled  installed, enabled  26.609.30741
    chrome@openai-chrome-local   installed, enabled  26.609.30741
    
    Computer Use: launched Windows Notepad successfully
    Chrome: opened https://example.com/ successfully
    Title: Example Domain
    

    Remaining bug: after setting chrome@openai-bundled disabled, Codex Desktop changed it back to enabled on startup. Plugin state may be synchronized by plugin name instead of full plugin@marketplace identity, so duplicate Chrome entries can reappear.

    This is a workaround, not a permanent fix. The product still needs atomic marketplace replacement/fallback, recovery from partial snapshots, native-host lock handling, and consistent Settings/CLI/session state. Related: #26387.

  6. zemeng5208 commented on Aug 12, 2026

    @zemeng5208

    I maintain WinBridge Recovery, an independent Windows-side recovery tool for Codex Desktop bundled-plugin state: https://github.com/zemeng5208/winbridge-recovery

    This issue is a direct match for one of the failure modes the project is designed around: the Desktop-owned .tmp\bundled-marketplaces\openai-bundled tree is registered as the active source, then gets rewritten incompletely and loses the marketplace/plugin manifests while the official app package still contains the complete bundled plugins.

    The recovery flow is version-aware. It detects the currently installed official Desktop package, validates/reconstructs the user-side bundled marketplace, reconciles versioned plugin caches and latest pointers, and checks related runtime/registration state. It also tries to stop the Chrome/Edge native-host lock from interfering with cache reconciliation. Backups, rollback, and post-repair consistency checks are included rather than doing an unconditional destructive cleanup.

    It does not take ownership of or patch C:\Program Files\WindowsApps, and it does not redistribute official plugin files. It only reconstructs recovery state from the official package already installed on that machine.

    This is a user-side recovery/workaround, not a replacement for the upstream fix requested here: the Desktop marketplace writer still needs atomic publication/fallback so a failed refresh cannot make a partial .tmp tree become the active marketplace.

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 appbugSomething isn't workingskillsIssues 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