vscode沙箱模式（restricted mode）会主动隔离系统path，导致node命令报错；需点击左下角黄色提示→选择信任文件夹→彻底重启vscode，并检查path、powershell执行策略、launch.json配置及wsl路径权限四者协同生效。
VSCode沙箱模式下node命令直接报“不是内部或外部命令”
这不是Node没装好，而是VSCode沙箱（Workspace Trust）主动切断了对系统PATH的继承。信任状态为Restricted Mode时，终端根本不会加载用户环境变量，node、npm、cnpm全都会消失。
验证方式很简单：在VSCode集成终端里运行echo $PATH（macOS/Linux）或echo %PATH%（Windows），如果输出为空或极短（比如只有C:\Windows\System32），基本就是沙箱拦截了。
- 左下角状态栏若显示黄色
Restricted Mode，点击它 → 选择Trust Folder and Subfolders - 信任后必须关闭并重启整个VSCode窗口（仅reload window无效）
- 重启后再次检查
echo %PATH%，应能看到包含nodejs路径的完整列表 - 注意：信任操作不可逆撤回，但可随时右键文件夹 →
Manage Workspace Trust重新设为受限
PowerShell执行策略在沙箱中仍生效，npm run卡住无输出
即使node命令可用，npm脚本仍可能被阻断——因为npm内部调用的是PowerShell封装脚本，而沙箱不改变PowerShell自身的ExecutionPolicy设置。
典型现象：运行npm start后终端停住、无任何错误、进程不退出、也不打印日志。
- 在VSCode终端中运行
Get-ExecutionPolicy -Scope CurrentUser，若返回Restricted，就是它 - 执行
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser（无需管理员权限） - 必须关闭当前终端标签页，再新开一个Terminal才能生效
- 别用
Unrestricted，RemoteSigned已足够且更安全
launch.json调试失败：“Cannot launch program”且断点灰掉
沙箱模式下，VSCode调试器（js-debug）默认禁用所有外部程序调用，哪怕node本身能跑，program字段指向的JS文件也会被拒绝加载。
ZenHeart zenlink 与 zenlink-mcp 为 OpenClaw，涵盖安装、MCP 注册、钩子接线、入站轮询及升级维护。
这不是路径写错，是调试器主动拒绝执行未显式授权的入口文件。
- 确保
launch.json中program字段是相对路径，如"${workspaceFolder}/src/index.js"，而非绝对路径或shell脚本 - 添加
"env": {}字段（空对象），强制继承当前终端环境，绕过沙箱的环境剥离 - 若项目含
preLaunchTask，需确认对应tasks.json中的command也指向可执行文件，而非npm run build这类脚本（沙箱会拦截脚本调用） - 调试前务必先在终端手动运行
node src/index.js验证能正常启动
WSL场景下沙箱与文件系统权限叠加导致Permission denied
在WSL中打开Windows路径（如/mnt/c/Users/xxx/project）时，VSCode沙箱 + WSL元数据缺失 + NTFS无执行位，三重限制会让./start.sh直接失败。
此时node命令本身可用，但脚本无法执行，错误和Node无关。
- 不要在
/mnt/c/下用chmod +x——NTFS不保存执行位，下次重启就丢 - 把项目移到WSL原生路径（如
~/projects/my-app），再chmod +x start.sh才真正生效 - 若必须放Windows侧，编辑
/etc/wsl.conf，加入[automount]和options="metadata"，然后wsl --shutdown重启 - VSCode中打开该WSL工作区时，仍需手动信任（左下角点击
Restricted Mode）
沙箱模式本质是隔离，不是故障；它的限制层层叠加，单点修复往往不够——PATH、PowerShell策略、调试器白名单、文件系统元数据，四者缺一不可。最容易被忽略的是：信任工作区后，必须彻底重启VSCode，而不是只关终端或reload窗口。
