Repository navigation
Windows stdio server: subprocess spawned inside a tool handler hangs forever when it inherits the server stdin (stdin=DEVNULL fixes) #3788
Description
What happens
A subprocess spawned from INSIDE a FastMCP tool handler (stdio server, Windows) hangs forever when the child inherits the server stdin — which is the default in subprocess.run/create_subprocess_exec if stdin is not set.
Repro (Windows, minimal)
FastMCP server (stdio) with a tool that spawns a trivial child (e.g. python -c "print(1)"):
subprocess.run([...])with inherited stdin → child never completes; tool call hangs (abort only via MCP idle-timeout — 30 min by default in Claude Code)- same call with
stdin=subprocess.DEVNULL→ completes in ~0.6 s
A/B tested with FastMCP pure (zero user imports) to rule out user code; also reproduced via asyncio.create_subprocess_exec on the event loop. The moment the child stops sharing the server jsonrpc stdin, everything works.
Suggested guard
Document/force stdin=DEVNULL for subprocesses spawned in handlers, or detach the child stdin by default in any subprocess helper the SDK provides — inheriting the protocol pipe is never what a tool wants.
Environment: Windows 11 (26200), Python 3.14, mcp/fastmcp stdio transport, Claude Code 2.1.310 host.
Activity
Ben-Home commentedon Oct 30, 2026
The suggested guard is right, and the reason it hangs is worth stating explicitly, because it changes what the SDK should promise.
In a stdio server, process stdin is the JSON-RPC transport. A child spawned with inherited stdin shares that same handle, so there are now two readers on one pipe. What the child's runtime does with it varies (the Windows launcher, node, or a shell may read ahead to buffer), and any read it performs consumes bytes the server transport was waiting for. The tool call then waits for a response the transport can no longer assemble, and the client waits behind it. DEVNULL works because it removes the second reader, not because the child was waiting for input.
Two things worth adding to the issue, both cheap to confirm:
On where the fix belongs, forcing DEVNULL inside the SDK is the safer default but it is a behaviour change, and anyone whose child legitimately reads the parent's stdin as data would be surprised. A middle path costs little:
The second one is what turns a 30 minute hang into a log line, and it needs no behavioural change to ship.