Non-interactive MCP tool call hangs after progress notification until idle timeout

Reproduce the hang in non-interactive mode with -p, --no-ask-user, --stream off, Azure MCP, and debug logging. Start with the rust:mcp::client request queue and rust:rmcp::service progress-notification path, then compare the timeline with the direct client. Done means the tool result reaches the model, or a bounded timeout returns a structured tool error instead of an idle WebSocket close.

Description

In non-interactive Copilot CLI, an already-discovered Azure MCP tool call can hang after delivering its initial progress notification. No tool result is delivered, and the MCP WebSocket closes five minutes later with idle timeout.

The identical tool and payload succeed immediately when invoked directly through another MCP client (VS Code), which suggests the failure is in the Copilot CLI MCP request/session path rather than the Azure best-practices command itself.

Environment

• Windows
• GitHub Copilot CLI 1.0.87-0 (current latest reported by copilot update)
• @azure/mcp 3.0.0-beta.45+d6f8a6f07e9b3b4c0b36176ae2fc39aafe6a5f05
• Non-interactive mode using -p, --no-ask-user, --stream off, and debug logging

Tool call

{
  "name": "azure-get_azure_bestpractices",
  "arguments": {
    "intent": "Deploy the claimed Flask research app to Azure App Service using Azure CLI in the assigned subscription, resource group, and preferred region.",
    "learn": true
  }
}

Reproduction

1. Start Copilot CLI in non-interactive mode with Azure MCP available and debug logging enabled.
2. Give it an Azure App Service deployment task that causes the model to call azure-get_azure_bestpractices with learn: true.
3. Observe that the tool emits its initial progress event but never returns a result.

This has occurred in three independent agent runs. Two used different application frameworks/personas, so it is not tied to Flask prompt wording.

CLI log timeline

18:27:42.559Z [DEBUG] [rust:mcp::client] MCP request enqueued {"request_id":"Number(2)"}
18:27:42.618Z [INFO]  [rust:rmcp::service] received notification ... message: Some("Learning about get_azure_bestpractices capabilities...")
18:32:41.840Z [DEBUG] [rust:log] Received close frame ... reason: "idle timeout"

There is no completion response or actionable timeout surfaced to the model between the progress event and socket closure.

Direct-client control

I invoked the same Azure MCP tool outside Copilot CLI, with the exact payload above, twice. Both calls returned immediately:

{
  "status": 200,
  "message": "",
  "results": ["...deployment best-practices guidance..."],
  "duration": 0
}

This also confirms that the command is available and that learn: true is accepted.

Expected behavior

Copilot CLI should deliver the MCP tool result to the model. If the server or transport does not complete within a bounded request timeout, the CLI should return a structured tool error so the model can continue with a fallback path.

Actual behavior

The model remains blocked on the tool call. The only visible event is the initial progress notification; five minutes later the WebSocket closes for idle timeout. In unattended runs this leaves the host silent until an external watchdog terminates it.

Related issues

• #4678 concerns MCP server startup blocking; this occurs after discovery and after a tool-call progress notification.
• #3257 concerns reuse of a dead pooled HTTP connection after idle; this occurs on a newly issued request that successfully begins delivering progress.

Full sanitized debug logs can be provided if useful.