VSCode启动失败通常无需重装，应按顺序排查：先运行code --status定位扩展问题，再禁用扩展验证；检查用户数据目录是否损坏；尝试--disable-gpu或--no-sandbox绕过GPU/沙箱限制；最后用--log trace分析底层日志。
VSCode 启动失败，不是必须重装——绝大多数情况能快速定位并修复，关键在分层排查顺序。
检查 code --status 输出是否卡在扩展加载
很多启动卡死或白屏问题实际是某个扩展崩溃导致的。直接命令行运行 code --status（macOS/Linux）或 code --status（Windows PowerShell），观察输出末尾是否有扩展报错、Activating extension... 长时间无响应，或出现 ERR! spawn ENOENT 类错误。
- 临时禁用全部扩展：
code --disable-extensions，能启动说明问题出在扩展 - 逐个启用排查：先启用一半扩展，再根据结果缩小范围；重点关注最近更新或含原生模块的扩展（如
ms-python.python、esbenp.prettier-vscode） - 跳过自动激活：启动时加
--skip-extensions参数可绕过所有扩展初始化逻辑
验证用户数据目录是否损坏（~/.vscode 或 %USERPROFILE%\AppData\Roaming\Code）
配置文件、缓存、扩展安装路径都集中在这个目录。损坏后可能表现为反复闪退、设置不保存、终端无法启动等。
OC SSH Tunnel Node Recovery
下载
诊断并恢复通过 SSH 隧道连接的 OpenClaw 节点。用于解决配对必需错误、隧道冲突、远程端点错误以及 SSH 目标配置错误等问题。
- 备份后重命名该目录（例如改为
Code-backup），再启动 VSCode——它会重建干净目录 - 若新目录下正常，说明旧目录中某项损坏；可逐步迁移
settings.json、keybindings.json等文本配置，但避免直接复制Cache、GPUCache、Crashpad等二进制子目录 - Windows 用户注意：
%APPDATA%\Code和%USERPROFILE%\AppData\Roaming\Code是同一位置，不要重复操作
绕过 GPU 加速与沙箱机制启动（--disable-gpu / --no-sandbox）
尤其在远程桌面、Docker 容器、老旧显卡驱动或企业策略限制环境下，GPU 渲染或 Chromium 沙箱常触发启动失败，错误可能静默（无弹窗、无日志）。
- 先试
code --disable-gpu：禁用硬件加速，强制使用软件渲染 - 再试
code --disable-gpu --no-sandbox：彻底关闭沙箱（仅用于排查，勿长期使用） - Linux 下若提示
Failed to move to new namespace，大概率是容器未启用cap_sys_admin权限，此时--no-sandbox是必要参数
查看主进程日志确认崩溃点（code --log trace）
比 GUI 弹窗更底层的日志，能暴露 Electron 初始化、窗口创建、IPC 连接失败等环节的问题。
- 运行
code --log trace --status，日志会输出到终端；若 GUI 启动失败，改用code --log trace --verbose并观察最后几行 - 重点搜索关键词：
CRASHED、ENOENT、EACCES、Failed to create window、Cannot find module - 日志中出现
node_modules.asar路径缺失，说明 VSCode 安装包本身被破坏，需重新下载安装包而非仅覆盖更新
真正难解的启动问题，往往卡在「扩展 + 自定义 shell 环境 + GPU 驱动」三者交叠处。先做最小化复现（比如新建普通用户启动），再叠加变量，比盲目删缓存更省时间。
