›_ Codex Issues
Codex Issues / #29103

Plugins from built-in marketplace are deleted after restart — marketplace source not persisted to config.toml

Open 💬 4 comments Opened Jun 19, 2026 by AIAFKK
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Environment

  • Codex Desktop on macOS (arm64)
  • config.toml: ~/.codex/config.toml

Steps to reproduce

  1. Open Codex Plugin UI (Plugins tab)
  2. Install any plugin from the built-in marketplace (e.g., Build Web Apps, Sentry, Superpowers)
  3. Verify plugin appears in plugins cache at ~/.codex/plugins/cache/openai-api-curated/
  4. Restart Codex
  5. Observe: the plugin disappears from cache and is no longer available

Root cause

When plugins are installed through the UI, they are downloaded to ~/.codex/plugins/cache/openai-api-curated/<plugin-name>/, but no corresponding marketplace entry is written to ~/.codex/config.toml.

`openai-curated is a reserved marketplace name that cannot be added via CLI (codex plugin marketplace add https://github.com/openai/plugins` fails with "marketplace 'openai-curated' is reserved").

On restart, the plugin sync process finds cached plugins without a valid marketplace source in config.toml and cleans them up as orphans.

Affected marketplaces

  • openai-curated-remote (binance, data-analytics, figma, github, openai-developers)
  • openai-api-curated (build-web-apps, build-web-data-visualization, circleci, coderabbit, codex-security, sentry, superpowers, mixpanel-headless, etc.)

Expected behavior

Plugins installed through the UI should persist across restarts. The marketplace source should be written to config.toml (or an equivalent persistence mechanism) at install time.

Workaround

  • Plugins from standalone GitHub repos (e.g., agentmemory, circleci-public/skills) work fine when registered via codex plugin marketplace add
  • The 5 plugins from openai-curated-remote can be manually pinned by editing config.toml directly:
[marketplaces."openai-curated"]
source_type = "git"
source = "https://github.com/openai/plugins"

[plugins."github@openai-curated"]
enabled = true
  • However, openai-api-curated plugins have no individual GitHub repos and cannot be registered this way. They can only be re-added via the UI after each restart.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 2 months ago

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

  • #28703

Powered by Codex Action

Necmttn · 2 months ago

Install persistence should probably be modeled as an install record separate from cache contents: plugin id, marketplace id, source, version/ref, installed_by, installed_at, and ownership. On restart, sync can reconcile records to cache instead of treating unrecorded curated plugins as orphans. A repair command could list cached-without-install-record plugins and write the missing marketplace source.

---

_Generated with ax._

grtninja · 1 month ago

Cross-platform corroboration involving codex-security on Codex Desktop for Windows.

Observed around June 24, 2026:

  1. codex-security had previously been installed and visible in Plugins > Manage.
  2. After a Codex Desktop update that morning, it disappeared from the managed-plugin list without an uninstall confirmation, migration notice, or visible error.
  3. Codex Web still showed Codex Security as active for the same account, so the account entitlement and Desktop plugin state disagreed.
  4. Manually searching the plugin marketplace and reinstalling codex-security restored it.

The exact Desktop build was not captured, and this evidence does not distinguish whether the update deleted the cached plugin, dropped its marketplace/source registration, or merely hid an installed entitlement. The user-visible failure is the same: a previously available curated plugin silently vanished across an update and required rediscovery/reinstallation.

Expected behavior:

  • curated-plugin installation and enabled state persist through Desktop updates/restarts;
  • update migration reconciles account entitlement, marketplace registration, cache contents, and enabled state;
  • if a plugin is removed or disabled, the UI shows the exact reason and recovery action;
  • the app must not silently clean up an entitled plugin as an orphan;
  • diagnostics should record old/new plugin version, marketplace source, migration action, and removal reason.

This Windows codex-security case suggests the persistence problem is not limited to the macOS examples in the original report.

grtninja · 1 month ago

Windows corroboration, specifically affecting codex-security:

After a Codex Desktop update on Windows on 2026-06-24, the previously available Codex Security plugin disappeared from the Desktop plugin surface. The underlying account/program access had not intentionally been removed. Searching for the plugin and manually adding it again restored the surface.

This appears consistent with the built-in marketplace persistence failure described here, and suggests the impact is not limited to macOS or ordinary productivity plugins. For a security-program participant, disappearance of codex-security is especially confusing because it can look like entitlement or program access was revoked rather than a local plugin-persistence regression.

Available evidence:

  • screenshot of the Codex Security add/restore flow;
  • timestamped user chronology showing the plugin present before the update, absent afterward, and restored after manual re-add.

No private repository or account identifiers are included in this public comment. Please consider adding Windows coverage and a regression test specifically for codex-security@openai-api-curated persistence across update/restart.