npx进程不受VSCode沙箱控制，因其在集成终端中调用系统node而非VSCode spawn的子进程，内存、CPU、环境变量完全独立，崩溃不影响UI，也不受javascript.server.experimental.enableAgentIsolation等配置影响。
VSCode 中用 npx 启动临时工具（比如 npx create-react-app 或 npx hardhat node）时，它默认不进入 VSCode 的沙箱隔离机制——你看到的进程就是普通系统进程，和编辑器主进程、Extension Host 完全无关。
为什么 npx 进程不受 VSCode 沙箱控制
npx 是在集成终端里执行的 shell 命令，终端底层调用的是系统 node 可执行文件，不是 VSCode 自己 spawn 的 Extension Host 子进程。所以：
- 内存、CPU、环境变量完全独立于 VSCode 主进程和插件沙箱
- 崩溃不会影响编辑器 UI，但也不会受
javascript.server.experimental.enableAgentIsolation等配置影响 - 你在终端里
ps aux | grep node看到的 PID，和 Extension Host 的 PID 完全不同
npx 调起的本地节点（如 hardhat node）是否需要额外隔离
不需要主动隔离，但要注意资源竞争：
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
-
npx hardhat node启动的是一个独立 HTTP 服务，默认监听http://127.0.0.1:8545，它和 VSCode 无任何 IPC 或共享上下文 - 如果你同时开多个
npx实例（比如两个hardhat node），端口冲突会直接报错：Error: listen EADDRINUSE: address already in use 127.0.0.1:8545 - VSCode 的
extensions.agent.timeout对这类进程无效；想控制超时，得在命令里加参数，例如：npx hardhat node --port 8546
如何避免 npx 工具链与 VSCode 插件争抢 Node.js 资源
真正容易被忽略的点是：同一台机器上，VSCode 的 Extension Host + Language Server + 你用 npx 跑的 CLI 工具，可能共用同一个全局 Node.js 版本，但加载的 node_modules 和模块缓存互不感知——这会导致看似“相同”的包行为不一致。
- 比如
typescript版本：Extension Host 用的是 VSCode 内置或插件指定的 TS，而npx tsc --version用的是项目node_modules里的版本 -
npx默认优先找本地node_modules/.bin，找不到才临时安装；如果本地没装，它会下载最新版，可能和插件期望的版本不兼容 - 调试时若发现类型提示错乱、自动导入失效，先检查
npx tsc --noEmit --watch和 VSCode TS Server 是否用了同一份tsconfig.json和node_modules
复杂点在于：你没法靠改 VSCode 设置去约束 npx 行为，它本质上是个 shell 层动作。真要统一，得从项目级入手——锁死 engines.node、用 .nvmrc 或 volta pin 管理 Node 版本，再配合 package.json#scripts 封装常用 npx 命令，而不是零散敲终端。
