codex 启动失败源于资源加载失败，应优先解决“the extension couldn't load its resources”；使用 code --verbose 查看底层日志定位 gpu 渲染、权限、用户数据目录损坏或扩展激活等问题。
Codex could not start 和 The extension couldn't load its resources 这两个报错不是并列关系，而是因果链：资源加载失败 → 启动流程中断 → 显示启动失败。先解决后者，前者自然消失。
code --verbose 是第一道诊断入口
VSCode 启动黑屏、闪退、卡在白屏，往往没弹窗报错。直接终端执行 code --verbose，比 GUI 启动多出几十行底层日志，关键线索就藏在里面：
- 看到
Failed to load module "appmenu-gtk3"（Linux）或libEGL initialization failed，说明 GPU 渲染层崩了，下一步该加--disable-gpu - 出现
Unable to read file '/.../Cache/' (Error: EACCES)，是权限问题，尤其常见于 WSL 或 Docker 挂载目录 - Windows 下若报
ERROR: Failed to get user data dir，大概率是注册表项HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Local AppData被篡改 - 输出末尾卡在某个扩展名后长时间无响应，比如
Activating extension 'ms-python.python'，基本可锁定问题源
用户数据目录损坏要精准隔离，别全删
%APPDATA%\Code\User Data（Windows）、~/Library/Application Support/Code/User Data（macOS）、~/.config/Code/User Data（Linux）这个目录不是“缓存文件夹”，它存着窗口布局、扩展状态、设置快照等运行时关键数据。Cache 或 GPUCache 子目录损坏，就会触发无限重启循环——点开即关，任务管理器里 code.exe 频繁启停。
- 临时重命名整个目录为
User Data.bak，再启动 VSCode，它会新建干净目录验证是否恢复 - 若恢复，说明原目录损坏；不要直接复制整个旧目录回来，只迁
settings.json、keybindings.json等纯文本配置 - 绝对跳过
Cache、GPUCache、Crashpad这些二进制子目录，它们不兼容跨版本 - Windows 用户注意：
%APPDATA%\Code和%USERPROFILE%\AppData\Roaming\Code是同一位置，别重复操作
禁用扩展不能只靠 --disable-extensions
code --disable-extensions 只跳过扩展初始化，但不会绕过 activationEvents 声明的自动激活逻辑。有些扩展（如语言服务器）即使被禁用，只要打开对应后缀文件，仍会拉起进程吃内存。
- 真正要隔离扩展影响，得组合使用：
code --disable-extensions --disable-gpu --verbose - 如果能进空窗口，说明崩溃来自某个扩展或其依赖的原生模块（比如
node-gyp编译的二进制） - 长期用
--disable-extensions会导致核心功能失效：GitLens 的右键菜单、Prettier 的保存格式化、Python 的调试器自动注册，全都不会触发 - 定位具体扩展时，用
code --status查看激活耗时，或运行Developer: Open Process Explorer按 Memory 排序，找 RSS 持续 > 300MB 的条目
最常被忽略的是：很多“启动失败”实际是资源加载环节静默失败，比如 Codex 找不到本地 Python 环境路径、远程容器里缺失 node 或 npm、或者 files.watcherExclude 配错导致 inotify 句柄爆满——这些都不会报红字，只会让整个启动链卡死在某一步。查 code --log trace 最后几行，比盯着 GUI 等弹窗靠谱得多。
