连接器修复

问题背景

在 WorkBuddy 里接第三方 MCP 连接器时，OAuth 往往要由系统默认浏览器打开授权页。Windows 上若出现 streamableHttp connect failed: Failed to open: 找不到应用程序 (0x800401F5)、sse connect failed: SSE error: Non-200 status code (405)，或界面提示授权超时、找不到应用程序，多数并不是 MCP 服务端本身坏了，而是本地 ShellExecute 打不开浏览器，或网络/代理把发现阶段拦在外面。

技能如何排查与修复

技能按四步收敛根因，任一步命中即可进入对应修复，不必机械跑完全部流程。

1. 日志定位：从 WorkBuddy 日志确认失败连接器名（如 connector:qq-mail）、目标 URL（如 https://api.mail.qq.com/mcp），以及是否已有 captureResourceMetadataUrl（OAuth 发现是否成功）。
2. 网络排除：对 MCP 端点做可达性验证；若 HTTP 正常而客户端仍失败，说明问题在本地环境。
3. 默认浏览器诊断（核心）：检查当前用户 HKCU\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice 中的 ProgId，并验证 HKCR\<ProgId>\shell\open\command 指向的可执行文件是否仍存在——ProgId 仍指向已卸载浏览器是最常见根因。
4. 确认可用浏览器：枚举本机仍安装的 Edge、Chrome 等，为覆写命令选目标路径。

修复侧优先推荐 HKCU 覆写 shell\open\command（无需管理员、仅当前用户），把失效的 ChromeCoreHTM、SogouExplorerHTML 等映射到仍存在的 msedge.exe 或 chrome.exe；验证注册表生效后让用户在 WorkBuddy 中重连，状态应变为 connected。方案 B 是引导用户在 Windows 设置 → 默认应用 → Web 浏览器 中正式改默认浏览器，适合作为 HKCU 修复后的长期收尾。

适用边界

• HKCU 方案只影响当前用户，不改动其他账户的全局注册表。
• 浏览器程序存在但仍失败时，需回到代理、防火墙或 DNS。
• 网络不通且非代理问题时，不要误把问题全部归因于 OAuth 浏览器链路。