MCP transport stays disconnected for the rest of the conversation after first tool call is rejected (Claude Code) #75

Summary

When the very first mcp__hive__* tool call in a Claude Code conversation is rejected by the user via the permission prompt, every subsequent call to any Hive tool in the same conversation fails — first with MCP error -32000: Connection closed, then with No such tool available. The hive MCP server itself remains healthy at the process level (claude mcp list reports hive: uvx hive-vault - ✓ Connected), so the disconnect is session-scoped inside Claude Code, not at the server level.

This produces a frustrating UX: a single accidental "deny" forces the user to restart the conversation to recover Hive functionality.

Reproduction

1. Fresh Windows 11 Claude Code session with hive registered via uvx hive-vault.
2. From the conversation, call any Hive tool (e.g. mcp__hive__session_briefing).
3. When the permission prompt appears, click Reject / "No".
4. From the same conversation, call any other Hive tool (e.g. mcp__hive__vault_query).
5. Observe: first retry returns MCP error -32000: Connection closed. Subsequent attempts return No such tool available: mcp__hive__* because Claude Code de-registers the deferred tools.
6. Run claude mcp list in a separate terminal → confirms hive: uvx hive-vault - ✓ Connected. Server is fine globally.
7. Restart the Claude Code conversation → Hive tools recover.

Expected

A single user rejection should not poison the transport for the rest of the conversation. Either:

• The transport should reconnect on next call, OR
• The rejection should be a no-op on the transport (only the specific call cancelled, server still callable).

Observed environment

• OS: Windows 11 Enterprise 10.0.22631
• Shell host: PowerShell 7 (Claude Code default Bash also available)
• Claude Code: latest (Opus 4.7 conversation)
• Package: hive-vault 1.12.0
• Transport stack: FastMCP 3.3.1 over stdio
• uvx cache: %LOCALAPPDATA%\uv\cache

Hypothesis (not verified)

Either:

(a) Claude Code's MCP transport layer tears down the stdio pipe when the user rejects a call and does not attempt to respawn uvx hive-vault for that conversation, OR
(b) FastMCP / hive-vault returns an unrecoverable status when its first call is cancelled mid-handshake, causing Claude Code to mark the server dead.

Distinguishing between the two requires either:

• The Hive server's debug log at the moment of the rejection (does the process see the rejection, or just stdio close?), or
• A repro with another MCP server using a different transport library, to see whether the bug is Claude-Code-side or FastMCP-side.

Workaround

Always accept the first Hive tool call (you can deny later ones individually — the breakage is specific to the very first call in a fresh session). If the transport is already broken, restart the conversation.

Severity

Medium. Functional impact is limited to the affected conversation, but the failure mode is silent (tools just "disappear") and the recovery (restart) costs context. Repro is reliable.

Asks

1. Confirm whether FastMCP logs the rejection event or just sees stdio close. (Helps disambiguate FastMCP-side vs Claude-Code-side.)
2. If it is a FastMCP-side recoverable error, document the recovery semantics.
3. Consider a heartbeat or transport-resurrect strategy in hive-vault for sessions where the daemon is healthy but the per-conversation handle dropped.

Reported during a real session on 2026-05-15 (Windows 11 admin-less laptop). Full session context tracked in user's dotfiles repo planning work — happy to share extracts if useful for triage.