VSCode没有无痕模式，只有受限模式（Restricted Mode）；该模式在打开新文件夹时默认启用，禁用所有非内置插件以保障安全，需点击右下角标签并选择“Trust This Workspace”才能恢复插件运行。
VSCode没有“无痕模式”，只有受限模式（Restricted Mode）
VSCode 本身不提供类似浏览器的“无痕模式”，所谓“无痕”需求，实际对应的是 Restricted Mode 下禁用未信任工作区中的插件。这个状态不是用户主动开启的，而是 VSCode 在打开新文件夹时默认触发的安全机制：未显式授信前，所有非内置扩展都会被静默禁用，并显示右下角 Restricted Mode 标签。
常见现象包括：ESLint 不报错、Markdown Preview Enhanced 点预览无反应、launch.json 调试按钮灰掉、终端里 npm run dev 报“命令未找到”。这些不是插件崩溃，是 VSCode 主动拦截了执行链。
禁用插件 ≠ 绕过信任检查
你不能靠“禁用某个插件”来规避受限模式——因为插件本身在未信任状态下根本没机会加载。VSCode 的信任检查发生在启动早期，早于插件激活时机。此时即使你在 settings.json 里写 "extensions.enabled": {"publisher.name": false}，也起不到作用：插件进程压根没被拉起。
-
extensions.enabled配置只对已信任工作区生效；未信任时，VSCode 直接跳过整个扩展主机（extension host）初始化 - 点击右下角
Restricted Mode→Trust This Workspace才是唯一能恢复插件运行的路径 - 手动编辑
.vscode/workspaceTrust.json或往settings.json加"security.workspace.trust.untrustedFiles": "open"都无效——前者不被读取，后者只控制文件打开行为，不影响插件启用
真正安全的临时排查方式：code --disable-extensions
如果你怀疑某个插件导致崩溃或异常，又不想授信当前工作区，正确做法不是“禁用插件”，而是用官方支持的隔离启动方式：
- 关闭所有 VSCode 窗口
- 终端执行：
code --disable-extensions（打开空窗口），或code --disable-extensions /path/to/project（打开指定目录） - 该命令会跳过所有用户扩展、忽略
settings.json中的扩展配置，且不触发任何信任弹窗 - 注意：不要用图形界面双击打开，也不要加
--reuse-window，否则可能复用旧进程并加载已有插件
这种方式下，你看到的是纯内置功能（如基础语法高亮、文件树、搜索），可用来确认问题是否由第三方扩展引起。它不改变信任状态，也不影响后续正常打开行为。
全局关 trust 的代价远超预期
有人试图通过关闭 security.workspace.trust.enabled 来“一劳永逸”，但这是高风险操作：
- 重启后所有文件夹（包括 GitHub 下载的 ZIP、同事发来的 demo）都默认受信任，
tasks.json和launch.json中的脚本静默执行 -
terminal.integrated.env.*环境变量配置失去项目隔离能力，变成全局生效 - 像
sonarlint这类依赖信任状态激活扫描的企业插件，会直接跳过关键检查 - 符号链接目录（如
ln -s ~/projects/myapp ./myapp）授信后，VSCode 记录的是解析后的绝对路径，容易误判信任是否覆盖子路径
最常被忽略的一点：信任状态不继承子目录。你信任了 /project，再单独打开 /project/node_modules，它仍是未信任状态——这说明“全局关 trust”并不能真正模拟出你想象中的“无痕”环境。
