Skip to content

Codex plugin path is still unreliable: repo marketplace uses ./, and docs should warn about current local plugin discovery limits #2128

Description

@rendigua

Summary

I validated ECC on Codex specifically and hit two separate layers of problems:

  1. ECC's shipped Codex marketplace entry still uses a repo-root local plugin path ("path": "./"), which is already known to be problematic for Codex local marketplace discovery.
  2. Even after bypassing that and manually installing ECC through Codex's documented personal marketplace layout, Codex still did not discover the plugin at runtime.

So this is not a report saying ECC alone is broken. The bigger runtime blocker looks upstream in Codex plugin discovery. But ECC still has a repo-side compatibility/documentation problem worth fixing:

  • the bundled Codex marketplace layout is not a safe default for current Codex behavior
  • the docs should be clearer that plugin mode is currently fragile on Codex, and that the non-plugin/manual path is the safer route for now

Why I am filing this here as well

I already filed the upstream Codex issue here:

That issue focuses on Codex local/personal marketplace plugin discovery.

This ECC issue is narrower:

  • ECC's shipped Codex marketplace config is currently not a safe default for Codex users
  • README/plugin instructions should better separate:
    • ECC-side marketplace/layout assumptions
    • Codex-side plugin discovery instability

What I tested

Path A: ECC repo's own Codex marketplace config

ECC currently ships:

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

The marketplace entry uses:

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

That matches the general Codex problem reported upstream around repository-root local plugin paths.

Path B: bypass ECC's marketplace file and use Codex personal marketplace layout manually

I then bypassed the shipped marketplace file and used the Codex personal marketplace layout manually:

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

The 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"
    }
  ]
}

Actual result

Even after the manual/personal install layout was placed correctly:

  • fresh Codex runtime still did not expose ECC as a visible plugin
  • no corresponding personal plugin cache appeared under ~/.codex/plugins/cache/
  • runtime still only exposed the pre-existing built-in/curated plugins

So the final runtime failure looks upstream.

But ECC still has a repo-side issue

From the ECC side, I think there are still two actionable improvements:

1. Avoid "path": "./" for the Codex local marketplace entry

Even if upstream Codex gets fixed, this repo-root path choice is already known to be brittle for Codex.

A Codex-friendly local marketplace shape should point to a real plugin subdirectory target instead of repository root.

There is already an open PR that looks relevant:

So this report may align with that direction.

2. Make the README / Codex install story more explicit

Right now the plugin path is presented as convenient, but for Codex users the docs should probably be more explicit that:

  • plugin mode may currently fail due to Codex local marketplace/plugin discovery limitations
  • the manual/non-plugin Codex installation path is the safer path today
  • if plugin mode is retained in docs, it should be clearly labeled as depending on upstream Codex plugin support behaving correctly

Suggested outcome

I think the best ECC-side outcome would be:

  1. land/finalize the Codex marketplace layout fix
  2. make the Codex README/plugin section more explicit about current fragility
  3. link or mention the upstream Codex blocker where relevant so users do not assume ECC alone is misconfigured

Environment

  • Windows
  • Codex CLI 0.130.0
  • Codex Desktop + local codex exec

Main point

This is not "ECC is definitely broken." The runtime blocker appears to be mostly Codex-side.

But ECC can still improve the default Codex plugin layout and documentation so users are not guided into a path that is currently known to be fragile.

Activity

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

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions