MCP tool calls intermittently rejected "disabled by the user" while cache shows enabled and server log shows execution

[luotianyiismywife]

• Copilot Chat Extension Version: latest (1.136.x)
• VS Code Version: 1.136.1
• OS Version: Windows 11 x64
• Feature: Chat ask mode (MCP tool usage)
• Selected model: tokenrhythm/deepseek-v4-flash-0731
• Logs: attached below in the description

Steps to Reproduce:

1. Configure an MCP server at profile level (e.g. @mozilla/firefox-devtools-mcp with --connect-existing --marionette-port 2828).
2. Open multiple VS Code windows; some windows still hold a stale cached config of a deleted workspace-level MCP server (same underlying server, cached as mcp.config.ws0.firefox-nightly in workspace state.vscdb → mcpToolCache).
3. From Copilot Chat, call an MCP tool (e.g. list_pages).
4. Observe: the same tool call alternates between:
   • Reaching the server (server log shows Executing tool: list_pages → server-side error "No Marionette listener..."), and
   • Being rejected with "disabled by the user" (call never reaches the server).

Expected: tool availability should be consistent with the persisted authorization state.

Evidence:

• mcpToolCache in profile state.vscdb shows all 48 tools with visibility: 3 (enabled), no disabled flags.
• Server log confirms the tool DID execute at 01:38:21: [firefox-devtools-mcp] Executing tool: list_pages → Connecting to existing Firefox via Marionette....
• Minutes later, the exact same tool call is rejected as "disabled by the user" without any user action.
• chat.mcp.autostart is never in profile settings.
• The workspace-level cache still lists a deleted server (mcp.config.ws0.firefox-nightly), suggesting stale multi-window MCP state.

This looks like a sync issue between the MCP tool authorization cache, the per-window server connection state, and the Copilot-side permission check — likely triggered by multiple VS Code windows and a stale cached workspace-level MCP config.

[luotianyiismywife]

最终版根因分析（2026-09-05，含完整排查过程和实测证据）

一、问题概述

在 ask 模式下调用 MCP 工具时，同一批工具中仅部分可用（14/48），其余工具被 Copilot 扩展内部以 disabled by the user 错误拦截，调用从未到达 MCP 服务器。而 mcpToolCache 中所有工具 visibility=3（已启用），服务器日志也显示工具已正常发现。

这个现象与工具数量变化（v0.10.1: 45 → v0.10.2: 48）同时出现，但经排查确认不是 schema 校验、不是用户禁用、不是缓存损坏，而是 ask 模式工具可见性的机制性缺陷（详见第 3 条评论的代码级分析）。

二、复现环境

• VS Code 1.136.1 (Windows 11 x64), Copilot Chat 0.64.1
• MCP 服务器: @mozilla/firefox-devtools-mcp v0.10.2 (48 个工具), profile 级配置
• 关键设置: chat.mcp.autostart = never
• 多窗口场景, 存在已删除的 workspace 级 MCP 配置残留缓存

[luotianyiismywife]

三、完整实测数据（48 个工具全部测试）

判定标准

• 可用 = 调用到达了 MCP 服务器（返回服务器侧错误如 "No Marionette listener" / "stale/invalid UID" 等），说明请求通过了 Copilot 侧检查
• 被拦 = 返回 Tool ... is currently disabled by the user, and cannot be called.（调用没到服务器，服务器日志无 Executing tool 记录）

完整矩阵（48 个）

可用（14）: list_pages, new_page, close_page, clear_snapshot, click_by_uid, drag_by_uid_to_uid, clear_console_messages, clear_downloads, accept_dialog, dismiss_dialog, profiler_is_active, evaluate_script, enable_debugger, remove_logpoint

被拦（34）: navigate_page, select_page, get_page_text, take_snapshot, resolve_uid_to_selector, hover_by_uid, fill_by_uid, fill_form_by_uid, upload_file_by_uid, press_key, type_text, list_network_requests, get_network_request, set_network_cache, list_console_messages, screenshot_page, screenshot_by_uid, list_downloads, set_download_behavior, navigate_history, set_viewport_size, get_firefox_output, get_firefox_info, restart_firefox, install_extension, uninstall_extension, profiler_start, profiler_stop, screencast_start, screencast_stop, list_scripts, get_script_source, set_logpoint, get_logpoint_results

对照实验

1. 参数校验先于 disabled 检查: 对被拦的 navigate_page 传空参数返回"参数校验错误"而非 disabled → 证明工具存在、参数校验通过、但被可用性检查拦截
2. 反复调用: 对 get_page_text 连续调用 3 次 → 全部被拦 → 无"首次拦截后变可用"的恢复机制
3. 分布无规律: 可用/被拦无字母序、模块、风险等级规律（evaluate_script 高风险可用，take_snapshot 只读被拦；new_page 可用，navigate_page 被拦）

日志证据（window24）

• 服务器日志: Discovered 48 tools（无 schema 校验警告）
• Copilot Chat 日志: 51 条 disabled by the user 错误，涉及 34 个 MCP 工具 + 1 个内置工具（create_file）
• 服务器日志记录的成功调用: 恰好 14 个，与被拦名单零重叠
• 时间线: 02:14:59 服务器启动 → 02:15:05 才 Discovered 48 tools（约 6 秒发现窗口）→ 02:16:48 起开始出现 disabled 错误

[luotianyiismywife]

四、根因分析（代码级验证）

拦截点（已确认）

Copilot 扩展 toolCalling.tsx 中：
js if (c.tools && !c.tools.availableTools.find(U => U.name === e.toolCall.name)) throw new Error('Tool ' + e.toolCall.name + ' is currently disabled by the user, and cannot be called.')
只要工具不在本次请求的 availableTools 列表里就被报 "disabled by the user"。

关键机制：ask 模式下 MCP 工具如何进入 availableTools

唯一途径是 request.toolReferences 快照（askAgentIntent.ts）：
js return toolsService.getEnabledTools(request, model, tool => tool.tags.some(tag => lookForTags.has(tag)) // MCP 工具 tags=['mcp']，不匹配 vscode_codesearch || request.toolReferences.some(ref => ref.name === tool.name)); // 只能靠这个
MCP 工具（tags=['mcp']）不走 tags 匹配，只能通过 @ 引用工具集（MCP 服务器名）生成的 toolReferences 进入。

快照在请求解析时创建（chatRequestParser.ts:191）

js const value = Array.from(toolset.getTools()).map(t => ...); // ← 展开成快照！
用户 @ 引用 MCP 服务器名（工具集）时，在请求解析的那一刻把工具集展开成静态快照，此后整个请求期间固定不变。

服务器连接/工具发现是异步的（window24 实测）

• 02:14:59 服务器启动 → 02:15:05 才 Discovered 48 tools（约 6 秒）
• 工具是逐个注册的（mcpLanguageModelToolContribution.ts 中 autorun 响应式注册）
• 若请求解析发生在发现完成前，快照就只有当时已注册的部分工具

完整解释（为什么是 14 个）

1. 新会话：用户 @ 引用 MCP 服务器 → 请求解析 → 此刻服务器还在发现中，只有约 14 个工具已注册 → 快照只有 14 个
2. 快照冻结后，后续请求即使 48 个工具都已注册（缓存/服务器均确认），ask 模式 filter 仍只认快照里的 14 个 → 34 个永远被拦
3. 交替现象：不同会话/请求的解析时机不同（发现前 vs 发现后）→ 有的请求 14 个可用，有的（老会话）全部被拦

已排除的因素

• ❌ 不是用户禁用（mcpToolCache 全为 visibility=3）
• ❌ 不是 schema 校验省略（Discovered 48 tools 无警告，缓存 48 个完整）
• ❌ 不是缓存损坏（profile state.vscdb 中 mcpToolCache 完整 48 工具）
• ❌ 不是 750ms 延迟窗（次要因素，非根因）
• ❌ 不是多窗口配置残留（主因，仅放大因素）

[luotianyiismywife]

五、时间线（为什么 v0.10.2 触发）

• 8/24: 项目级 MCP 正常工作
• 9/4 早上: profile 级 + v0.10.1（45 工具）完全正常，无 disabled
• 9/5 02:23: v0.10.2 发布（45 → 48 工具）
• 9/5 02:15（window24 新窗口）: v0.10.2 + 48 工具 → 开始出现 disabled by the user

v0.10.2 是放大因素而非根因：工具数量/列表变化使首次 @ 引用快照的解析时机更容易落在发现窗口内（工具越多、注册越慢，快照截断概率越高）。9/4 早上 v0.10.1 正常可能是因为当时恰好快照解析晚于发现完成。

六、修复方向建议（按优先级）

1. ask 模式 filter 动态化（askAgentIntent.ts）: 对 MCP 工具集（tags=['mcp']），在 availableTools 构建时动态包含当前已注册的 MCP 工具，而不是仅依赖请求解析时的 toolReferences 快照
2. 工具集引用解析等待服务器就绪（chatRequestParser.ts:191）: @ 引用工具集时，若 getTools() 为空/部分（服务器发现中），应等待服务器工具发现完成（带超时）再创建快照
3. 报错语义区分（toolCalling.tsx）: 区分"用户真实禁用"vs"工具暂未注册/不可用"，给模型更准确的信号（如 "tool not currently available"）而非误导性的 "disabled by the user"
4. 注册推送加速: 对 MCP 工具注册走 flushToolUpdates() 立即推送路径（当前 750ms scheduler 延迟会放大问题）

七、影响面

该问题影响所有在 ask 模式下通过 @ 引用使用 MCP 工具集的用户，尤其是：

• 服务器启动慢/工具多的场景（如 firefox-devtools-mcp 48 工具）
• 新窗口 + 新会话的首个请求
• chat.mcp.autostart=never 的多窗口环境

[luotianyiismywife]

修复 PR 已提交 🎉

PR: https://github.com/microsoft/vscode/pull/334641（Fix ask mode MCP tool availability after server discovery）

修复内容（对应第 3 条评论的根因分析）:

• �skAgentIntent.ts 中新增 �skAgentToolFilter: 当用户 @ 引用了 MCP 服务器（toolReferences 中出现 mcp_ 前缀的工具名）时, 在 availableTools 构建时动态包含所有当前已注册的 MCP 工具
• 不再依赖请求解析时的静态快照, 可用性反映实时注册状态——服务器发现完成后注册的新工具立即可被模型调用
• 新增 6 个单元测试（askAgentIntent.spec.ts）, 覆盖快照场景/非 MCP 引用/无引用等边界情况, 全部通过

验证: �itest run src/extension/intents/test/node/askAgentIntent.spec.ts → 6/6 通过

请 review, 有任何修改建议随时提出!

[luotianyiismywife]

两个修复方案 PR 均已提交, 请维护者选择 📌

针对同一根因（ask 模式工具集静态快照 vs 动态注册时序问题）, 提交了两个方案, 区别在于修复范围:

---

方案 A: 按"被引用的服务器"精确放行 ✅（保守, 推荐）

**PR: https://github.com/microsoft/vscode/pull/334657**（Scope MCP tool availability to referenced servers only）

• 通过 LanguageModelToolMCPSource 识别工具归属的 MCP 服务器
• 用户 @ 了哪个服务器 → 只有该服务器的所有当前已注册工具可用（含发现完成后注册的）
• 其他服务器工具保持不可用 → 授权边界完整保留
• 8 个单元测试（含"未引用的服务器工具被排除"用例）

优点: 修时序问题且不破坏权限边界, 多服务器环境下安全
代价: 需要读 tool.source 判断归属（引用时的快照工具已注册才能解析到 source）

---

方案 B: 按 mcp_ 前缀宽松放行 ⚠️（改动最小）

**PR: https://github.com/microsoft/vscode/pull/334641**（Fix ask mode MCP tool availability after server discovery）

• 用户 @ 了任意 MCP 工具 → 所有 tags=['mcp'] 的工具全部可用
• 实现最简单（不查 source）

风险: 多服务器环境下（如 firefox-devtools + ida-pro-mcp + GitKraken 同时配置）, 用户只 @ 了 firefox, 但其他服务器的工具也全部暴露给模型——授权边界被扩大

---

对比

	方案 A（#334657）	方案 B（#334641）
修复时序 bug	✅	✅
保留授权边界	✅ 按服务器隔离	❌ 全部放行
实现复杂度	中（读 source）	低（前缀判断）
多服务器安全	✅	⚠️ 越权

建议采用方案 A（#334657）, 方案 B 保留作为参考。如果维护者觉得两个方案都不合适, 也欢迎提出更好的思路, 我可以配合修改。

[luotianyiismywife]

补充观察: 多窗口架构限制(独立于本 issue 的修复, 建议单独跟踪) 🪟

排查过程中发现 VS Code 的 MCP 架构对多窗口场景基本没有做协调设计, 以下是代码级验证的结果。这不是本 issue 两个 PR 要解决的问题, 但与本 bug 的表现互相影响, 建议维护者单独跟踪。

---

架构事实(代码验证)

组件	作用域	说明
McpService	每窗口独立实例	registerSingleton(IMcpService, McpService) — workbench singleton 是窗口级的, 每个窗口有自己的服务器实例/连接状态/工具注册表
mcpToolCache	profile 共享	McpServerMetadataCache 写入 profile scope 的 state.vscdb, 多窗口读同一份
缓存写入时机	onWillSaveState	每个窗口保存状态时都写入 → 多窗口互相覆盖(最后保存者胜)
mcp.enablement	存储共享, 实例独立	EnablementModel('mcp.enablement') profile 级存储, 但每个窗口实例独立缓存, 窗口间不同步
chat.mcp.autostart	配置共享, 执行独立	配置 profile 级, 但每个窗口各自执行 autostart 逻辑

会导致什么问题

1. 各窗口服务器启动状态不一致(最直接)

• 窗口 A 启动了 firefox-devtools, 窗口 B 完全不知道
• chat.mcp.autostart=never 时每个窗口各自决定 → 窗口 A 工具可用, 窗口 B 零注册
• 同一台机器上会同时存在多个服务器进程(n 个窗口 = n 个进程), 连接的是同一个浏览器 → 状态互相干扰(如两个窗口同时操作 Marionette)

2. 缓存竞态(数据互相覆盖)

• 每个窗口在 onWillSaveState 时写 mcpToolCache
• 窗口 A 写入 48 个工具 → 窗口 B(服务器未连接, 缓存为空)退出时写入空列表 → A 的缓存被覆盖丢失
• 表现为"重启后工具列表消失/回退"的随机现象

3. 工具注册集合跨窗口不一致

• 窗口 A 已连接 → 48 个工具注册
• 窗口 B 未连接 → 0 个工具注册
• 即使本 issue 的修复合并, 窗口 B 的 ask 模式依然无工具可用(只是报错不同)

4. 权限状态不同步

• EnablementModel profile 存储共享, 但窗口内缓存独立
• 窗口 A 启用了某服务器, 窗口 B 的 UI/行为可能还是旧状态, 直到重启

---

建议

1. 单独开 issue 跟踪 多窗口 MCP 状态协调(IPC 共享服务器状态, 或"单例服务器 + 多窗口代理"架构)
2. 本 issue (MCP tool calls intermittently rejected "disabled by the user" while cache shows enabled and server log shows execution #334569) 的修复(Scope MCP tool availability to referenced servers only #334657) 聚焦 ask 模式快照时序, 不涉及多窗口协调
3. 多窗口问题可作为后续独立 PR

(这是我实测环境里同时存在 window24/window25/window27 等多个窗口、且各窗口 MCP 日志/工具状态不同的根因之一。)