Why does MCP Inspector respawn my MCP server for every open browser tab?
MCP Inspector (modelcontextprotocol/inspector, April 2025) on macOS keeps respawning my MCP server: the log repeats 'Spawned stdio transport' and 'Connected MCP client to backing server transport' multiple times for the same command (uv run --with mcp mcp run codemcp/main.py). Why does this happen, and how do I stop the duplicate server processes? It seems to occur when several Inspector tabs are open in the browser.
Originally asked on GitHub: https://github.com/modelcontextprotocol/inspector/issues/302
5 answers
Closed as 'not planned': the maintainer said this sounds more like an unintentional state than a necessary feature, so no code change is coming, though adding a docs troubleshooting note was suggested. As the logs show, each Inspector browser tab opens its own SSE connection and spawns its own stdio transport: with multiple tabs you get repeated 'Spawned stdio transport' and 'Connected MCP client to backing server transport' lines, each running the same server command (for example /opt/homebrew/bin/uv with args run,--with,mcp,mcp,run,codemcp/main.py). The trigger in this thread was accidental: a commenter had manually restarted Inspector but an old Inspector tab was still buried in the browser tab list, and that leftover tab kept the connected state alive so the server kept respawning. The fix that worked was closing the other Inspector tabs, or removing the tab that still had the connected state; the duplicate spawns then stopped. One commenter also noted SSE connections have a limit of about 6 tabs. General advice: if you see this repeated spawn pattern, look for leftover Inspector tabs before restarting Inspector again. Note that the Inspector log echoes the full env object it passes to your command, so avoid putting secrets such as tokens or credentials in the env block while debugging.
Did this work for you?What a GitHub user tried on GitHub (Outcome unclear)
Reporter re-filed the issue because multiple Inspector tabs caused repeated 'Spawned stdio transport' and 'Connected MCP client to backing server transport' log lines, each spawning the same command (/opt/homebrew/bin/uv with args run,--with,mcp,mcp,run,codemcp/main.py).
Source: https://github.com/modelcontextprotocol/inspector/issues/302 (opens external site)
Did this work for you?What @avez-fsd tried on GitHub (Worked)
User confirmed the repeated spawning stops after closing the other Inspector tabs, and noted SSE connections also have a limit of 6 tabs.
Did this work for you?What @BBBmau tried on GitHub (Worked)
User with the same problem removed the leftover browser tab that still had the connected state, and the server stopped respawning.
Did this work for you?What @ezyang tried on GitHub (Outcome unclear)
Commenter identified the root cause for one case: after manually restarting Inspector, an old Inspector tab was still open in the browser tab list and kept the connection alive, so the server kept being spawned.
Did this work for you?
Related questions
- MCP Inspector 0.10.2 sends null for unset optional params (error -32602)?
- Why does npx @modelcontextprotocol/inspector fail with 'mcp-inspector: command not found' after 0.10.0?
- How do I increase MCP Inspector's 10-second request timeout?
- MCP Inspector crashes with 'Controller is already closed' on fastmcp Streamable HTTP
- Why does the MCP Inspector Docker container refuse connections on localhost:6274, and how do I fix it?