Codex VS Code 侧边栏为何在 Linux Wayland 中卡在 Logo 或显示空白？

Codex VS Code 侧边栏在 Linux Wayland 中卡在 Logo 或显示灰色空白，公开日志表明故障发生在 WebView 前端启动阶段，而不是 Codex app-server 初始化或 ChatGPT 登录阶段。失败时日志停在 Initialize received id=1；成功时还会出现 React 根节点渲染、路由挂载和 provider 就绪消息。换句话说，后台已经启动，但侧边栏前端没有完成与扩展 IPC 路由的连接。

先明确这不是已确认的单一 Wayland 缺陷

对应问题的环境是 Linux x86_64、Wayland、VS Code 1.129.1、Codex 扩展 26.715.31925，扩展内置 Codex CLI 为 0.145.0-alpha.18。问题会随机出现，相同配置的不同冷启动可能一次正常、一次卡住。

临时用户数据目录在原生 Wayland 和 X11/XWayland 下都曾成功启动，但原用户目录重建后也只正常一次，随后故障复发。因此，“发生在 Wayland 会话”是环境条件，现有证据不足以把 Wayland 本身认定为唯一根因。

用日志定位启动链路

失败启动通常止于以下顺序：

Activating Codex extension
Spawning codex app-server
I am the router
Initialize received id=1

成功启动还会继续出现类似消息：

React root render requested
app routes mounted
ready provider mounted

这组差异非常关键。它说明扩展激活、app-server 创建和初始握手已经发生，但失败窗口中没有观察到 WebView 前端挂载。排查重点应放在 WebView 创建、资源加载、前端 JavaScript 执行和 IPC 连接，而不是先清理账号或更换模型。

在恢复操作前保存现场

1. 记录 Codex Logo 持续显示或灰色面板出现的时间。
2. 在“输出”面板选择 Codex，保存从激活开始的完整日志。
3. 运行 Developer: Open Logs Folder，保留窗口、主进程和扩展宿主日志。
4. 运行 Developer: Toggle Developer Tools，检查 Console 与 Network。
5. 不要先重新加载 WebView，否则日志可能混入恢复路径产生的新错误。

公开案例在一次手动重新加载 WebView 时看到 Blocked vscode-webview request。这条消息值得保留，但它没有在最新的干净失败启动中再次出现，因此更可能是恢复操作相关症状，不能单独作为根因。

确认后台是否真的正常

在集成终端中检查扩展和内置二进制版本：

code --version
code --list-extensions --show-versions | grep openai

再检查独立 Codex CLI 的登录状态和基本调用。独立 CLI 正常并不能证明扩展内置二进制正常，但可以帮助排除账号和服务完全不可用。

该公开问题中，独立和扩展内置的 Codex 二进制都显示已通过 ChatGPT 登录，CLI 也可用。因此反复退出登录缺少证据支持，并可能制造新的认证变量。

不要把硬件加速当作确定修复

案例最初在禁用硬件加速时出现，重新启用后曾有一次成功启动，但稍后的冷启动在硬件加速开启状态下再次失败。该对照已经否定了“开启硬件加速即可修复”的稳定结论。

仍可把硬件加速作为诊断变量，但测试必须成组进行：

1. 固定扩展、VS Code、项目和用户数据目录。
2. 分别在开启和关闭状态下执行多次完整冷启动。
3. 每次都记录是否出现 React 根挂载消息。
4. 比较成功率和日志，不以单次结果下结论。

比较 Wayland 与 X11/XWayland

先确认当前会话类型：

printf '%sn' "$XDG_SESSION_TYPE"
printf '%sn' "$WAYLAND_DISPLAY"
printf '%sn' "$DISPLAY"

可以用同一个临时用户数据目录分别测试原生 Wayland 与 X11/XWayland。对照时保持扩展版本和项目一致，避免同时改变多个变量。

公开报告在两种显示后端的临时目录中都曾成功，但真实目录仍会随机失败。这说明切换后端可能改变时序，却不能证明故障完全由显示协议造成。

使用临时用户数据目录做隔离

mkdir -p /tmp/codex-vscode-wayland/user-data
mkdir -p /tmp/codex-vscode-wayland/extensions
code --user-data-dir /tmp/codex-vscode-wayland/user-data 
  --extensions-dir /tmp/codex-vscode-wayland/extensions

只安装 Codex，完成登录后重复打开侧边栏和冷启动。如果临时目录能稳定工作，原用户目录中的 Chromium/WebView 数据、缓存、其他扩展或状态值得继续分层比较。

但临时目录一次成功并不够。公开案例甚至把原 User/ 配置完整复制到临时目录后成功，也在重建真实用户数据根目录后成功过一次，随后仍复发。随机或时序敏感故障必须以多次启动统计验证。

如何安全重建用户数据

重建 VS Code 用户数据会影响设置、扩展状态、工作区状态和 WebView 缓存。只有完成备份后才应测试：

code_config="$HOME/.config/Code"
backup="$HOME/Code-user-data-backup-$(date +%Y%m%d-%H%M%S)"
cp -a "$code_config" "$backup"
printf 'Backup: %sn' "$backup"

先用 --user-data-dir 做可逆隔离，比直接删除真实目录安全。即使重建后首次成功，也要多次完全退出再启动；该 issue 已证明首次成功不代表状态永久修复。

“重新加载 WebView”应如何使用

Developer: Reload Webviews 可以触发一次前端重建，适合验证 WebView 路径是否参与故障。使用前保存日志，使用后单独记录新产生的请求阻止或渲染异常。

公开案例中，重新加载 WebView、禁用再启用扩展、重启 VS Code 都不是稳定恢复手段。它们可以改变故障时序，却不应写进长期修复清单。

网络错误为何未被视为主因

某次失败启动在初始化约 37 秒后记录了远程插件目录预热网络错误，但 WebView 前端在此之前就没有挂载。其他前端成功挂载的会话也出现过后续网络失败。

因此，时间顺序和对照样本都不支持把该网络错误解释为缺少前端 IPC 连接的原因。排障时应优先看第一个分叉点，而不是日志中最后出现的错误。

构造成功与失败对照表

观察项	失败启动	成功启动
扩展激活	出现	出现
app-server 初始化	完成到 id=1	完成
React 根渲染	未出现	出现
路由挂载	未出现	出现
前端 IPC 连接	未观察到	已建立
登录状态	已登录	已登录

提交问题时附上同一机器、同一配置下的一组成功和失败日志，比只提交空白截图更容易定位时序差异。

采集最小复现信息

1. 记录发行版、内核、桌面环境和 XDG_SESSION_TYPE。
2. 记录 VS Code、Codex 扩展和内置 Codex CLI 版本。
3. 说明硬件加速状态以及 Wayland 或 X11 启动参数。
4. 分别保存一次失败和一次成功的 Codex、主进程及 WebView 日志。
5. 报告临时用户数据目录连续多次冷启动的结果。
6. 说明重新加载 WebView是否产生 Blocked vscode-webview request。

日志公开前应删除访问令牌、账号、项目路径、提示词和源代码。若可稳定复现，应在 Codex GitHub 仓库的现有 issue 中补充信息，避免分散到缺少上下文的新报告。

当前结论与临时策略

目前最强的证据是：失败启动已完成 app-server 初始化，却没有进入 WebView 的 React 渲染、路由挂载和前端 IPC 连接阶段。该问题表现为随机或时序敏感的 WebView 前端启动故障，仍没有稳定的本地修复。

重复完整重启有时能恢复，但不能保证下一次启动。遇到问题时应先保存失败日志，再用临时用户目录、Wayland/X11 和硬件加速做受控对照。不要反复清除认证、删除用户数据或把单次成功当作根治；这些操作既可能丢失现场，也已被公开复现证明不稳定。