答案是点击右下角锁形图标选择“trust this workspace”并重载。这是vscode 1.56+默认工作区信任机制所致，右下角显示restricted mode或not trusted时，所有扩展被静默禁用；手动信任并重载后立即恢复，且仅作用于当前文件夹。
插件显示“this extension has been disabled because the current workspace is not trusted”
这是 VSCode 1.56+ 的默认安全行为，不是插件故障，也不是配置错误。只要右下角状态栏出现 Restricted Mode 或 Not trusted，所有扩展（包括语言服务、预览、格式化、调试器）都会被静默禁用——哪怕插件本身已启用、设置也正确。
最直接的验证方式：点击右下角锁形图标或文字提示 → 选择 Trust This Workspace → 勾选 I understand the risks → 点击 Trust and Reload。重载后，插件立刻恢复，无需重启 VSCode 全局进程。
注意：.vscode/workspaceTrust.json 是无效路径，VSCode 不读取它；手动改 .vscode/settings.json 加 "security.workspace.trust.untrustedFiles": "open" 只影响文件打开行为，不解决插件禁用问题。
为什么点了“Trust”后某些插件仍不工作
信任操作只解决“是否允许运行”，但不保证插件自身就绪。常见断点如下：
-
Code Runner需要额外确认：按Ctrl+Shift+X搜索该插件，确保状态是“已启用”，而非灰显或显示“已禁用” -
executorMap中对应语言的命令写错，比如python写成pyhton，或值为空字符串 - 语言识别失败：右下角显示
Plain Text而非Python/JavaScript，此时即使工作区已信任，Code Runner也不会响应 ▶️ 按钮 - 插件依赖其他扩展（如
Prettier依赖ESLint），而后者因未信任被禁，导致链式失效
全局关闭受限模式的副作用
在设置中关闭 security.workspace.trust.enabled 确实能一劳永逸，但会同步关闭全部防护：
- 终端启动时不再加载项目级
terminal.integrated.env.*环境变量，所有工作区共用同一套环境 -
launch.json和tasks.json的路径解析失去沙箱保护，符号链接或相对路径可能意外指向系统目录 - 企业级插件（如
SonarLint、GitHub Pull Requests）可能跳过关键检查步骤 - 从 GitHub 直接下载 ZIP 并解压打开的临时项目，将自动获得完整执行权限，无二次确认
如何判断当前问题是信任导致，而非插件自身异常
信任问题有明确信号，优先排查这些位置：
- 右下角状态栏是否显示
Restricted Mode或锁形图标 - 打开
Extensions面板，找到对应插件，点击齿轮 →Extension Settings→ 展开Workspace Trust区域，看是否显示This extension is disabled in untrusted workspaces - 尝试在另一个已信任的工作区（如新建空文件夹并信任）中安装同一插件，对比行为是否一致
- 终端里运行
npm run dev报 “command not found”，但which npm有输出 → 这是受限模式导致 shell 未加载$PATH，不是 Node.js 没装好
真正容易被忽略的是：信任状态按文件夹粒度存储，符号链接目录（如 ln -s ~/code/myapp ./myapp）被信任后，VSCode 记录的是解析后的绝对路径，下次用不同路径访问同一物理目录，仍会再次提示。
