Local/personal marketplace plugin is not discovered at runtime on Windows (Codex CLI 0.130.0)

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

Summary

On Windows with Codex CLI 0.130.0, a local plugin placed via the documented personal marketplace flow is still not discovered by a fresh Codex runtime.

This does not look specific to one plugin repo. We reproduced it with a third-party plugin (ECC) and also found several related Codex issues around marketplace registration, local plugin discovery, and plugin/runtime exposure.

The important point is that this was not only tested through codex plugin marketplace add .... We also tried the documented personal marketplace layout manually and Codex still did not recognize the plugin.

Environment

  • OS: Windows
  • Codex CLI: 0.130.0
  • Host usage: Codex desktop + local CLI/runtime (codex exec)

What we tested

Path A: plugin repo's own marketplace config

The plugin repo includes:

  • .agents/plugins/marketplace.json
  • .codex-plugin/plugin.json
  • skills/
  • .mcp.json

In this repo's shipped marketplace file, the plugin entry uses:

"source": {
  "source": "local",
  "path": "./"
}

That already looks close to #17066, so we did not stop there.

Path B: documented personal marketplace flow

We then bypassed the repo's own marketplace config and manually installed it using the personal marketplace layout described by Codex's plugin tooling/docs:

  • ~/.agents/plugins/marketplace.json
  • ~/plugins/ecc/
  • ~/plugins/ecc/.codex-plugin/plugin.json
  • ~/plugins/ecc/skills/
  • ~/plugins/ecc/.mcp.json

Personal marketplace entry used:

{
  "name": "personal",
  "interface": {
    "displayName": "Personal"
  },
  "plugins": [
    {
      "name": "ecc",
      "source": {
        "source": "local",
        "path": "./plugins/ecc"
      },
      "policy": {
        "installation": "AVAILABLE",
        "authentication": "ON_INSTALL"
      },
      "category": "Productivity"
    }
  ]
}

Expected behavior

A plugin installed via the documented personal marketplace layout should at least become discoverable to a fresh Codex runtime.

Even if not all capabilities are active yet, I would expect one of the following:

  • the plugin appears in the visible plugin set
  • the plugin produces a corresponding local plugin cache entry
  • there is a clear runtime error that the plugin was found but rejected

Actual behavior

After starting a fresh codex exec runtime:

  • the plugin did not appear in the visible plugin set
  • ~/.codex/plugins/cache/ did not gain a corresponding personal plugin cache entry
  • runtime still only exposed the pre-existing plugins already available on the machine

In our case, the fresh runtime still reported only the existing built-in/curated plugins, not ECC.

Additional signal that may matter

On this machine, codex plugin --help only shows:

  • marketplace

It does not expose subcommands like:

  • plugin add
  • plugin list

That seems inconsistent with the local plugin installation/update flow described by the built-in plugin tooling/docs, and may point to either:

  • version skew between CLI/runtime and plugin docs/tooling
  • platform/channel differences in plugin support
  • incomplete local plugin support in this release

Why I think this is not an isolated repo mistake

This looks related to a broader local plugin / marketplace discovery instability rather than only this plugin repo:

  • #17066 local marketplace path/root issue
  • #22078 local plugin/skills not exposed
  • #23902 marketplace written but not really consumed
  • #24736 plugins not appearing / No plugins found
  • #21791 plugin/runtime visibility mismatch

Main ask

Can you clarify whether local/personal marketplace plugins are expected to work on Windows in 0.130.0, and if so, what the canonical supported discovery path is for:

  • ~/.agents/plugins/marketplace.json
  • ~/plugins/<plugin-name>/
  • fresh runtime pickup in codex exec

Right now it is hard to tell whether this is:

  • unsupported/partial support in this version
  • a Windows-specific discovery bug
  • stale documentation/tooling around personal marketplaces
  • or a broader local plugin discovery regression

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

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

  • #24736

Powered by Codex Action

rendigua · 2 months ago

Follow-up after cleaning a self-inflicted false-install state:

I need to correct part of the earlier signal.

Some of the previous runtime loader failures were caused by a manually-forced pseudo-install state on my side:

  • I had manually added [plugins."ecc@personal"] enabled = true to ~/.codex/config.toml
  • I had also manually copied plugin files into ~/.codex/plugins/cache/personal/ecc

That produced misleading loader errors such as Codex trying to load from a bad path ending in ...\cache\personal\ecc\skills.

I have now removed that polluted state and re-tested from a clean baseline.

Clean baseline:

  • ~/.agents/plugins/marketplace.json still contains the ecc entry
  • ~/plugins/ecc still exists as the local plugin source
  • marketplaces.personal remains registered in ~/.codex/config.toml
  • the manual [plugins."ecc@personal"] entry was removed
  • the manual ~/.codex/plugins/cache/personal/ecc cache copy was removed

After that cleanup:

  • the previous ...\ecc\skills loader error disappeared
  • but ECC still does NOT become visible as a runtime plugin in either:
  • a fresh codex exec session
  • a fresh new Codex desktop thread
  • no ecc: plugin skills become visible
  • no ECC-related MCP tools become visible

So the refined conclusion is narrower and cleaner:

This no longer proves a broken installed plugin instance. Instead, it shows that on my current codex-cli 0.130.0 / Desktop build, a personal marketplace entry can be visible/registered without yielding an installed+runtime-visible plugin instance.

In other words:

  • marketplace discovery seems to work
  • runtime plugin installation/activation from that personal marketplace still appears missing, unavailable, or not exposed through an observable supported step in this version

Also still relevant:

  • on this machine codex plugin only exposes marketplace subcommands, not plugin add / plugin list
  • that makes it hard to map the documented/local marketplace model to an actual runtime installation flow in this release

So my current best problem statement is:

personal marketplace is discoverable, but I cannot identify a supported path in 0.130.0 that turns the personal marketplace entry into a runtime-visible installed plugin instance.

SylvainWinning · 2 months ago

The cleaned-up follow-up makes this issue much clearer. I think the useful distinction for maintainers is that there appear to be three separate states that are easy to conflate:

  1. Marketplace registered/discoverable: ~/.agents/plugins/marketplace.json and the configured marketplace entry can be found.
  2. Plugin installable/installed: a specific plugin entry can be selected and materialized into Codex's plugin cache/installed state.
  3. Runtime-visible capabilities: the installed plugin contributes skills/apps/MCP servers to a fresh CLI or Desktop session.

From the report, state 1 seems to be true, while there is no observable supported transition to states 2 and 3 on Windows / 0.130.0.

A narrow acceptance test for this could be a local-only personal marketplace fixture on Windows that verifies all three observations separately:

  • plugin/list includes the personal marketplace entry;
  • plugin/install or the documented CLI equivalent creates the expected installed/cache state;
  • a fresh runtime exposes at least one deterministic capability from that plugin, such as a sample skill or MCP server name.

If personal marketplace entries are intentionally only catalog entries until an explicit install step, the missing piece may just be documentation/CLI discoverability. If they are supposed to auto-materialize, then this looks more like a Windows activation/runtime pickup bug.