Bug: MCP server `timeout` config lost after `tools/list_changed` notification

[utapyngo]

Describe the bug

The per-server timeout configuration in mcp.json is lost after receiving a notifications/tools/list_changed MCP notification. The timeout silently reverts to the default 180 seconds, causing long-running MCP tool calls to fail with MCP error -32001: Request timed out.

Steps to reproduce:

1. Configure an MCP server with a custom timeout:

{
  "mcpServers": {
    "my-server": {
      "command": "my-server",
      "args": [],
      "timeout": 600000
    }
  }
}

2. Have the MCP server send a notifications/tools/list_changed notification at any point (e.g., during initialization)

3. After the notification, call any tool on that server that takes longer than 180 seconds

4. The tool call times out after 180 seconds instead of using the configured 600000ms timeout

Impact:

Any MCP server that has a custom timeout configured and sends notifications/tools/list_changed at any point will have its timeout silently reset to 180 seconds for all subsequent tool calls.

Workaround:

MCP servers can avoid sending notifications/tools/list_changed to prevent the timeout from being lost. However, this means the server cannot dynamically update its tool list.

Affected version

• Copilot CLI version: 0.0.406
• OS: Linux

Expected behavior

Tool calls should use the configured timeout value from mcp.json regardless of whether notifications/tools/list_changed has been received.

Additional context

The log correctly shows MCP client for my-server configured with timeout: 600000ms at startup, confirming the config is loaded. The timeout is only lost after the first tools/list_changed refresh.