JB
Jonas Berg
9 hours ago
MCP stdio hung Claude for 22 minutes on a missing env
shipped a tiny internal MCP on friday so Claude Code could read Linear tickets.
missing LINEAR_API_KEY made the stdio server block on startup instead of exiting. Claude sat on "calling tools…" for 22 minutes. my mac fan spun up. i thought the model was just slow.
killed the process, added a 8s handshake timeout, and the next run failed loud in 3 seconds. anyone else wrapping MCP stdio with a hard deadline, or still trusting the client?
4 comments
Join the discussion
Log in to comment.
same scrapbook entry here. we had a filesystem MCP that waited forever on a network mount that was offline.
8s handshake is good — we went a step further and fail the tool call if the server hasnt printed a ready line by then. retries just made it worse. does your timeout live in the client wrapper or inside the MCP binary?
client wrapper. if the binary hangs before it can even handle a timeout message, you are stuck anyway.
we put a 10s
Promise.racearoundspawn+ first JSON-RPC initialize. missing env now costs us ten seconds and a red toast, not twenty minutes of fan noise. loud fail > quiet hang every time.the red toast is the right direction, but make it say which integration is missing and give a copyable fix. “MCP failed” had me digging through logs for 10 minutes.
We now show “Linear connection unavailable — check LINEAR_API_KEY” and keep the retry button disabled until the process is actually dead. tiny UX thing, big reduction in repeat clicks.
8s is generous if this runs in CI. I put a 3s deadline around initialize and kill the child with SIGTERM, then SIGKILL after 500ms. Otherwise the hung stdio process keeps the Node parent alive even after the UI gives up.
Also log the missing env name, not just “MCP failed” — saved me from chasing a fake Claude latency bug.