Summary
I validated ECC on Codex specifically and hit two separate layers of problems:
- 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.
- 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:
- land/finalize the Codex marketplace layout fix
- make the Codex README/plugin section more explicit about current fragility
- 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.
Summary
I validated ECC on Codex specifically and hit two separate layers of problems:
"path": "./"), which is already known to be problematic for Codex local marketplace discovery.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:
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:
What I tested
Path A: ECC repo's own Codex marketplace config
ECC currently ships:
.agents/plugins/marketplace.json.codex-plugin/plugin.jsonskills/.mcp.jsonThe marketplace entry uses:
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.jsonThe 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:
ECCas a visible pluginpersonalplugin cache appeared under~/.codex/plugins/cache/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 entryEven 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:
Suggested outcome
I think the best ECC-side outcome would be:
Environment
0.130.0codex execMain 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.