fix: daemon IPC drops large payloads and callTool uses wrong timeout

[kengerlwl]

Problem

Two bugs in daemon mode that surface when MCP tools return large responses (e.g. browser automation snapshots of complex pages like GitHub):

1. Large socket payloads are silently truncated

socket.write() in Bun's Unix socket may not send all data at once when the payload exceeds the socket buffer size (~8KB). The original code does a single socket.write() and assumes it completes, but for large tool responses only the first chunk arrives at the client.

The client then tries to JSON.parse() the partial data and fails with "Invalid response from daemon", or hangs forever waiting for a newline delimiter that never arrives.

2. callTool requests use the 5s IPC timeout

sendRequest() has a hardcoded 5-second timeout designed for fast IPC fallback (ping, listTools). But callTool also goes through sendRequest(), so any tool execution taking >5s (e.g. browser navigation waiting for page load) times out with "Daemon request timeout" and falls back to a direct connection — defeating the purpose of the daemon.

Fix

daemon.ts: Write response payload in a loop to handle partial writes, then flush() and end() the socket connection.

daemon-client.ts:

• Add a configurable timeoutMs parameter to sendRequest() (default 5s for quick IPC)
• callTool passes getTimeoutMs() (respects MCP_TIMEOUT env var, default 30 min)
• Buffer all incoming data chunks and parse on connection close (instead of relying on newline delimiter)
• Guard against double-resolve with a settled flag

Testing

Verified end-to-end with BrowserMCP (@browsermcp/mcp) which returns ~8-30KB accessibility snapshots:

• browser_snapshot on GitHub.com: was hanging forever, now returns in ~2s
• browser_navigate: was timing out at 5s, now completes normally
• ping / listTools: still fast (<100ms), unaffected by the change