Live Share连接中断八成因插件干扰vsls-agent信令通道，高风险插件包括REST Client、Thunder Client、Proxyman插件、HTTPS Everywhere替代品、未适配MCP协议的Copilot增强插件及旧版Markdown Preview Enhanced；需通过日志排查、安全模式验证和残留hook清理定位并解决。
VSCode 实时协同开发（Live Share）连接中断，八成不是网络问题，而是某个插件干扰了 vsls-agent 的信令通道或劫持了 WebSocket 连接。
哪些插件最常触发 Live Share 断连
Live Share 依赖独立的 vsls-agent 进程建立端到端加密信令通道（基于 WebSocket），一旦有插件主动监听、拦截或重写全局 WebSocket 构造函数、篡改 fetch/XMLHttpRequest 行为，或在后台高频轮询/注入脚本，就可能破坏该通道的握手与保活逻辑。
高风险插件类型包括：
- 网络调试类：如
REST Client、Thunder Client（部分版本会 patch 全局 fetch） - 安全/代理类：如
Proxyman官方插件、HTTPS Everywhere替代品（会强制重写请求头） - AI 辅助类：部分未适配 MCP 协议的
copilot增强插件（如 2026 Q1 前的非官方 fork）会 hookvscode.workspace.onDidChangeTextDocument并阻塞事件循环 - 离线文档类：如
Markdown Preview Enhanced旧版（v0.6.x）在预览时启动本地 HTTP server，与vsls-agent竞争端口或触发防火墙策略
快速定位是哪个插件在“捣鬼”
不要靠猜——Live Share 断连后，vsls-agent 日志里通常留有线索。关键操作顺序如下：
- 断连瞬间立即打开命令面板（
Ctrl+Shift+P），运行Live Share: Show Logs，查看最新日志中是否含WebSocket connection failed或handshake timeout后紧跟着某插件名（如[rest-client] intercepting request） - 若日志无明确指向，进入安全模式验证：关闭所有插件 → 重启 VSCode → 发起 Live Share 会话 → 确认稳定 → 逐个启用插件，每次启用后等待 2 分钟空闲再触发一次协作操作（如共享终端），直到复现中断
- 重点盯防刚更新过的插件：检查
Extensions视图右上角的 “Updated” 标签，尤其是 2026 年 4 月后发布的vscode-mcp相关插件（需加--enable-proposed-api=vscode.vscode-mcp启动的）——它们对底层通信栈改动较大，已知与 Live Share 存在兼容性冲突
禁用插件后仍断连？检查是否残留 hook
有些插件卸载不干净，会在 ~/.vscode/extensions/ 下留下未清理的 node_modules 或全局 patch 文件，导致重启后继续生效。
- 手动检查：
ls -la ~/.vscode/extensions/ | grep -E "(rest|proxy|copilot|mcp)"，确认对应目录是否真的被删除（注意带版本号的子目录） - 搜索残留 hook：在 VSCode 终端中运行
grep -r "WebSocket.prototype" ~/.vscode/extensions/ 2>/dev/null，若返回结果，说明某插件曾 monkey-patch 过原生 API - 终极清理：退出 VSCode → 删除整个
~/.vscode/extensions/→ 仅重装 Live Share 官方插件（ms-vsliveshare.vsliveshare）→ 再逐个加回其他插件
Live Share 的稳定性极其敏感于插件对底层通信 API 的“越界操作”，而这类问题往往不会报错，只表现为静默断连。排查时别被“插件能正常启用”误导——只要它在后台修改过 WebSocket 或网络请求链路，就可能成为定时炸弹。
