›_ Codex Issues
Codex Issues / #38342

[macOS Desktop] Enabled plugin skill is injected but its stdio MCP tools are absent after full restart

Open 💬 4 comments Opened Aug 13, 2026 by carriee6
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

0.147.0-alpha.6.5

What model / provider were you using?

Default OpenAI GPT model (not a custom provider).

What platform are you using?

macOS, Codex Desktop.

What issue are you seeing?

A Git marketplace plugin is enabled and its skill is injected into a newly created Desktop task, but the stdio MCP server declared by that same plugin is not exposed in the task's tool inventory.

Concrete reproduction: Cowart 0.1.25 from zhongerxin/Cowart.

The skill cowart-open-canvas is available and instructs the agent to call render_cowart_canvas_widget. The plugin manifest correctly declares .mcp.json, which defines a cowart_mcp stdio server. However, the current task has no callable cowart_mcp / render_cowart_canvas_widget tool, so the native canvas cannot open.

This survives fully quitting Codex Desktop, reopening it, and creating a brand-new task twice. The plugin/cache is current, enabled, and points at the latest upstream commit.

Environment / evidence

  • Plugin: cowart@cowart-github, enabled = true
  • Marketplace: https://github.com/zhongerxin/Cowart.git, ref main
  • Cowart version: 0.1.25
  • Installed commit: 6a338f016dee21fd97346c5fd8fe1bd81b1a7522; matches origin/main
  • Cowart skill is visible in the task environment.
  • The expected MCP tool is absent from the task environment/tool discovery.
  • The plugin's MCP probe can launch the server and enumerate/reach its core tools outside the Desktop task surface. A later probe assertion that writes a sample download to ~/Downloads fails under this sandboxed diagnostic environment, but that is unrelated to the missing-tool symptom.
  • Active provider is OpenAI, ruling out the custom Responses-provider unsupported call issue.

Steps to reproduce

  1. Register zhongerxin/Cowart as a Git marketplace and install/enable cowart@cowart-github.
  2. Fully quit Codex Desktop.
  3. Reopen Codex Desktop and create a new task.
  4. Ask: Open the Cowart canvas for this project.
  5. Observe that the skill is injected, but the task does not expose mcp__cowart_mcp__render_cowart_canvas_widget (or any Cowart MCP tool).

Expected behavior

When a plugin skill is loaded into a new Desktop task, its declared stdio MCP server should be started/discovered and its tools should be available in that task (or dynamically discoverable).

Actual behavior

Skills and MCP tool exposure are inconsistent: the skill is available, while the associated server tools are missing even after the documented restart/new-task recovery flow.

Related issues

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 15 days ago

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

  • #37036
  • #38162

Powered by Codex Action

dajiaohuang · 14 days ago

I reproduced a core-side version of this on current origin/main at a7b8c074b577f897111c14de3a5e127b91e2a479 using only the repository's synthetic stdio MCP server, initialization barrier, and test credentials -- no Cowart installation or real account state.

For account context, I use Codex on a Pro 20x subscription.

The observed sequence is:

  • the first request already includes the plugin skill in the skills catalog;
  • the plugin's optional MCP server is still pending during binding capture;
  • after the existing 1-second optional-MCP grace period, mcp__sample::echo is omitted from that turn's tool catalog;
  • once the same MCP becomes ready, the next turn in the same task can discover the tool;
  • the existing explicit plugin mention, structured skill call, mcp:// mention, and link-mention paths all wait for readiness and pass.

The relevant split appears to be that required_mcp_servers_for_input promotes only explicit plugin/skill/MCP selections, while ordinary natural-language use of an already-injected plugin skill leaves its MCP optional. capture_binding_with_metadata can therefore permanently bind the first turn without the tool even though the skill tells the model to call it.

This does not appear to be a strict duplicate of #38162: that report observes initialize and tools/list completing before tools are omitted, while this reproduction captures the MCP still pending at first binding. #37036 also appears to involve project-specific Desktop capability/config assembly rather than this proven readiness boundary.

Could maintainers clarify the intended fix direction?

  1. Refresh the task's MCP/tool binding when an optional server becomes ready, so tool_search can discover it in the same turn.
  2. Treat an enabled plugin MCP as required whenever that plugin contributes a visible skill to the turn.
  3. Keep optional startup non-blocking, but suppress or qualify the skill until its required tools are reachable.

The main tradeoff is first-turn latency versus catalog consistency: making every skill-contributing MCP required could block on the slowest plugin, while dynamic binding refresh is narrower but must preserve per-turn tool-directory invariants.

If maintainers choose a direction and would find an external regression test/fix useful, please explicitly invite the contribution under the repository's policy.

dajiaohuang · 14 days ago

I did not open an upstream PR because the contribution policy says external PRs are invitation-only. I prepared a tested draft at https://github.com/dajiaohuang/codex/pull/1.

It implements the smallest catalog-consistency option from the earlier analysis: an enabled plugin MCP becomes required when that plugin contributes a visible skill. The focused first-turn regression passes with MCP initialization held beyond the old optional grace period. The draft also calls out the slow-plugin latency tradeoff and the dynamic-refresh/suppressed-skill alternatives.

If this direction fits the team's architecture, an invitation would let me submit it through the project's normal review process.

wanou2c · 14 days ago

+1. Same root cause on Windows with remote HTTP MCP servers (Lingxing + SellerSprite) on Codex Desktop 26.803.81509 / engine 0.147.0-alpha.6.6. The MCP handshake and tools/list succeed, but the tools are omitted from the task's tool catalog with the log line omitting MCP server without an exact ready client. Reproduces with both direct Streamable HTTP URLs and a local stdio proxy in front of the same servers; the same config works on 26.803.41515 and in Codex CLI.

Additional data point for the root cause: our model catalog already sets "use_responses_lite": false, so the workaround from #33679 does not apply here ? consistent with the catalog-consistency race described above rather than the Responses Lite tool-exposure path. The proposed fix direction (treat an enabled plugin's MCP as required when it contributes a visible skill) matches what we observe; please consider inviting the draft.