vs code插件“启动自启”实为activationevents触发的自动加载，禁用需三步：配置extensions.disabled、排查onstartupfinished劫持、检查配置兜底启用；验证是否真未加载应通过developer: show running extensions和输出面板日志确认。

插件“启动自启”本质是 activationEvents 触发的自动加载

VS Code 没有传统意义上的“开机自启插件”，所谓插件一打开就运行，其实是它注册了 activationEvents（如 onLanguage:python、onCommand:prettier.format、onStartupFinished），只要满足条件（比如打开 .py 文件、执行某个命令、编辑器启动完成），插件就会被加载并初始化。禁用插件后它仍“在后台”，往往是因为这些事件早已触发过，进程还驻留着。

真正阻止插件启动加载，得从三个层面下手

只在扩展面板点“Disable”远远不够——它只是标记状态，不卸载已加载实例。要让插件彻底不启动，需组合操作：

VS Code Node

通过作为 OpenClaw 节点连接的 VS Code/Cursor IDE 操作代码，提供 40 多种命令，涵盖文件操作、语言智能、Git、测试等功能。

下载

• 在用户或工作区 settings.json 中添加 "extensions.disabled": ["ms-python.python", "esbenp.prettier-vscode"]（注意：不是 enabled 数组，该写法已弃用）
• 检查是否被 onStartupFinished 类事件劫持：某些插件（如 GitLens、CodeGeex）默认监听此事件，即使禁用也会在窗口加载完后强行激活——必须配合 Developer: Reload Window 或完全重启 VS Code 才能清空
• 确认没有其他插件或配置兜底启用：比如 editor.defaultFormatter 强制设为 esbenp.prettier-vscode，哪怕插件已禁用，保存时仍会拉起它

验证插件是否真没启动？别信扩展面板的开关

扩展面板显示“已禁用”，只代表你手动点了 Disable，不代表它没运行。真正有效的判断方式是：

• 按 Ctrl+Shift+P → 输入 Developer: Show Running Extensions → 查看列表里有没有目标插件名；没出现才算真正未加载
• 打开输出面板（Ctrl+Shift+U），下拉选择对应插件（如 Python 或 Prettier）→ 如果完全无日志输出，基本可确认未激活；若有日志但功能不生效，大概率是配置冲突而非加载问题
• 在扩展搜索框输入 @disabled: → 列出所有当前被禁用的插件（含工作区级禁用），确认目标 ID 是否在列

工作区设置优先级最高，但命令行参数才是终极开关

如果你在项目根目录的 .vscode/settings.json 里写了 "extensions.disabled": ["xxx"]，那它一定生效，哪怕用户级设置里把它设为启用。但要注意例外：

• --disable-extensions 命令行参数会无视所有配置（包括工作区和用户设置），是唯一真正跳过插件加载的方式，适合排查冲突时临时使用
• 多根工作区（.code-workspace）的 extensions.disabled 会覆盖单文件夹工作区的同名设置，但无法覆盖用户级设置
• Remote-SSH / Dev Container 场景下，远程环境的 settings.json 是独立的，本地禁用对它无效

真正难缠的不是关不掉，而是你以为关掉了，结果某天发现 CPU 占用又高了、格式化还在跑、状态栏图标又亮了——那八成是某个 onStartupFinished 插件悄悄复活，或者工作区配置把你忘了。