vscode 2026.1+ 默认启用webassembly沙箱机制，旧版插件因未适配vscode-mcp或dap新abi约束（如缺失capabilities声明、误用type: node调试配置、直接调用child_process/fs/process.env等），导致调试器无法进入wasm上下文而静默失败，断点不触发。
VSCode 2026.1+ 已默认启用 WebAssembly 沙箱机制，任何插件若未适配 vscode-mcp 或 DebugAdapter 的新 ABI 约束，调试时会静默失败或卡在 createServerSession 入口——这不是配置问题，是执行环境被拦截。
为什么本地调试插件突然不进断点
旧版插件（尤其是基于 Node.js 子进程 spawn 启动 DAP 的）在 VSCode 2026 中无法触发断点，根本原因是：Wasm 沙箱禁止直接 require('child_process')、fs.readFileSync 和 process.env 未声明访问权限。调试器进程本身运行在受限沙箱内，不是你本地终端的 Node.js。
- 现象：launch.json 配置无误，F5 后控制台无输出，调试面板显示 “No debug adapter installed” 或卡在 “Starting debug session…”
- 验证方式：在插件入口加
console.log('sandbox test')，若该日志不出现，说明沙箱已阻止模块加载 - 关键检查点：
package.json中必须声明"capabilities": { "untrustedWorkspaces": { "supported": true } }，否则沙箱拒绝初始化
如何模拟真实沙箱环境启动调试
不能靠 npm run watch + code --extensionDevelopment 组合来测——它绕过了 Wasm 加载链。必须用 VSCode 内置的调试协议通道启动。
- 确保插件根目录有
.vscode/launch.json，且 type 字段为"pwa-extensionHost"（不是node） - 配置中必须包含
"runtimeExecutable": "${execPath}"，显式指向当前 VSCode 主进程（而非任意 Node.js） - 添加
"args": ["--enable-proposed-api=vscode.vscode-mcp", "--disable-extensions"]，避免其他插件干扰沙箱判定 - 启动后，在调试控制台输入
self.constructor.name，返回WebAssemblyInstance才代表进入沙箱上下文
调试适配器（DAP）在沙箱中的存活条件
DebugAdapter 不再能自由绑定端口或 fork 进程。它必须通过 VSCode 提供的 vscode.debug API 注册，且所有 I/O 路由需经由 DAP 协议帧转发。
- 废弃写法：
const server = net.createServer(...).listen(3333)→ 沙箱报错Network access denied in WASM context - 正确路径：在
createServerSession()中返回继承自DebugSession的实例，并只使用this.sendEvent()/this.sendResponse() - 注意
supportsConfigurationDoneRequest必须设为true，否则 VSCode 2026 会跳过后续初始化流程，不调用attachRequest - OpenOCD/J-Link 类插件需改用
vscode.workspace.fs.readFile()替代fs.readFileSync读取配置文件，否则抛PermissionDenied
沙箱不是“能不能跑”，而是“以什么身份跑”。最常被忽略的是：插件 package.json 里漏了 capabilities 声明，或 launch.json 里用了 type: node 假装自己是普通脚本——这两处一旦出错，VSCode 就不会把你的代码送进 Wasm 实例，所有调试行为都发生在错误的上下文中。
