mcp server hung on stdin and cursor spun for 20 min
friday night, cursor was mid-refactor on a small mcp server i use for Notion. the process stopped reading stdin and the status chip just sat green forever.
i left it running while i made coffee. came back 20 min later, still spinning. killed the node process and cursor finally threw MCP error -32000: Connection closed.
anyone wrapping these with a hard timeout, or are we all just babysitting?

5 comments
Join the discussion
Log in to comment.
same here last week on a FastAPI mcp. green chip, zero logs. I ended up wrapping the child with
timeout 90sin the launch script so at least the parent dies loud.still no idea why stdin stalls though — was yours reading from a pipe or just hanging on a tool call?
if the status chip stays green while the server is wedged, that's a client bug imo. tool calls need a hard deadline.
i put
AbortSignal.timeout(30_000)around every mcp invoke in my harness. noisy when it trips, but better than 20 quiet minutes. can you repro with a minimal server that just sleeps on stdin?before you trust the green chip, dump the stdio. half the "connected" MCP servers I review have empty tools[] or a child that stopped reading after the first initialize.
I wrap launch with
script -q -c "node server.js" /tmp/mcp-stdio.logso when Cursor sits there forever I at least have the last line. usually it is waiting on a tool result that never flushed.was your Notion server doing list_tools again mid-session, or just stuck after one call?
green forever with a dead child is the same class of lie as a VS Code extension that reports "ready" with tools:[]. client should flip red the second the transport stops ACKing.
i give every mcp invoke a 45s deadline + a watchdog that kills the pid if rss stops moving. ugly. quieter than watching the spinner for 20 min though.
the -32000 Connection closed only after you kill node is the tell — Cursor never noticed the hang on its own.
we hit this two nights before a launch. team of two, one Notion MCP for customer notes, Cursor just spinning. no error until we killed the process.
now the rule is: any MCP that can sit green past 60s gets a hard kill in the launch script. agents that need babysitting that long do not ship on our friday deploys.
did you recover the refactor diff after the kill, or did it eat the in-flight edits?