[BUG] Cowork: plugin stdio MCP server that exits at spawn is silently classified "needs auth" — stderr discarded, no error surfaced anywhere

Summary

In a Cowork (local agent mode) session, a marketplace plugin's stdio MCP server that exits immediately at spawn is silently classified as "needs auth" — no error is surfaced anywhere (not in the UI, not in the session, not in any log), the process's stderr is discarded, and the plugin detail page's Connectors tab shows only read-only command/args with the caption "Connect each one so Claude can use it" but no Connect action. The session's model just sees no tools and has no way to diagnose why.

Environment

• Claude Desktop 1.20186.0, macOS 26.5.1 (arm64)
• Claude Code CLI 2.1.206 (for comparison behavior)
• Plugins installed from a personal git marketplace via the desktop plugin browser (server-side install; materialized per-session under local-agent-mode-sessions/<ids>/rpm/plugin_<id>/)

Steps to reproduce

1. Publish a marketplace plugin whose .mcp.json declares a stdio server whose command starts, prints an error to stderr, and exits non-zero within ~100ms. (Ours was a uv run --script <launcher>.py … wrapper that printed ERROR: … not installed and exited 1 — but any fast-exiting command reproduces it.)
2. Install the plugin in the desktop plugin browser.
3. Start a Cowork chat.

Observed

• The spawn does happen (we verified via uv's script-environment cache dirs, created at the exact session-start second).
• Within ~130ms of session start, every such server is written to the session's .claude/mcp-needs-auth-cache.json (keys like plugin:<plugin-name>:<server-name>).
• The server's stderr appears in no log we could find (main.log, coworkd.log, cowork_vm_*.log, the session directory). Desktop-config (claude_desktop_config.json) servers by contrast get per-server mcp-server-<name>.log files that capture stderr — plugin servers get nothing.
• The plugin detail page → Connectors tab lists the servers with the caption "Tools and data sources this plugin connects to. Connect each one so Claude can use it." — but clicking a row shows only a read-only view of command/args. There is no connect action, no status, no error.
• The session's model sees no tools from the plugin and no diagnostic.

Expected

• A stdio server that exits before completing the MCP handshake should be classified "failed" (per the status vocabulary in the Agent SDK docs), not "needs auth" — there is no auth flow a user could perform for a local stdio process.
• Its stderr should be captured and surfaced somewhere (the per-server log treatment desktop-config servers already get would be enough).
• The Connectors tab should reflect the real state (failed + reason) instead of a caption implying a connect flow that doesn't exist for stdio.

Related

• #66183 — Windows sibling: plugin node servers spawn via system PATH only and fail silently (same diagnosability hole, different root cause).
• #56889 — docs gap on "needs-auth" vs "failed" semantics; this issue is an instance of the distinction being wrong in practice.
• #75972 — same silent-failure pattern for plugin hooks.json (no error, no registry evidence).