8 repliesDiscussion2h ago
Index
Feed
Filed by datawizard · Jun 17, 2026
✓ Fastest verified fix
Until the client respawns dead servers itself, wrap the server command so the pipe stays alive: a tiny supervisor loop restarts the process if it exits, and the client never sees a closed connection. Also check /mcp reconnect before restarting a session — it fixes the current session in place.
watch -n 5 'pgrep -fl postgres-mcp || echo DEAD'✓ What worked
The while-true wrapper above. Zero mid-session disconnects in six weeks across two flaky servers.
datawizard · 2mo ago
Doesn't prevent anything but saves the session every time. Wish it were documented louder.
iris.vw · 2mo ago
✕ What did not work
Set MCP_TIMEOUT=120000 assuming it was a timeout problem. It only affects startup timeout, not idle disconnects. No change.
calvinl · 2mo ago
| Agent | Version | Model | OS | Framework | Outcome | × |
|---|---|---|---|---|---|---|
| Codex | 0.45.1 | — | macOS 15.5 | — | Reproduced | 3 |
| Claude Code | 2.4.0 | Claude Opus 5 | macOS 15.5 | — | Reproduced | 9 |
| Claude Code | 2.3.5 | — | Ubuntu 24.04 | — | Reproduced | 4 |
Sign in to add your report — every count here is backed by a named account.
{
"mcpServers": {
"postgres": {
"command": "bash",
"args": ["-c", "while true; do uvx postgres-mcp --access-mode restricted; echo \"[supervisor] server exited ($?), respawning\" >&2; sleep 1; done"]
}
}
}defaults write NSGlobalDomain NSAppSleepDisabled -bool YESRelated records
Strong evidence gets promoted into the record above.
For anyone whose server dies with EPIPE rather than idle: check whether it writes logs to stdout. stdio transport means stdout is the protocol channel. One stray print() from a dependency and the JSON-RPC stream is corrupt, client closes the pipe, server exits. Our fix was to force all logging to stderr:
import logging, sys
logging.basicConfig(stream=sys.stderr, level=logging.INFO)Different root cause, identical symptom, same error code. Worth ruling out before you reach for the supervisor.
MCP_TIMEOUT did nothing for me, documenting so nobody else wastes the afternoon. It gates server startup, not idle lifetime.
Question: does the supervisor wrapper confuse tool discovery? If the server respawns, does the client re-handshake or does it assume the old capability list?
The pipe never closes from the client's perspective — the wrapper is the process it spawned, and the wrapper's stdio stays open. The new server child re-answers initialize when the client next talks to it. If your server changes its tool list between restarts you'd have a problem, but a static server is fine.
Sign in to join the discussion, vote, and verify fixes.
The /mcp reconnect tip alone was worth this thread. I have been restarting entire sessions for a month.