Summary

codex plugin marketplace add affaan-m/ECC and codex plugin add/list now report ecc@ecc as installed and enabled on Codex CLI 0.139.0, but the installed plugin cache only contains the plugin folder files (README.md and .codex-plugin/plugin.json). The manifest still references shared repo content via parent-relative paths such as ../../skills/, ../../.mcp.json, and ../../assets/..., and those paths do not exist from the installed cache location.

This leaves the user with a confusing state: Codex says the ECC plugin is installed/enabled, but a fresh Codex runtime does not expose ECC as a loaded plugin/capability surface. ECC skills were only available in my session from an existing manual/global .agents/skills install path, not from the Codex plugin runtime.

This appears related to the already-documented fragility in #2128 / openai/codex#26037, but this is a current repro on Codex CLI 0.139.0 with a concrete installed-cache symptom.

Environment

• OS: Linux
• Codex CLI: codex-cli 0.139.0
• ECC plugin version: 2.0.0
• Marketplace command used: codex plugin marketplace add affaan-m/ECC
• Repo: affaan-m/ECC, default branch main
• Observed at: 2026年06月13日T06:20:18Z

Reproduction

codex plugin marketplace add affaan-m/ECC
codex plugin list

codex plugin list reports:

Marketplace `ecc`
/home/hamza/.codex/.tmp/marketplaces/ecc/.agents/plugins/marketplace.json
PLUGIN STATUS VERSION PATH
ecc@ecc installed, enabled 2.0.0 /home/hamza/.codex/.tmp/marketplaces/ecc/plugins/ecc

The installed plugin cache contains only:

/home/hamza/.codex/plugins/cache/ecc/ecc/2.0.0/.codex-plugin/plugin.json
/home/hamza/.codex/plugins/cache/ecc/ecc/2.0.0/README.md

The cache manifest still contains:

{
 "skills": "../../skills/",
 "mcpServers": "../../.mcp.json",
 "interface": {
 "composerIcon": "../../assets/ecc-icon.svg",
 "logo": "../../assets/hero.png"
 }
}

From the installed cache location, those paths do not resolve:

test -d /home/hamza/.codex/plugins/cache/ecc/ecc/2.0.0/../../skills; echo $?
test -f /home/hamza/.codex/plugins/cache/ecc/ecc/2.0.0/../../.mcp.json; echo $?
test -f /home/hamza/.codex/plugins/cache/ecc/ecc/2.0.0/../../assets/ecc-icon.svg; echo $?

Observed result:

1
1
1

Expected behavior

After codex plugin list reports ecc@ecc as installed, enabled, one of these should be true:

1. The installed plugin cache contains all files referenced by .codex-plugin/plugin.json, including skills, MCP config, and assets.
2. The manifest uses paths that resolve inside the installed cache.
3. The plugin install/list docs clearly warn that this path is discovery-only today and does not imply runtime skill loading until the upstream Codex plugin cache behavior changes.

Actual behavior

• ecc@ecc appears installed and enabled.
• The plugin cache does not contain the manifest-referenced skills/MCP/assets.
• A fresh Codex runtime does not expose ECC plugin capabilities as expected from an installed/enabled plugin.
• Users can mistake this for a successful ECC runtime install, then look for commands/skills that are not actually loaded from the plugin.

Why this matters

The current README correctly says Codex plugin mode is experimental/fragile and recommends the manual sync flow, but the CLI success state is still misleading. A user following the Codex marketplace commands can end up with an apparently enabled plugin that has unresolved runtime references.

For major recovery/autonomous workflows, this matters because the user needs to know whether ECC is actually active as a plugin or only present as manually synced instructions/skills.

Suggested fixes

Possible ECC-side options:

• Package the Codex plugin folder so the installed cache includes the skills/MCP/assets it references.
• Change the plugin manifest to reference content that is copied into the installed plugin cache.
• Add a Codex plugin health check script/docs step that verifies the cache-resolved paths after install.
• Make the README wording around codex plugin list # ecc@ecc should appear explicit that this is not sufficient proof of runtime skill loading.

I realize part of this may remain upstream in Codex plugin caching/runtime discovery, but ECC can still reduce the false-success state or document a deterministic post-install check.