Windows local agent mode: plugin MCP stdio servers spawn with visible console windows, duplicated at app and session level

Environment

• Windows 11 Pro
• Claude Desktop (current as of 2026-08-04), local agent mode (Cowork)
• Plugin installed from a private GitHub repo via the account marketplace ("Add from a repository")
• Plugin declares three stdio MCP servers in mcp-servers.json via plugin.json's mcpServers key; each server is command: "uv", args: ["run", "--script", "${CLAUDE_PLUGIN_ROOT}/…/server.py"] (PEP 723 inline metadata)

The servers work — tools connect and run. These are behaviors of the spawn path itself.

1. Plugin MCP servers spawn with visible console windows

When a local agent mode session starts the plugin's stdio servers (lazily, at first tool use), each spawn opens a visible terminal window. The equivalent servers hand-registered in claude_desktop_config.json never showed windows — the app-level host hides them. The session-level spawn path appears to be missing windowsHide (or CREATE_NO_WINDOW) on its CreateProcess.

Because plugin servers are also torn down when the conversation turn ends and respawned at the next tool use, the windows recur on every run rather than appearing once at startup.

Verified it isn't the plugin's own child processes: every child spawn in the servers carries DETACHED_PROCESS | CREATE_NO_WINDOW, and GUI helpers run under pythonw.exe.

2. Duplicate server sets: app-level AND session-level

The same three plugin servers run twice simultaneously — one full set parented by the Desktop app process, a second set parented by the local-agent-mode session host:

uv.exe (parent: Desktop app)        -> venv python -> base python   (hidden)
uv.exe (parent: agent session host) -> venv python -> base python   (visible console)

MCPB extension servers show the same duplication. For servers with background state this doubles resource use and creates concurrent-instance hazards (we added a per-resource file lock to cope).

3. (Context) Turn-end teardown drains only in-flight requests

On turn end the session host closes the server's stdio; FastMCP-style servers drain in-flight requests but exit ~1s later otherwise. Any fire-and-forget background work inside the server process dies mid-run. We probe-verified this and redesigned around it (work moved to a detached child process), but documenting the lifecycle for plugin authors would help: plugin-declared servers are connection-scoped in local agent mode, unlike claude_desktop_config.json servers which are app-lifetime.

Expected

• Session-spawned plugin MCP servers hidden like app-level ones (windowsHide: true).
• One server instance per declared server, or documentation that duplicates are by design.
• Documented lifecycle guidance for plugin stdio servers in local agent mode.