Skip to content

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

Open
Open
[macOS Desktop] Enabled plugin skill is injected but its stdio MCP tools are absent after full restart#38342
Labels
appIssues related to the Codex desktop appbugSomething isn't workingmcpIssues related to the use of model context protocol (MCP) serversskillsIssues related to skills

Description

@carriee6
carriee6
opened on Aug 13, 2026

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

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    mcpIssues related to the use of model context protocol (MCP) servers
    skillsIssues related to skills
    on Aug 13, 2026

  2. github-actions commented on Aug 13, 2026

    @github-actions
    github-actionsBot
    on Aug 13, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. dajiaohuang commented on Aug 13, 2026

    @dajiaohuang
    dajiaohuang
    on Aug 13, 2026

    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.

  4. dajiaohuang commented on Aug 13, 2026

    @dajiaohuang
    dajiaohuang
    on Aug 13, 2026

    Policy update (2026-08-21): the repository now states that it does not accept external code contributions or pull requests. The tested fork Draft remains available only as a technical reference; I am not requesting an invitation or upstream submission.

    The reference is dajiaohuang#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 records the slow-plugin latency tradeoff and the dynamic-refresh/suppressed-skill alternatives.

  5. wanou2c commented on Aug 14, 2026

    @wanou2c
    wanou2c
    on Aug 14, 2026

    +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.

  6. JiajiaPig1124 commented on Aug 29, 2026

    @JiajiaPig1124
    JiajiaPig1124
    on Aug 29, 2026

    Reproduced on macOS with Codex Desktop 26.825.31414 / bundled codex-cli 0.148.0 after reinstalling the local plugin and fully restarting the app.

    Additional data point: this also affects custom agent definitions that contain their own [mcp_servers.<name>] stanza. The custom agent's developer_instructions are loaded, so the agent definition is recognized, but its configured stdio MCP namespace is completely absent from the agent's tool inventory. This reproduced with two different custom agent roles.

    Controls:

    • The exact MCP command starts successfully over stdio; the same profile also starts over HTTP.
    • The TOML parses and the custom agent instructions are loaded.
    • A fresh agent/task still exposes zero tools from the configured server.
    • No MCP startup or binding error is surfaced in the agent.

    Expected: when a custom agent definition is loaded, its configured MCP server tools should be mounted/discoverable, or Codex should surface a startup/binding error.

  7. ZygimantasKoncius commented on Sep 1, 2026

    @ZygimantasKoncius
    ZygimantasKoncius
    on Sep 1, 2026

    Reproduced on macOS with Codex Desktop 26.820.60940 (bundle 7119). Logs identify the bundled app-server client as 0.150.0-alpha.8.

    The affected MCP server is an authenticated Streamable HTTP gateway exposing several hundred downstream tools. A plugin skill was visible, but the gateway’s tools were absent from the task.

    The logs repeatedly showed:

    omitting pending optional MCP server server_name=dh-gateway

    Reauth completed and Codex successfully loaded the gateway credentials from Keychain. Restarting the task and sending additional turns still produced no tools. The gateway subsequently initialized successfully with MCP protocol 2025-06-18, and a later task used its tools successfully without another authentication change.

    This confirms that authentication and the MCP server were healthy. The failure was the task’s tool binding being captured while the optional server was pending and not being refreshed when it became ready.

    Impact: Codex repeatedly told the user that the integration was disconnected, causing unnecessary reauthentication and four task restarts.

    Expected behavior:

    • When an enabled plugin contributes a visible skill, its required MCP server should be ready before that skill is exposed; or
    • The task’s tool binding should refresh when the server becomes ready; and
    • Codex should report “server is still starting” rather than presenting the integration as disconnected.

    This appears to match the optional-server startup race described in this issue’s existing analysis.

  8. EdgarZev commented on Oct 7, 2026

    @EdgarZev
    EdgarZev
    on Oct 7, 2026

    I’m seeing a similar symptom with Microsoft Power Apps Canvas Authoring while using Codex tasks through ChatGPT on macOS.

    The Canvas skills and MCP configuration are present, but tasks report that connect, sync_canvas, compile_canvas and live App Checker are unavailable. We’ve encountered this on a MacBook Pro and an Intel 12-inch MacBook. The tools previously worked on the Pro, including successful source sync and validation, then became unavailable again.

    On the Intel Mac, .NET SDK 10.0.401 and the Canvas Authoring 1.1.5 package are present locally. The running server version has not been verified. An app update and restart/reconnect attempts haven’t restored tool availability there.

    This is blocking ongoing development. I’m not certain it has the same root cause as this issue. What diagnostic information would help distinguish a server startup failure from tools failing to appear in the task?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingmcpIssues related to the use of model context protocol (MCP) serversskillsIssues related to skills

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions