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

[niteshj11]

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

• ACP: session/new blocks for 192s on a single unresponsive MCP server (no bounded MCP startup budget) #4678 concerns MCP server startup blocking; this occurs after discovery and after a tool-call progress notification.
• HTTP MCP servers fail with TypeError: fetch failed after idle period — CLI reuses dead pooled TCP connection #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.

[niteshj11]

Thanks for the follow-up. Here are the requested details.

1. Exact error/output

There is no immediate CLI error. The non-interactive Copilot CLI session hangs while awaiting the MCP tool result. Debug logging shows:

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"

No MCP completion response or structured tool error is delivered between the progress notification and the WebSocket idle-timeout close. An external host watchdog eventually terminates the silent session.

2. Command that was running

Sanitized invocation:

copilot -p "<Azure App Service deployment task>" --allow-all-tools --allow-all-paths --allow-all-urls --no-ask-user --no-color --stream off --name <host-id> -C <workspace> --log-dir <debug-log-dir> --log-level debug

The model then issued this MCP 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
  }
}

The same symptom reproduced in three independent sessions, including Flask and FastAPI tasks and AI-led, explore-first, and documentation-first personas. In each case the request was enqueued, the initial Learning about get_azure_bestpractices capabilities... progress notification arrived, and the connection closed about five minutes later with idle timeout. No Azure CLI deployment command had run.

3. Platform and versions

• Microsoft Windows 11 Enterprise, 64-bit
• OS version/build: 10.0.26200 / 26200
• GitHub Copilot CLI: 1.0.87-0
• GitHub CLI: 2.94.0 (2026-06-10)
• Azure MCP package: 3.0.0-beta.45+d6f8a6f07e9b3b4c0b36176ae2fc39aafe6a5f05
• copilot update reported no update available (1.0.87-0 installed; fetched latest release v1.0.86).

4. Authentication or other area

This does not appear to involve sign-in or authentication. GitHub CLI authentication is active, MCP tool discovery succeeds, and the MCP request starts sufficiently to emit a progress notification.

As a control, I invoked the identical azure-get_azure_bestpractices tool and payload twice through the VS Code MCP client on the same machine. Both calls returned HTTP 200 immediately with a valid result (duration: 0). This isolates the observed failure to the Copilot CLI MCP request/session path rather than general Azure MCP availability or the payload.

I can provide sanitized Copilot CLI debug logs and watchdog snapshots for all three reproductions if needed.

[niteshj11]

Thanks for checking. I reviewed the full debug log for each of the three reproductions. For the hanging azure-get_azure_bestpractices call, there is only one Learning about get_azure_bestpractices capabilities... progress notification per run, not repeated notifications.

The three timelines are:

Run p1
18:27:42.559Z MCP request enqueued (request_id Number(2))
18:27:42.618Z one Learning about... progress notification
18:32:41.840Z WebSocket close: idle timeout

Run p3
18:51:10.064Z MCP request enqueued (request_id Number(3))
18:51:10.181Z one Learning about... progress notification
18:56:09.156Z WebSocket close: idle timeout

Run p4
19:15:05.841Z MCP request enqueued (request_id Number(2))
19:15:05.899Z one Learning about... progress notification
19:20:05.211Z WebSocket close: idle timeout

I counted the exact progress-message pattern across each complete raw log: LearningProgressCount = 1 and IdleCloseCount = 1 in all three cases. There are no additional progress notifications for that call between the initial notification and the close frame.

So the repeated-progress timeout-reset defect you found does not appear to explain these particular hangs directly. This looks like a related but distinct path where one progress notification is received, no result or structured error follows, and the connection closes at the approximately five-minute idle threshold.

I can attach a sanitized contiguous log excerpt for each request if that would help correlate request IDs and transport events.

[niteshj11]

The Azure MCP timeout is unset in the Copilot CLI MCP configuration.

The active entry in ~/.copilot/mcp-config.json is structurally:

{
  "mcpServers": {
    "azure": {
      "tools": ["..."],
      "type": "local",
      "command": "C:\\Users\\<user>\\AppData\\Roaming\\npm\\azmcp.cmd",
      "args": ["server", "start"]
    }
  }
}

The Azure server entry contains only tools, type, command, and args. It has no timeout, requestTimeout, or toolTimeout property. I also checked the other Copilot CLI config files (~/.copilot/config.json and ~/.copilot/settings.json); neither defines an MCP timeout.

One potentially confusing detail: our external research harness has mcp_timeout_seconds: 60, but that value is supplied to the worker as behavioral guidance only. It does not configure or cancel an in-flight Copilot CLI MCP request. The harness inactivity watchdog was 960 seconds, so it also did not cause the approximately five-minute MCP WebSocket close.

Therefore, the observed close at about 299 seconds appears to come from a Copilot CLI/MCP transport default (or another component's default), not from an explicitly configured timeout on our side.