Python FastMCP server (STDIO) exits immediately on Windows — Not connected

[cioffiAI]

Bug Description

A Python FastMCP server (mcp.server.fastmcp.FastMCP) exits immediately (~1 second after startup) when launched by opencode as a local MCP server via STDIO transport, returning "Not connected" on every tool call. The same server works perfectly when tested manually via subprocess with JSON-RPC over stdin/stdout.

Steps to Reproduce

1. Create a Python FastMCP server (mcp==1.27.0)
2. Install as a CLI tool (uv tool install .) or run directly
3. Configure in opencode.jsonc as local MCP server
4. Start opencode — first tool call works, then all subsequent tool calls return "Not connected"
5. Server logs show: startup messages followed by immediate exit with no errors

Manual Test (PASSES — server works correctly)

The same server, when tested manually via subprocess, passes all MCP protocol operations:

• initialize → protocolVersion: 2024-11-05
• tools/list → all tools returned
• tools/call → all tool calls succeed
• Process stays alive indefinitely when stdin/stdout are properly piped

Environment

• OpenCode version: current dev
• OS: Windows 11 (PowerShell 5.1)
• Python: 3.13
• MCP SDK: 1.27.0 (mcp.server.fastmcp)
• Server transport: STDIO

Additional Context

• The "Not connected" string is NOT present in the server source code — it comes from opencode's MCP client layer
• The server binary wrapper (uv tool install .exe) works correctly when tested with subprocess.Popen
• Other STDIO MCP servers (GitHub, Playwright via npx) work fine on the same machine
• This appears to specifically affect Python-based MCP servers on Windows
• Related: fix(mcp): MCP server loses connection mid-session causing intermittent failures #23997 (different pattern — loses mid-session, not immediate), PR fix(mcp): detect transport close and update status to failed #24955

Key Finding

The Python MCP server process is being killed by opencode shortly after startup, before it can properly initialize the STDIO transport. The server never gets a chance to respond to the initialize handshake.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• MCP stdio transport sends batched requests without proper flush, breaking local servers #21516: MCP stdio transport sends batched requests without proper flush, breaking local servers (same pattern: local MCP server works correctly when tested manually via subprocess, but fails when launched through OpenCode's MCP stdio client — tool calls either fail or the server exits early)
• MCP Subsystem entirely unresponsive on Windows Desktop App (/config loads, but /mcp times out) #16449: MCP Subsystem entirely unresponsive on Windows Desktop App (Windows-specific MCP failure where servers work fine standalone but fail inside OpenCode)

If your issue is the same, please consider adding any additional details as a comment on those existing issues rather than opening a new one.