VS Code 中 Codex 面板持续加载与灰屏：从 Webview 资源错误排查到临时改用 CLI

Post Views: 6

最近我准备启动一个新的 WordPress 历史文章处理项目，计划先完成“历史文章格式盘点”，再继续处理摘要补齐和其他批量任务。

我为此新建了项目目录：

Plaintext

/home/wangqiang/code/wordpress-ai-excerpt-backfill

/home/wangqiang/code/wordpress-ai-excerpt-backfill

原本的计划很简单：

在 VS Code 中打开这个目录；
使用右侧 Codex 面板初始化仓库；
让 Codex 创建 README、目录结构和第一阶段说明；
后续继续编写只读盘点脚本。

但刚打开 Codex 面板，就遇到了一个很影响使用的问题：Codex 一直停留在加载状态，随后又变成了灰色或白色空白页面。

这篇文章记录本次完整排查过程，以及我最终为什么暂时放弃 VS Code 面板，改用 Codex CLI。

一、问题表现：Codex 面板一直加载

我先在本地创建了一个空目录：

Bash

mkdir -p /home/wangqiang/code/wordpress-ai-excerpt-backfill

mkdir -p /home/wangqiang/code/wordpress-ai-excerpt-backfill

随后在 VS Code 中通过：

Plaintext

文件 → 打开文件夹

文件 → 打开文件夹

打开：

Plaintext

/home/wangqiang/code/wordpress-ai-excerpt-backfill

/home/wangqiang/code/wordpress-ai-excerpt-backfill

文件夹可以正常打开，左侧资源管理器也能正确显示项目名称。

图1：在 VS Code 中打开新建的 wordpress-ai-excerpt-backfill 目录

但点击右侧的 Codex 面板后，界面一直停留在 OpenAI Logo，长时间没有进入正常的会话页面。

图2：Codex 面板长时间停留在加载状态

我首先尝试了比较常见的操作：

Plaintext

Developer: Reload Window

Developer: Reload Window

也就是：

Plaintext

开发人员：重新加载窗口

开发人员：重新加载窗口

但重新加载后问题没有变化。

这说明它不只是一次简单的界面初始化失败。

二、先确认 Codex CLI 是否可用

由于 VS Code 面板无法使用，我准备先确认本机是否已经安装 Codex CLI。

执行：

Bash

command -v codex
codex --version

command -v codex
codex --version

结果显示：

Plaintext

Codex 路径：未找到
找不到命令 “codex”

Codex 路径：未找到
找不到命令 “codex”

本机当时也没有 Node.js 和 npm：

Bash

node --version
npm --version

node --version
npm --version

均提示命令不存在。

为了避免额外安装 Node.js 和 npm，我最终使用 Codex 官方独立安装脚本：

Bash

curl -fsSL https://chatgpt.com/codex/install.sh | sh

curl -fsSL https://chatgpt.com/codex/install.sh | sh

安装结果为：

Plaintext

Codex CLI 0.144.6 installed successfully.

Codex CLI 0.144.6 installed successfully.

安装位置被加入：

Plaintext

/home/wangqiang/.local/bin

/home/wangqiang/.local/bin

重新确认：

Bash

export PATH="$HOME/.local/bin:$PATH"
hash -r

codex --version

export PATH="$HOME/.local/bin:$PATH"
hash -r

codex --version

输出：

Plaintext

codex-cli 0.144.6

codex-cli 0.144.6

这说明 Codex CLI 本身已经可以正常运行。

三、登录 Codex CLI

当前版本使用的是子命令：

Bash

codex login

codex login

而不是：

Bash

codex --login

codex --login

执行后，Codex 会启动一个本地回调地址，并自动打开浏览器完成 ChatGPT 账号授权：

Plaintext

Starting local login server on http://localhost:1455.

Starting local login server on http://localhost:1455.

授权成功后显示：

Plaintext

Successfully logged in

Successfully logged in

随后在项目目录中运行：

Bash

cd /home/wangqiang/code/wordpress-ai-excerpt-backfill
codex

cd /home/wangqiang/code/wordpress-ai-excerpt-backfill
codex

首次进入时，Codex 会询问是否信任当前目录：

Plaintext

Do you trust the contents of this directory?

Do you trust the contents of this directory?

由于这是我刚创建的本地项目目录，因此选择：

Plaintext

1. Yes, continue

1. Yes, continue

CLI 可以正常启动，也可以正常执行只读命令。

这一步很重要，因为它说明：

ChatGPT 账号登录正常；
Codex 服务本身可以使用；
当前项目目录没有问题；
故障主要集中在 VS Code 的 Codex 图形面板。

四、为什么仍然希望修复 VS Code 面板

Codex CLI 可以继续工作，但我仍然希望先修复 VS Code 中的 Codex 面板。

原因并不是 CLI 不能用，而是 Codex 面板更适合我当前的工作方式。

在右侧面板中，每一段回复旁边都有复制按钮，可以很方便地把 Codex 的执行结果复制到 ChatGPT 中继续分析。

终端虽然空间更大，但复制长回复通常需要：

用鼠标选择文本；
使用 Ctrl + Shift + C；
处理终端换行和折叠内容。

对于需要频繁在 Codex 与 ChatGPT 之间来回复制结果的工作流程，右侧面板明显更方便。

因此，我继续排查 VS Code Webview。

五、普通 Codex 输出日志没有提供有效信息

我先尝试查看：

Plaintext

查看 → 输出

查看 → 输出

并在输出来源中选择：

Plaintext

Codex

Codex

但来回切换“聊天”和“CODEX”并不会重新激活扩展，也没有生成新的有效日志。

随后尝试：

Plaintext

Developer: Restart Extension Host

Developer: Restart Extension Host

即：

Plaintext

开发人员：重启扩展主机

开发人员：重启扩展主机

问题依旧，而且 Codex 输出面板仍没有出现足够的信息。

这时继续盯着扩展输出日志，已经很难推进排查。

六、通过开发人员工具定位 Webview 错误

接下来我打开了：

Plaintext

帮助 → 切换开发人员工具

帮助 → 切换开发人员工具

并进入：

Plaintext

Console

Console

这次终于看到了大量明确的错误。

其中重复最多的是：

Plaintext

The FetchEvent for "<URL>" resulted in a network error response: insufficient resources.

The FetchEvent for "<URL>" resulted in a network error response: insufficient resources.

同时，大量 Codex Webview JavaScript 文件加载失败，例如：

Plaintext

GET https://file+.vscode-resource.vscode-cdn.net/.../webview/assets/appshot-window-IWY5MCjg.js net::ERR_FAILED

GET https://file+.vscode-resource.vscode-cdn.net/.../webview/assets/appshot-window-IWY5MCjg.js net::ERR_FAILED

还有：

Plaintext

use-chatgpt-composer-controller-5LuSW-YN.js
threads-create-DhlCLXwJ.js
codex-micro-DWAuwG0p.js
app-preloader-CPugGrqt.js

use-chatgpt-composer-controller-5LuSW-YN.js
threads-create-DhlCLXwJ.js
codex-micro-DWAuwG0p.js
app-preloader-CPugGrqt.js

这些请求全部指向本机扩展目录中的 Webview 静态资源，但通过 VS Code 的 Webview 资源地址加载时失败。

图3：开发人员工具中大量 insufficient resources 与 net::ERR_FAILED 错误

到这一步，问题范围已经明显缩小：

不是 Codex 登录失败；
不是项目目录错误；
不是 Codex CLI 不可用；
不是普通的 API 请求失败；
是 Codex Webview 前端资源没有成功载入。

七、确认扩展资源文件是否真的存在

虽然 Console 报告 JavaScript 文件加载失败，但还需要确认这些文件是否在磁盘中真实存在。

我检查了当前 Codex 扩展资源目录：

Bash

assets="$HOME/.vscode/extensions/openai.chatgpt-26.715.31925-linux-x64/webview/assets"

stat -c '%A  %U:%G  %s bytes  %n' "$assets"

find "$assets" -maxdepth 1 -type f | wc -l

assets="$HOME/.vscode/extensions/openai.chatgpt-26.715.31925-linux-x64/webview/assets"

stat -c '%A  %U:%G  %s bytes  %n' "$assets"

find "$assets" -maxdepth 1 -type f | wc -l

结果显示：

Plaintext

drwxrwxr-x  wangqiang:wangqiang
4959

drwxrwxr-x  wangqiang:wangqiang
4959

也就是说，资源目录中共有 4959 个文件。

随后检查报错中涉及的几个具体文件：

Bash

for file in \
  appshot-window-IWY5MCjg.js \
  use-chatgpt-composer-controller-5LuSW-YN.js \
  threads-create-DhlCLXwJ.js \
  codex-micro-DWAuwG0p.js \
  app-preloader-CPugGrqt.js
do
    stat -c '存在：%s bytes  %n' "$assets/$file"
done

for file in \
  appshot-window-IWY5MCjg.js \
  use-chatgpt-composer-controller-5LuSW-YN.js \
  threads-create-DhlCLXwJ.js \
  codex-micro-DWAuwG0p.js \
  app-preloader-CPugGrqt.js
do
    stat -c '存在：%s bytes  %n' "$assets/$file"
done

所有文件都存在，而且文件大小正常。

例如：

Plaintext

存在：2622 bytes  appshot-window-IWY5MCjg.js
存在：2032413 bytes  use-chatgpt-composer-controller-5LuSW-YN.js
存在：6701 bytes  threads-create-DhlCLXwJ.js
存在：1069 bytes  codex-micro-DWAuwG0p.js
存在：337 bytes  app-preloader-CPugGrqt.js

存在：2622 bytes  appshot-window-IWY5MCjg.js
存在：2032413 bytes  use-chatgpt-composer-controller-5LuSW-YN.js
存在：6701 bytes  threads-create-DhlCLXwJ.js
存在：1069 bytes  codex-micro-DWAuwG0p.js
存在：337 bytes  app-preloader-CPugGrqt.js

这说明扩展安装包并不是简单地缺少文件。

更准确地说，是：

文件在磁盘中存在，但 VS Code Webview 无法正常读取或加载这些文件。

八、清理 Service Worker 缓存

既然报错发生在 Webview 的资源加载层，我首先处理 VS Code 的 Service Worker。

完全关闭 VS Code 后执行：

Bash

source_dir="$HOME/.config/Code/Service Worker"
backup_dir="$HOME/.config/Code/Service Worker.bak-$(date +%Y%m%d-%H%M%S)"

mv "$source_dir" "$backup_dir"

source_dir="$HOME/.config/Code/Service Worker"
backup_dir="$HOME/.config/Code/Service Worker.bak-$(date +%Y%m%d-%H%M%S)"

mv "$source_dir" "$backup_dir"

本次没有直接删除目录，而是将其改名备份为：

Plaintext

/home/wangqiang/.config/Code/Service Worker.bak-20260720-171027

/home/wangqiang/.config/Code/Service Worker.bak-20260720-171027

这样做的好处是：

不会丢失原始目录；
随时可以恢复；
VS Code 下次启动会自动重新生成 Service Worker；
不会影响项目文件或 Git 仓库。

重新打开 VS Code 后，Codex 面板确实发生了变化：

原来的加载 Logo 消失；
但页面变成了完整的灰色空白区域。

图4：清理 Service Worker 后，Codex 面板由加载状态变成灰色空白

这说明缓存重建产生了一些影响，但问题没有真正解决。

九、继续清理其余可重建缓存

接下来我继续备份以下目录：

Plaintext

Cache
Code Cache
CachedData
GPUCache

Cache
Code Cache
CachedData
GPUCache

执行：

Bash

timestamp="$(date +%Y%m%d-%H%M%S)"

for name in \
    "Cache" \
    "Code Cache" \
    "CachedData" \
    "GPUCache"
do
    source_path="$HOME/.config/Code/$name"
    backup_path="$HOME/.config/Code/${name}.bak-$timestamp"

    if [ -e "$source_path" ]; then
        mv "$source_path" "$backup_path"
    fi
done

timestamp="$(date +%Y%m%d-%H%M%S)"

for name in \
    "Cache" \
    "Code Cache" \
    "CachedData" \
    "GPUCache"
do
    source_path="$HOME/.config/Code/$name"
    backup_path="$HOME/.config/Code/${name}.bak-$timestamp"

    if [ -e "$source_path" ]; then
        mv "$source_path" "$backup_path"
    fi
done

生成的备份包括：

Plaintext

Cache.bak-20260720-171447
Code Cache.bak-20260720-171447
CachedData.bak-20260720-171447
GPUCache.bak-20260720-171447

Cache.bak-20260720-171447
Code Cache.bak-20260720-171447
CachedData.bak-20260720-171447
GPUCache.bak-20260720-171447

重新打开 VS Code 后，Codex 面板仍然是灰色空白。

因此可以确认：

单独清理 Service Worker、Cache、Code Cache、CachedData 和 GPUCache，均未解决本次问题。

十、卸载并重新安装 Codex 扩展

下一步，我直接在 VS Code 扩展页面中卸载 Codex，然后重新安装 OpenAI 官方扩展。

扩展 ID 为：

Plaintext

openai.chatgpt

openai.chatgpt

重新安装后，Codex 面板依旧没有恢复，而是变成白色或灰白色空白页面。

图5：重新安装 Codex 扩展后，面板仍为空白

到这里，扩展安装损坏的可能性也进一步降低了。

十一、尝试回退 Codex 扩展版本

由于问题是当天突然出现的，我怀疑可能是 Codex 扩展更新导致的兼容问题。

在扩展管理菜单中选择：

Plaintext

安装其他版本

安装其他版本

当前故障版本为：

Plaintext

26.715.31925

26.715.31925

我先回退到 4 天前的版本：

Plaintext

26.707.91948

26.707.91948

图6：将 Codex 扩展回退到 4 天前的版本

安装完成后，扩展详情页显示：

Plaintext

版本：26.707.91948

版本：26.707.91948

但重启扩展和 VS Code 后，Codex 面板仍然无法显示。

随后又继续回退到一周前的版本。

结果仍然相同。

这里有一个值得注意的现象：

我可以确认一周前使用 Codex 时是正常的，但现在即使安装回当时的版本，问题依然存在。

因此，本次故障不能简单归结为“某一个 Codex 扩展版本存在 Bug”。

更可能的情况包括：

VS Code Webview 当前运行环境发生了变化；
某个系统资源或 Electron 状态出现异常；
扩展升级后留下了不只位于普通缓存目录中的状态；
新旧扩展与当前 VS Code 版本组合存在兼容边界；
Webview 同时加载大量资源时触发了当前环境中的资源限制。

目前可以确定故障位置，但还不能确认唯一根因。

十二、最终决定：暂时使用 Codex CLI

继续反复清理缓存、降级扩展或修改 VS Code 环境，时间成本已经开始高于问题本身。

而 Codex CLI 已经验证可以正常使用：

Bash

cd /home/wangqiang/code/wordpress-ai-excerpt-backfill
codex

cd /home/wangqiang/code/wordpress-ai-excerpt-backfill
codex

因此，我最终决定：

暂时停止排查 VS Code Codex 面板；
保留当前回退版本；
关闭 Codex 扩展自动更新；
先使用 Codex CLI 推进项目；
等官方后续修复或发布新版本后，再回到 VS Code 中测试。

十三、目前保留的备份目录

本次排查过程中，没有直接删除 VS Code 缓存，而是保留了以下备份：

Plaintext

~/.config/Code/Service Worker.bak-20260720-171027
~/.config/Code/Cache.bak-20260720-171447
~/.config/Code/Code Cache.bak-20260720-171447
~/.config/Code/CachedData.bak-20260720-171447
~/.config/Code/GPUCache.bak-20260720-171447

~/.config/Code/Service Worker.bak-20260720-171027
~/.config/Code/Cache.bak-20260720-171447
~/.config/Code/Code Cache.bak-20260720-171447
~/.config/Code/CachedData.bak-20260720-171447
~/.config/Code/GPUCache.bak-20260720-171447

暂时不恢复，也不删除。

等确认 VS Code 后续运行稳定，并且不再需要回滚时，再统一清理这些目录。

十四、本次排查能够确认的结论

经过这轮排查，目前可以确认以下几点。

1. Codex 服务和账号登录正常

Codex CLI 可以完成登录并正常进入项目目录，因此账号和服务本身没有明显问题。

2. 项目目录不是故障原因

无论打开空目录还是启动 CLI，项目路径均正常：

Plaintext

/home/wangqiang/code/wordpress-ai-excerpt-backfill

/home/wangqiang/code/wordpress-ai-excerpt-backfill

3. Codex 扩展资源文件真实存在

Console 中加载失败的 JavaScript 文件都存在于本机扩展目录，而且权限和文件大小正常。

4. 故障发生在 VS Code Webview 资源加载层

最直接的错误是：

Plaintext

insufficient resources

insufficient resources

以及：

Plaintext

net::ERR_FAILED

net::ERR_FAILED

失败请求主要指向：

Plaintext

file+.vscode-resource.vscode-cdn.net

file+.vscode-resource.vscode-cdn.net

5. 清理常规缓存没有解决问题

已经处理：

Plaintext

Service Worker
Cache
Code Cache
CachedData
GPUCache

Service Worker
Cache
Code Cache
CachedData
GPUCache

但问题依旧。

6. 重装和回退扩展也没有解决

重新安装最新版、回退到 4 天前版本和一周前版本后，Codex 面板仍然为空白。

7. 当前最实际的方案是使用 CLI

在根因尚未完全确认的情况下，CLI 是更稳定、维护成本更低的临时替代方案。

十五、后续计划

这次故障不再继续扩大排查范围。

后续我会：

继续使用 Codex CLI；
推进 wordpress-ai-excerpt-backfill 仓库初始化；
完成历史文章格式盘点；
保持 VS Code Codex 扩展不自动更新；
等待后续修复版本；
新版本发布后，再单独测试右侧 Codex 面板。

本次排查没有彻底修复 VS Code 中的 Codex 面板，但至少明确了问题边界，也建立了可以继续工作的替代路径。

相比继续投入大量时间追查一个暂时不影响核心任务的问题，先切换到 CLI，保持项目向前推进，是当前更合适的选择。

需要长期技术维护或远程问题排查？

我是拥有 15+ 年经验的 PHP / Go 后端工程师，长期关注已有系统维护、Bug 修复、性能优化、服务器排查、WordPress 网站维护和小功能迭代。

如果你的项目遇到以下情况，可以先从一次小问题排查开始合作：

✅ PHP / Laravel / Yii2 老项目无人维护
✅ Go / Gin 后端接口需要排查或优化
✅ WordPress 网站访问慢、报错或插件冲突
✅ Nginx / MySQL / Redis / Linux 服务器异常
✅ CDN / Cloudflare / DNS / HTTPS 配置问题
✅ 需要长期远程技术支持或兼职维护

更多介绍请查看：关于我 & 合作

微信：13980074657
邮箱：shuijingwanwq@gmail.com
Telegram：@shuijingwan
GitHub：https://github.com/shuijingwan

VS Code 中 Codex 面板持续加载与灰屏：从 Webview 资源错误排查到临时改用 CLI

一、问题表现：Codex 面板一直加载

二、先确认 Codex CLI 是否可用

三、登录 Codex CLI

四、为什么仍然希望修复 VS Code 面板

五、普通 Codex 输出日志没有提供有效信息

六、通过开发人员工具定位 Webview 错误

七、确认扩展资源文件是否真的存在

八、清理 Service Worker 缓存

九、继续清理其余可重建缓存

十、卸载并重新安装 Codex 扩展

十一、尝试回退 Codex 扩展版本

十二、最终决定：暂时使用 Codex CLI

十三、目前保留的备份目录

十四、本次排查能够确认的结论

1. Codex 服务和账号登录正常

2. 项目目录不是故障原因

3. Codex 扩展资源文件真实存在

4. 故障发生在 VS Code Webview 资源加载层

5. 清理常规缓存没有解决问题

6. 重装和回退扩展也没有解决

7. 当前最实际的方案是使用 CLI

十五、后续计划

评论

发表回复 取消回复

更多文章

从只读审计到 42/42 完成：用 GLM 与 SlyTranslate 安全补全 WordPress 历史文章摘要

在用 AI 批量补全 WordPress 历史文章摘要之前，我先建立了一套只读格式审计管线

VS Code 中 Codex 面板持续加载与灰屏：从 Webview 资源错误排查到临时改用 CLI

为 Codex 配置 GitHub HTTPS 凭据：使用 GitHub CLI 实现自动推送

发表回复取消回复