René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Windows: TextIOWrapper in stdio_server() emits CRLF instead of LF, corrupting newline-delimited JSON messages","articleBody":"## Summary\n\n`mcp/server/stdio.py` creates `TextIOWrapper(sys.stdout.buffer, encoding=\"utf-8\")` without specifying `newline=\"\"`. On Windows, the default `newline=None` causes `\\n` → `\\r\\n` translation, so every JSON-RPC message written to stdout ends with `\\r\\n` instead of `\\n`.\n\nThe MCP spec uses newline-delimited JSON with `\\n` as the delimiter. Emitting `\\r\\n` is a protocol-level impurity.\n\n## Affected file\n\n[`mcp/server/stdio.py` lines 46–49](https://github.com/modelcontextprotocol/python-sdk/blob/main/src/mcp/server/stdio.py)\n\n```python\n# Current (buggy on Windows)\nif not stdin:\n    stdin = anyio.wrap_file(TextIOWrapper(sys.stdin.buffer, encoding=\"utf-8\"))\nif not stdout:\n    stdout = anyio.wrap_file(TextIOWrapper(sys.stdout.buffer, encoding=\"utf-8\"))\n```\n\n## Reproduction\n\nOn Windows, spawn a Python subprocess that uses this code and read the raw bytes:\n\n```python\nimport subprocess, sys\n\nscript = r'''\nimport sys\nfrom io import TextIOWrapper\nstdout = TextIOWrapper(sys.stdout.buffer, encoding=\"utf-8\")\nstdout.write('{\"jsonrpc\":\"2.0\",\"result\":\"ok\"}\\n')\nstdout.flush()\n'''\n\nproc = subprocess.Popen([sys.executable, \"-c\", script], stdout=subprocess.PIPE)\nout, _ = proc.communicate(timeout=5)\nprint(repr(out))\n# Output on Windows: b'{\"jsonrpc\":\"2.0\",\"result\":\"ok\"}\\r\\n'\n# Output on Linux:   b'{\"jsonrpc\":\"2.0\",\"result\":\"ok\"}\\n'\n```\n\nVerified on:\n- **OS:** Windows 11 Pro (10.0.26200)\n- **Python:** 3.11\n- **mcp:** 1.26.0\n\n## Why this matters\n\nWhile the current JS MCP SDK client (`StdioClientTransport`) strips trailing `\\r` via `.replace(/\\r$/, \"\")` before parsing, this is a server-side bug that:\n\n1. Violates the NDJSON wire format (which specifies LF-only line endings)\n2. Creates an asymmetry: the Python `stdio_client` sends bare `\\n`, but the Python `stdio_server` responds with `\\r\\n`\n3. Could break any MCP client that does a strict `split(\"\\n\")` and then fails to `JSON.parse` the line with a trailing `\\r`\n\nThe comment on line 43 even acknowledges: *\"Encoding of stdin/stdout as text streams on python is platform-dependent (Windows is particularly problematic)\"* — but the fix applied (`re-wrap to ensure UTF-8`) doesn't also fix the newline translation mode.\n\n## Fix\n\nAdd `newline=\"\"` to both `TextIOWrapper` calls. `newline=\"\"` disables translation while still operating in text mode:\n\n```python\nif not stdin:\n    stdin = anyio.wrap_file(TextIOWrapper(sys.stdin.buffer, encoding=\"utf-8\", newline=\"\"))\nif not stdout:\n    stdout = anyio.wrap_file(TextIOWrapper(sys.stdout.buffer, encoding=\"utf-8\", newline=\"\"))\n```\n\nWith this fix:\n```python\n# newline=\"\" result:\nbuf = io.BytesIO()\nwrapper = TextIOWrapper(buf, encoding=\"utf-8\", newline=\"\")\nwrapper.write('{\"jsonrpc\":\"2.0\",\"result\":\"ok\"}\\n')\nwrapper.flush()\nrepr(buf.getvalue())\n# b'{\"jsonrpc\":\"2.0\",\"result\":\"ok\"}\\n'  ← correct on all platforms\n```\n\nThe same fix should be applied to the `stdin` wrapper so that incoming messages with bare `\\n` are not translated either (avoiding any future issues if a client sends strict LF).\n\n## Context\n\nThis was discovered while debugging Windows MCP tool timeouts with `mem0-mcp-selfhosted`. The eager-init approach fixed the actual timeout, but this CRLF emission was identified as a secondary protocol-level issue during investigation.","author":{"url":"https://github.com/DonovanDeHart","@type":"Person","name":"DonovanDeHart"},"datePublished":"2026-04-13T12:50:52.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":8},"url":"https://github.com/2433/python-sdk/issues/2433"}