直接禁用插件比关遥测更可靠，因隐私插件常绕过telemetry设置自建http客户端发数据；需用developer: show running extensions查start-up、activation events和cpu%，结合extension logs folder和tcpdump验证外连，再通过settings.json中extensions.enabled精确禁用并清理残留配置，最后可用--disable-extensions彻底隔离。
直接禁用插件本身比关遥测开关更可靠，因为很多“隐私追踪插件”根本不在 VS Code 遥测控制范围内——它们是独立扩展，自建 HTTP 客户端、硬编码域名、绕过 telemetry.enableTelemetry 设置发送数据。
确认哪些插件在后台高频发请求
别靠名字判断，得看实际行为：
- 运行命令
Developer: Show Running Extensions，重点盯三列：Start-up 为true、Activation Events 含"*"或"onStartupFinished"、CPU % 持续 >3% 的插件 - 打开命令面板，执行
Developer: Open Extension Logs Folder，进codegeex-vscode-extension或tabnine等目录，查output.log里是否有POST https://api.codegeex.cn、POST https://telemetry.tabnine.com这类记录 - 用系统工具抓包（如 macOS 的
tcpdump -i lo0 port 80 or port 443），启动 VS Code 后空闲 30 秒，看有没有非127.0.0.1的外连
禁用必须用 extensions.enabled 配置项
图形界面点“禁用”容易失效，尤其对带 onStartupFinished 的插件——它可能已初始化网络模块，只是 UI 功能不响应。真正切断连接得靠配置：
- 打开
Preferences: Open Settings (JSON) - 在
extensions.enabled对象里加对应 ID，例如：{<br> "extensions.enabled": {<br> "tabnine.tabnine-vscode": false,<br> "github.copilot": false,<br> "codegeex.codegeex-vscode-extension": false<br> }<br>} - ID 必须精确：去扩展页点“详情”，URL 最后一段就是
publisher.name，写错（比如漏掉-vscode-extension）会静默失败 - 保存后重启 VS Code，再跑一遍
Developer: Show Running Extensions，确认对应插件的 Start-up 列变成false
防复活：删干净残留配置和自动更新
禁用后过两天又连上？大概率是这三处没清理：
-
settings.json里还留着"tabnine.apiKey"、"github.copilot.enableInlineSuggestion"等字段——哪怕插件禁用了，某些版本仍会读这些值并尝试预热连接 -
"extensions.autoUpdate": true开着，某次后台更新可能重置插件状态；建议设为false，避免静默恢复 - 工作区级
.vscode/settings.json里有同名配置，优先级高于用户级，得一并检查删除
终极隔离：启动时彻底跳过所有扩展加载
排查阶段或审计敏感项目时，--disable-extensions 是唯一能 100% 阻断网络外连的方式：
- 退出所有 VS Code 实例
- 终端执行：
code --disable-extensions /path/to/your/project（macOS/Linux）或code --disable-extensions C:\project（Windows） - 这个参数不读任何
settings.json、不加载.vscode/extensions.json、不触发任何 Activation Event——连插件的 JS 文件都不会被 require - 注意：必须放在命令末尾，且不能和
--extensions-dir同时用，否则会被忽略
真正难搞的不是“怎么关”，而是关完发现它还在连——因为插件作者把上报逻辑写死在主进程初始化阶段，甚至藏在语言服务器子进程中。这时候光靠设置不管用，得结合日志验证 + 启动参数隔离 + hosts 拦截三路并进。
