filesystem: ~1MB JSON-RPC line on stdio causes crash or zombie state

[pzr21]

Describe the bug
The secure-filesystem-server MCP server becomes unavailable after receiving a single ~1 MB JSON-RPC message on stdio.

Unlike truncated JSON or type-confused fields, this payload is syntactically valid JSON-RPC. The failure is consistent with missing per-line size limits and/or unbounded buffering / JSON.parse on huge stdin lines, leading to memory pressure, event-loop blocking, or a broken read loop.

Environment
OS: Linux
Platform: Cursor Desktop
MCP server: @modelcontextprotocol/server-filesystem via npx -y
Reported serverInfo: {"name":"secure-filesystem-server","version":"0.2.0"}

To Reproduce

1. Start the server:

npx -y @modelcontextprotocol/server-filesystem /tmp

2. After a normal session is established (or on a fresh stdio session), write one newline-terminated line whose JSON body is approximately 1 MB. For example:

{
  "jsonrpc": "2.0",
  "method": "echo",
  "params": { "data": "<1,048,576 × 'A'>" },
  "id": 9999
}

(Exact construction: "A" * 1024 * 1024 inside params.data, then json.dumps + \n.)

3. Wait ~200 ms, then send a valid follow-up request.

Expected behavior

• Enforce a maximum stdin line / message size (e.g. 64 KiB–256 KiB, aligned with MCP/host limits) before full buffering or JSON.parse.
• On oversize input: return a JSON-RPC error (or drop the line per transport rules), log a clear stderr line, and continue processing subsequent messages.
• Server process remains alive and responsive to normal initialize / tools/list traffic after the oversized line.

Actual behaviour
Observed failure modes:

• Node process exits (transport closes abruptly), or
• Process still running but does not respond to the post-fuzz liveness probe (“zombie state”).

[norika1207-lab]

This looks worth pinning down as a protocol-level regression rather than only an implementation bug.

For large JSON-RPC line causes crash or zombie state, the acceptance test I would want is a minimal client/server fixture that records the exact JSON-RPC or HTTP exchange, then asserts both the wire result and the local lifecycle state after the failure path. In MCP deployments, the dangerous failures are often not just wrong return values; they are pending requests, dropped notifications, mismatched session state, or errors that get translated into a generic response and become impossible to diagnose.

A useful fix boundary would preserve three signals: the protocol error sent to the peer, the local exception or cancellation reason available to application code, and a trace/log field that ties the two together. That makes the behavior debuggable for agent hosts without requiring every host to special-case this SDK detail.

[he-yufeng]

I could not reproduce this against the current main filesystem server (@modelcontextprotocol/server-filesystem@0.6.3, @modelcontextprotocol/sdk@1.29.0).

Probe shape:

• start src/filesystem/dist/index.js with one allowed temp directory
• send a normal initialize
• send a newline-terminated JSON-RPC ping request whose params.data is 1 MiB of A
• send a second normal ping

Observed result: both the large request and the follow-up request returned normal { "result": {} } responses, and the process remained alive.

So this looks either fixed in the current SDK/server stack or specific to the older published version from the report (serverInfo.version = 0.2.0). I am not opening a server-side patch from this issue because the current filesystem server entrypoint delegates stdio framing to the SDK transport, and the latest checked code path does not show the reported zombie/crash behavior.