Fix subprocess deadlock with MCP servers via stderr redirection

[dicksontsai]

Summary

Fixes a critical deadlock issue that occurs when MCP servers produce verbose stderr output. The SDK would hang indefinitely when the stderr pipe buffer filled up.

The Problem

The deadlock occurred due to sequential reading of subprocess streams:

1. SDK reads stdout completely before reading stderr
2. When stderr pipe buffer fills (64KB on Linux, 16KB on macOS), subprocess blocks on write
3. Subprocess can't continue to stdout, parent waits for stdout → DEADLOCK 🔒

The Solution

Redirect stderr to a temporary file instead of a pipe:

• No pipe buffer = no possibility of deadlock
• Temp file can grow as needed (no 64KB limit)
• Still capture stderr for error reporting (last 100 lines)
• Works consistently across all async backends

Implementation Details

• stderr=tempfile.NamedTemporaryFile() instead of stderr=PIPE
• Use deque(maxlen=100) to keep only recent stderr lines in memory
• Temp file is automatically cleaned up on disconnect
• Add [stderr truncated, showing last 100 lines] message when buffer is full

Testing

• Verified no deadlock with 150+ lines of stderr output
• Confirmed stderr is still captured for error reporting
• All existing tests pass
• Works with asyncio, trio, and other anyio backends

Impact

• Fixes consistent hangs in production with MCP servers
• No functional regression - stderr handling is preserved
• Simpler than concurrent reading alternatives
• More robust than pipe-based solutions

Fixes the issue reported in Slack where SDK would hang indefinitely when receiving messages from MCP servers with verbose logging.

🤖 Generated with Claude Code