VSCode终端启动失败、Node子进程崩溃或forkpty(3)失败，八成是系统文件描述符耗尽：ulimit -n过低（≤2048）导致forkpty、语言服务器等并发资源分配失败，非VSCode本身故障。
VSCode 内置终端启动失败、Node.js 子进程崩溃或 forkpty(3) failed 报错，八成不是 VSCode 坏了，而是系统级文件描述符（fd）耗尽——尤其在单机跑多个 Node 服务、开一堆终端、又启了语言服务器和搜索服务时，ulimit -n 默认的 1024 连一半都撑不住。
为什么 ulimit 低会导致 VSCode 终端和 Node 进程异常
VSCode 启动时会并发创建多个资源：内置终端（每个依赖 forkpty）、Extension Host、searchService、tsserver/pyright 等语言服务器，全都要分配 fd。Linux/macOS 下每个 forkpty 调用至少占 1 个 fd，而 chokidar 监听器每注册一个目录路径还会额外吃 inotify 句柄。一旦总 fd 数逼近 ulimit -n 上限，就会出现：
-
EBUSY: resource busy or locked, open '.pipeconpty-xxx-in'（macOS/Linux） -
forkpty(3) failed或终端空白/闪退 - Node.js 子进程（如
npm run dev）启动瞬间崩溃，报EMFILE: too many open files
这不是代码问题，是操作系统拒绝再发句柄。
如何快速验证当前 ulimit 是否过低
别猜，直接查：
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 在 VSCode 内置终端中运行
ulimit -n，若输出 ≤ 2048，基本就是瓶颈 - Linux 用户追加检查：
cat /proc/sys/fs/inotify/max_user_watches，若 - macOS 用户运行
launchctl limit maxfiles，若显示类似256 256，说明 LaunchServices 层也锁死了
Linux/macOS 永久调高 ulimit 的正确姿势
临时改 ulimit -n 4096 只对当前终端会话有效，重启 VSCode 就失效。永久生效必须改系统配置，并重新登录：
- 编辑
/etc/security/limits.conf，末尾追加两行（注意空格）：* soft nofile 65536 * hard nofile 65536
- Linux 用户还需确保 PAM 加载该配置：检查
/etc/pam.d/common-session是否含session required pam_limits.so - macOS 用户要额外配 LaunchDaemons：
sudo vim /Library/LaunchDaemons/limit.maxfiles.plist，写入对应 plist 并执行sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist - 改完必须完全退出系统、重新登录（不是关 VSCode），否则不生效
Windows 上 conhost.exe 句柄泄漏的应对方式
Windows 错误里反复出现 conpty-xxx-in 或 winpty-agent.exe 失败，大概率是旧 conhost.exe 进程没释放命名管道句柄。任务管理器能看到多个 conhost.exe 持有同名 pipe，但杀掉后新建终端又复现：
- 优先尝试回退到 WinPTY：在 VSCode 设置中搜
terminal.integrated.windowsEnableConpty，设为false - 管理员 PowerShell 清残留 pipe（仅对已断开的 pipe 有效）：
Get-ChildItem \.pipe | Where-Object {$_.Name -like "conpty-*"} | Remove-Item - 若仍不稳定，考虑禁用终端复用：设置
terminal.integrated.enablePersistentSessions为false
真正棘手的是 Windows 控制台子系统残留 + VSCode 进程管理缺陷叠加，这种情况下，WinPTY 往往比 ConPTY 更稳。
