›_ Codex Issues
Codex Issues / #22078

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

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

Summary

A local marketplace plugin is enabled and its plugin manifest points to a valid skills directory, but Codex sessions do not expose the plugin's skills. This reproduces in Codex CLI and Codex App after multiple restarts.

This is currently blocking oh-my-codex plugin-mode usage without falling back to legacy skill installation.

Environment

codex-cli 0.130.0
oh-my-codex v0.16.3
macOS / arm64

Expected behavior

When a local marketplace plugin is configured and enabled, Codex should discover and expose the skills declared by the plugin manifest:

{
  "name": "oh-my-codex",
  "version": "0.16.3",
  "skills": "./skills/",
  "mcpServers": "./.mcp.json",
  "apps": "./.app.json"
}

In this case, skills such as team, ralph, deep-interview, ultrawork, wiki, etc. should be visible in a fresh Codex session.

Actual behavior

Only the legacy/user-installed omx-setup skill is visible. The rest of the oh-my-codex plugin skills are not exposed.

A fresh codex exec session shows only these matching skills:

omx-setup
compound-engineering:ce-plan
sophi:use-agent-team

Other plugin skills from non-local/plugin-cache sources, such as compound-engineering:*, sophi:*, browser-use:*, etc., are exposed correctly. The issue appears specific to this local marketplace plugin or its layout/discovery path.

Configuration evidence

Relevant ~/.codex/config.toml entries:

[marketplaces.oh-my-codex-local]
source_type = "local"
source = "/opt/homebrew/lib/node_modules/oh-my-codex"

[plugins."oh-my-codex@oh-my-codex-local"]
enabled = true

The plugin bundle exists and contains a valid manifest:

B=/opt/homebrew/lib/node_modules/oh-my-codex/plugins/oh-my-codex
node -e "const p=require('$B/.codex-plugin/plugin.json'); console.log(JSON.stringify({name:p.name,version:p.version,skills:p.skills,mcpServers:p.mcpServers,apps:p.apps}, null, 2))"

Output:

{
  "name": "oh-my-codex",
  "version": "0.16.3",
  "skills": "./skills/",
  "mcpServers": "./.mcp.json",
  "apps": "./.app.json"
}

The skills are physically present:

find /opt/homebrew/lib/node_modules/oh-my-codex/plugins/oh-my-codex/skills -maxdepth 2 -name SKILL.md | wc -l
# 26

omx doctor also reports the plugin-mode install as healthy:

Resolved setup scope: user
Resolved setup install mode: plugin
[OK] Skills: plugin marketplace oh-my-codex-local registered; OMX skills are supplied by /opt/homebrew/lib/node_modules/oh-my-codex/plugins/oh-my-codex
Results: 15 passed, 0 warnings, 0 failed

Reproduction

  1. Install and configure oh-my-codex in plugin mode.
  2. Ensure the local marketplace and plugin are enabled in ~/.codex/config.toml:

```toml
[marketplaces.oh-my-codex-local]
source_type = "local"
source = "/opt/homebrew/lib/node_modules/oh-my-codex"

[plugins."oh-my-codex@oh-my-codex-local"]
enabled = true
```

  1. Verify the plugin manifest has skills: "./skills/" and that the skills/*/SKILL.md files exist.
  2. Start a fresh Codex CLI or Codex App session.
  3. Ask the model to list visible skills, or inspect the model-visible skill list.

Observed: oh-my-codex plugin skills are missing.

Local marketplace commands tried

codex plugin marketplace add /opt/homebrew/lib/node_modules/oh-my-codex

Output:

Marketplace `oh-my-codex-local` is already added from /opt/homebrew/lib/node_modules/oh-my-codex.
Installed marketplace root: /opt/homebrew/lib/node_modules/oh-my-codex
codex plugin marketplace upgrade oh-my-codex-local

Output:

Error: marketplace `oh-my-codex-local` is not configured as a Git marketplace

Questions

  1. Are skills from source_type = "local" marketplaces expected to be loaded into Codex sessions?
  2. If yes, is the oh-my-codex local marketplace layout valid for Codex plugin discovery?
  3. Is there a required cache/install step for local marketplace plugins beyond codex plugin marketplace add <local-root> and [plugins."name@marketplace"].enabled = true?
  4. If this is a Codex loader bug, could Codex surface diagnostics explaining why a plugin's declared skills directory was skipped?

Why this matters

oh-my-codex plugin mode intentionally avoids legacy skill installation and relies on Codex plugin discovery for bundled skills. Falling back to legacy mode works around the symptom but defeats the plugin-mode path.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 2 months ago

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

  • #22051

Powered by Codex Action

alario-tang · 2 months ago

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.

JaeJunday · 11 days ago

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.

thavguard · 8 days ago

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.

thavguard · 8 days ago

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.

jmena1984 · 5 days ago

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.