René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"[FEATURE] MCP stdio server exits silently when JSON-RPC messages are CRLF-terminated","articleBody":"## Summary\n\n`stackql mcp --mcp.server.type=stdio` exits immediately with code 0 and no error output if an incoming JSON-RPC line is terminated with `\\r\\n` instead of `\\n`. The stray `\\r` at the end of the line appears to kill the server's message loop. Nothing is written to stdout, stderr, or the sink log, so from the client's side the server just dies with a clean exit code, which makes this very hard to diagnose.\n\n## Environment\n\n- stackql version: 0.10.500\n- OS: Windows 11 (also reproducible anywhere by sending CRLF line endings)\n- Invocation: `stackql mcp --mcp.server.type=stdio --auth='{\"github\":{\"type\":\"null_auth\"}}'`\n\n## Steps to reproduce\n\nLF-terminated message - works (server responds to `initialize`):\n\n~~~bash\n{ printf '{\"jsonrpc\":\"2.0\",\"method\":\"initialize\",\"params\":{\"protocolVersion\":\"2024-11-05\",\"capabilities\":{},\"clientInfo\":{\"name\":\"repro\",\"version\":\"1\"}},\"id\":1}\\n'; sleep 8; } \\\n  | stackql mcp --mcp.server.type=stdio --auth='{\"github\":{\"type\":\"null_auth\"}}'\n~~~\n\nCRLF-terminated message - server exits with code 0, no response, no error:\n\n~~~bash\n{ printf '{\"jsonrpc\":\"2.0\",\"method\":\"initialize\",\"params\":{\"protocolVersion\":\"2024-11-05\",\"capabilities\":{},\"clientInfo\":{\"name\":\"repro\",\"version\":\"1\"}},\"id\":1}\\r\\n'; sleep 8; } \\\n  | stackql mcp --mcp.server.type=stdio --auth='{\"github\":{\"type\":\"null_auth\"}}'\n~~~\n\nEquivalent Python repro (this is how it was found - `subprocess.Popen(..., text=True)` on Windows translates `\\n` to `\\r\\n` on the child's stdin):\n\n~~~python\nimport json, subprocess, time\n\ncmd = [\"stackql\", \"mcp\", \"--mcp.server.type=stdio\",\n       '--auth={\"github\":{\"type\":\"null_auth\"}}']\n\n# text=True on Windows writes \\r\\n to the child's stdin\nproc = subprocess.Popen(cmd, stdin=subprocess.PIPE, stdout=subprocess.PIPE,\n                        stderr=subprocess.PIPE, text=True)\nmsg = {\"jsonrpc\": \"2.0\", \"method\": \"initialize\",\n       \"params\": {\"protocolVersion\": \"2024-11-05\", \"capabilities\": {},\n                  \"clientInfo\": {\"name\": \"repro\", \"version\": \"1\"}}, \"id\": 1}\nproc.stdin.write(json.dumps(msg) + \"\\n\")\nproc.stdin.flush()\ntime.sleep(10)\nprint(\"returncode:\", proc.poll())   # 0 - exited, no response ever written\n~~~\n\nSwitching the same script to binary pipes (no newline translation) makes the handshake succeed.\n\n## Expected behaviour\n\nEither of:\n\n1. Tolerate CRLF: strip a trailing `\\r` from each line before JSON parsing. The MCP spec's stdio transport delimits messages with newlines, and CRLF-emitting clients exist in practice (anything spawning the server through a text-mode pipe on Windows).\n2. At minimum, fail loudly: log a parse error to stderr and/or the sink log, and exit non-zero, instead of exiting 0 in silence.\n\n## Actual behaviour\n\nThe process exits with code 0. Nothing is written to stdout. The sink log file is created but empty. The only stderr output is the usual `sink file: \u003cpath\u003e` line.\n\n## Impact\n\nAny MCP client (or test harness) that ends up writing CRLF-terminated lines on Windows sees the server \"start and immediately die\" with a success exit code and zero diagnostics. This cost real debugging time while smoke testing the Windows `.mcpb` bundle.\n\n","author":{"url":"https://github.com/jeffreyaven","@type":"Person","name":"jeffreyaven"},"datePublished":"2026-06-12T04:09:45.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/668/stackql/issues/668"}