fix(mcp): survive stdio host disconnect and silence handled MCP noise

[lukeocodes]

Summary

dg mcp --transport stdio was crashing when the AI host (Claude Desktop, Codex, etc.) closed the JSON-RPC stdio channel on disconnect. Anything that wrote to the global rich Console after that raised ValueError: I/O operation on closed file and surfaced as an unhandled exception (DX-CLI-4, DX-CLI-5 — 88 events in 14d, 27 in the last hour alone, still firing as of writing).

This PR adds three layered fixes:

1. dg mcp writes to stderr and returns None for stdio

packages/deepctl-cmd-mcp/src/deepctl_cmd_mcp/command.py

• Module console is now stderr_console from deepctl_core.output. Writing anything to stdout while the MCP host owns it would corrupt the JSON-RPC stream anyway.
• For transport=stdio the handler returns None instead of MCPServerResult. That skips BaseCommand.output_result entirely so there is nothing to write to the closed protocol channel after the proxy exits.
• The other branches (sse, errors, KeyboardInterrupt) keep returning MCPServerResult. Those have a real terminal to print to.

2. BaseCommand.execute traps closed-stream writes around output_result

packages/deepctl-core/src/deepctl_core/base_command.py

Defense in depth so any future stdio-mode command inherits the same safety. Catches BrokenPipeError, OSError, and ValueError("...closed file..."). Unrelated ValueErrors still propagate as ClickException so real bugs aren't hidden.

3. deepctl-telemetry drops handled MCP SDK log noise

packages/deepctl-telemetry/src/deepctl_telemetry/client.py

_scrub_event now drops events whose logger is in:

• mcp.client.streamable_http (the upstream MCP returned 5xx, recovered by the client — DX-CLI-1)
• mcp.server.lowlevel.server (stdio peer closed mid-message, recovered by the server — DX-CLI-3)

…provided no unhandled exception is attached. Unhandled crashes from those loggers (e.g. a real bug in the embedded SDK) are still surfaced.

Sentry issues addressed

Issue	Title	Outcome
DX-CLI-4	ValueError: I/O operation on closed file. (rich/console)	killed at source: stdio handler returns None + execute traps closed-stream writes
DX-CLI-5	ValueError: I/O operation on closed file. (base_command:124)	same
DX-CLI-1	HTTPStatusError: 503 from /kapa/mcp	dropped by _scrub_event (handled by MCP SDK)
DX-CLI-3	Received exception from stream: 1 validation error for JSONRPCMessage	dropped by _scrub_event (peer-closed noise)
DX-CLI-2	AttributeError: 'Request' object has no attribute 'send'	not in this PR — bug lives in the upstream deepgram-mcp package's proxy.py:handle_sse. Needs a separate fix there.

Companion PR

This is the client side of deepgram/dx-api#67, which fixed the same architectural family (handle upstream/downstream stream disconnects cleanly) on the server end.

Test plan

• make test (full suite): 965 passed, 0 failed
• make lint: clean
• make format-check: 115 files already formatted

New tests:

• TestExecuteStreamSafety in packages/deepctl-core/tests/unit/test_base.py
  • swallows ValueError("I/O operation on closed file")
  • swallows BrokenPipeError
  • still propagates unrelated ValueErrors (negative invariant guard)
• TestMcpNoiseFilter in packages/deepctl-telemetry/tests/unit/test_telemetry.py
  • drops 5xx HTTPStatusError from mcp.client.streamable_http
  • drops message-only event from mcp.server.lowlevel.server
  • keeps unhandled exceptions even from MCP loggers
  • keeps events from non-MCP loggers
  • integration with _scrub_event: returns None for noise, still scrubs headers/cookies/user data for normal events
• Updated test_handle_stdio_transport_returns_none and test_handle_api_key_from_auth_manager to expect None for stdio (the new contract)

Backwards compatibility

McpCommand.handle for stdio mode now returns None instead of MCPServerResult(status="success", ...). Anything programmatically calling handle() for stdio and reading .status will need to treat None as success. In practice this is internal to BaseCommand.execute, which already handles result is None.

Related

• Sentry: DX-CLI-1, DX-CLI-3, DX-CLI-4, DX-CLI-5
• Server-side companion: deepgram/dx-api#67