Local marketplace plugin is enabled but its plugin skills are not exposed in Codex sessions

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

• #22051

Powered by Codex Action

Thanks for the duplicate pointer. I checked #22051 and it looks related at the plugin discovery/cache layer, but I don't think this issue is an exact duplicate.

Key differences:

• #22051 is about the bundled Chrome plugin on Windows Codex App, where the plugin is missing from the Plugins UI / regenerated bundled marketplace cache.
• This issue reproduces on macOS with a third-party/local marketplace plugin (oh-my-codex-local).
• The local marketplace is already configured and the plugin is enabled in ~/.codex/config.toml.
• The plugin manifest is valid and declares skills: "./skills/".
• The plugin bundle physically contains 26 SKILL.md files.
• The failure is specifically that fresh Codex sessions do not expose those plugin skills as model-visible skills in CLI/App.

So the shared root may be plugin discovery, but this issue is specifically about local marketplace plugin skill discovery / model-visible skills, not only App plugin UI listing or bundled marketplace cache generation.

I reproduced the same issue with an official openai-curated plugin.

Environment

• macOS arm64
• codex-cli 0.144.0-alpha.4
• ChatGPT authentication
• superpowers@openai-curated
• Local plugin version 5.1.3, marketplace revision 2f1a8948

Findings

• config.toml contains [plugins."superpowers@openai-curated"] enabled = true.
• codex plugin list reports the plugin as installed, enabled.
• plugin/read returns all 14 Superpowers skills with enabled: true.
• In the same fresh app-server process, skills/list with forceReload: true returns no superpowers:* skills.
• The errors array is empty.
• A fresh codex exec process also reports that no Superpowers skills are available.
• Removing the plugin and reinstalling it from the official marketplace initially produced the same result.

In other words, the plugin details API reports a healthy plugin and complete skill inventory, while the model-visible skill catalog silently omits the entire plugin.

Workaround and isolation

I linked each Superpowers skill directory into ~/.codex/skills/<skill-name>. After that, codex debug prompt-input included all 14 namespaced skills again, for example:

superpowers:brainstorming
superpowers:requesting-code-review
superpowers:systematic-debugging
...

The model-visible paths still point to the original marketplace files under plugins/superpowers/skills/.../SKILL.md. This suggests that the SKILL.md files and Superpowers manifest are valid, and that the failure is in propagating the installed plugin's skill roots into the session skill loader.

Possible source-level failure point

On current main, skills/list follows this path:

PluginsManager::effective_skill_roots_for_layer_stack()
→ PluginLoadOutcome::effective_plugin_skill_roots()
→ SkillsLoadInput

effective_plugin_skill_roots() skips all skill roots for an otherwise active plugin when plugin_namespace is absent. I have not directly inspected that internal runtime value, so this is only a hypothesis, but it is one concrete point where plugin/read and skills/list could diverge without producing a skill loading error.

Suggested regression coverage

• Install a local or curated marketplace plugin through the real plugin store/cache layout.
• Declare skills: "./skills/" in its manifest.
• Assert that plugin/read and skills/list(forceReload: true) expose the same enabled skills.
• If an enabled plugin declares skills but produces zero effective skill roots, surface the reason through errors or diagnostics instead of silently dropping it.

If a maintainer confirms the intended fix and explicitly invites an external PR, I can prepare the regression test and implementation within that scope.

Confirmed on the current stable release after a clean official-only setup.

Environment

• macOS arm64
• codex-cli 0.144.1 (matches npm view @openai/codex version)
• ChatGPT authentication
• no source_type = "local" marketplace
• no personal marketplace, no symlinked/user-installed copies of curated skills

Enabled official curated plugins:

superpowers@openai-curated
build-web-apps@openai-curated
github@openai-curated
sentry@openai-curated

codex plugin list reports every one as installed, enabled from the official openai-curated marketplace.

Reproduction and observed result

1. Remove personal/local marketplace configuration and stale openai-curated-remote cache.
2. Reinstall the plugins only through openai-curated.
3. Start a fresh process:

codex debug prompt-input -C /path/to/repo

The resulting model-visible skills list contains 42 ordinary system/runtime/repo-local skills, but zero entries matching superpowers, build-web-apps, github:, or sentry:.

The same result occurs with codex exec --strict-config --ephemeral.

Why this is not only a skill-metadata budget issue

I initially had six curated plugins. I removed the two largest optional plugins (build-web-data-visualization and codex-security), reducing the enabled curated set to the four above. Plugin skill descriptions were well below the documented fallback budget, yet all curated skills remain absent while non-plugin skills remain visible.

The plugin state and the model-visible skill catalog therefore still diverge on the current stable release, even for the official curated marketplace and without a local marketplace layout.

A useful regression test would install an official curated plugin in a clean temporary CODEX_HOME and assert that its declared skill roots appear in codex debug prompt-input / skills/list. Diagnostics should explain an omitted enabled plugin skill root rather than returning an empty skill set without errors.

Additional diagnostic correlation: this report was reproduced and validated in Codex thread ID 019f5789-761a-7a60-a64f-185ccd1ab791.

For temporary mitigation, globally symlinking each enabled official curated plugin skill directory into ~/.codex/skills/ made all 25 skills appear in a fresh codex debug prompt-input process. The displayed sources still resolve to the official openai-curated plugin directories. This reinforces that the manifests and SKILL.md files are valid; the missing step is plugin skill-root propagation into the normal loader.

Confirmed on Windows with the official curated GitHub plugin, including the current stable CLI.

Environment

• Windows 11 / x86_64
• VS Code Codex extension 26.707.71524
• Bundled CLI: codex-cli 0.144.2
• Also reproduced with standalone @openai/codex 0.144.4
• ChatGPT authentication
• GitHub plugin: github@openai-curated
• Plugin manifest version 0.1.6, marketplace revision 2f1a8948

Observed state

• codex plugin list --json reports github@openai-curated installed and enabled.
• Its manifest declares four skills: github:gh-address-comments, github:gh-fix-ci, github:github, and github:yeet.
• A fresh child prompt contains 96 total skills, including 11 managed-plugin skills, but contains 0/4 GitHub skills.
• Explicit invocation does not change the result:

codex debug prompt-input '@github' | Select-String 'github:'
# no matches

• The app-hosted session can expose the four GitHub skills through its managed plugin surface, so the failure is specifically a divergence between installed/app-visible declarations and the fresh child-CLI prompt catalog.

Controls attempted

All of these still returned 0/4 GitHub skills:

1. Updated the VS Code extension and restarted/reloaded the host.
2. Tested the bundled CLI and the current standalone CLI (0.144.4).
3. Removed and re-added github@openai-curated through codex plugin remove/add.
4. Repeated with explicit @github invocation.
5. Verified GitHub CLI authentication.
6. Repeated with GITHUB_PAT_TOKEN injected only into the probe process.
7. Confirmed apps, plugins, and remote_plugin feature flags are enabled.

No manual cache edits or symlink workaround were used. The repository configuration and plugin declaration remained valid.

This independently reproduces the official-curated case on Windows and shows that the omission is not caused by GitHub authentication, the bundled CLI version, a stale plugin install, or lack of explicit invocation. Ideally, an enabled plugin with declared skills should either contribute those roots to skills/list / debug prompt-input, or emit a diagnostic explaining why each root was excluded.

This is what happens to superpowers plugin's skills on OpenAI Codex (v0.147.0):

<img width="1980" height="525" alt="Image" src="https://github.com/user-attachments/assets/a0c62762-c492-4a63-b3b8-5d3fe9c4edf7" />

<img width="243" height="159" alt="Image" src="https://github.com/user-attachments/assets/d16bdfeb-c51c-433c-a5a8-4b310d259ec6" />

---

This is on claude code with the same plugin:

<img width="756" height="310" alt="Image" src="https://github.com/user-attachments/assets/ae234c01-689d-4d7d-aee8-fab420c6ea86" />

Reproduced on a newer stable Codex release with a minimal Skills-only local Plugin.

Environment

• Linux
• codex-cli 0.149.1
• Plugins feature enabled/stable
• local marketplace
• one bundled Skill

Packaging validation

The Plugin used the canonical plural Skill layout:

{
  "name": "deslop",
  "version": "0.2.0",
  "skills": "./skills/"
}

with one ordinary bundled Skill:

skills/deslop/SKILL.md

Plugin Creator validation passed.

For comparison, an earlier manifest using skills: "./skill/" failed the static check with:

plugin.json field skills must resolve to skills

Changing the package to ./skills/ resolved that static validation error, but did not resolve runtime Skill registration.

Installation succeeds

Local marketplace discovery succeeded. Plugin installation succeeded, and Codex reported the Plugin as installed, enabled, and version 0.2.0.

The Plugin cache contained the declared payload, including:

.codex-plugin/plugin.json
skills/deslop/SKILL.md
skills/deslop/agents/...
skills/deslop/references/...

A sanitized equivalent cache location is:

$CODEX_HOME/plugins/cache/<marketplace>/deslop/0.2.0/skills/deslop/SKILL.md

Native Skill registration still fails

I isolated the test from standalone Skill discovery:

1. Moved the ambient standalone deslop Skill completely outside the Skill discovery root.
2. Used a unique temporary marketplace/cache identity.
3. Started a disposable Git repository with no repository-local deslop Skill.
4. Started a fresh app-server process/session.
5. Called the native skills/list(forceReload=true) API.

The relevant catalog projection was:

{"deslop":[],"errors":[]}

(The protocol response may include unrelated fields depending on API version.) The installed Plugin cache contained the Skill, but the native host catalog did not register it and surfaced no relevant loading error. No filesystem search or manual reading of the Plugin cache was used to establish this result.

Standalone control

The same runtime Skill works through ordinary standalone/repository Skill discovery. In an isolated repo-local test, the host reported:

name=deslop
enabled=true
scope=repo

and loaded the same skills/deslop/SKILL.md successfully.

This appears to reproduce the same Plugin-to-session Skill propagation failure tracked here. The evidence narrows the boundary to Plugin Skill registration/propagation rather than Plugin installation, cache creation, Skill validity, or the plural package layout.

Plugin packaging was withheld from the project release rather than adding a duplicate runtime or compatibility workaround.