[longseespace]

• Ensure the client’s background task breaks out of its receive loop once the transport’s AsyncThrowingStream finishes, preventing tight spins on closed connections.

Motivation and Context

When an MCP server process exited, Client.connect kept calling connection.receive() inside a repeat…while true loop even though the underlying stream had already finished. That resulted in a tight loop consuming ~100% CPU per disconnected server (e.g., killing 8 servers spiked to ~800% CPU). Breaking out when the stream finishes stops the runaway task and lets reconnect logic create a fresh transport instead.

How Has This Been Tested?

Tested in the BoltAI macOS client using this local package:

• Start MCP servers, then kill them repeatedly (manual reloads and process terminations).
• Verified CPU usage stays low and no new “hot” threads appear in LLDB.
• Confirmed normal message handling continues when the stream stays open.

Breaking Changes

No breaking API changes. Existing clients automatically benefit from the fix and still receive the same stream/error handling behavior.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

The fix keeps the transient “resource temporarily unavailable” retry path intact, so transports that briefly report EAGAIN will still retry. Only a fully finished receive stream now terminates the loop, which matches MCP transport semantics.

[DePasqualeOrg]

Thanks for your contribution, @longseespace. My PR #175 addresses the same root cause with a more comprehensive fix. If you think I've missed something, or if you have any feedback on my PR, please let me know.

Rather than adding break while keeping the outer loop, my PR removes the outer repeat { } while true loop entirely to match Server.swift and the TypeScript and Python SDKs.

My PR also removes the now-redundant EAGAIN handling (transports handle this internally), adds defer cleanup for pending requests on unexpected disconnect, and includes a test case based on test_stdio_client_bad_path from the Python SDK.

[toasterbook88]

Maintainer triage on February 24, 2026: low-risk merge candidate (small focused Client.swift fix, mergeable, no failing checks).

[varun06]

Hi @longseespace, thank you for this contribution. We're consolidating overlapping PRs.

#221 fixes the same receive-loop spin after the transport closes, and it already has an approval. The loop's EAGAIN retry isn't needed there, since StdioTransport handles EAGAIN internally.

We plan to close this PR once #221 is merged, so the fix isn't lost in between. If you think something here isn't covered by #221, please comment there or here and we'll make sure it's carried over.