Codex VS Code 插件为何无法加载以前的对话？

作者：袖梨 2026-09-13

Codex VS Code 插件无法加载以前的对话，不等于对话文件已经丢失。公开问题中的环境是 Linux 上的 VS Code Server：旧会话仍保存在 ~/.codex，但打开旧对话时，多条 SQLite 初始化和维护语句分别耗时约 5 至 10 秒，数据库连接获取也超过慢查询阈值。现有证据更像是会话恢复链路被本地状态数据库的 I/O 或锁等待拖住，而不是会话内容不存在。

先区分“列表不显示”和“数据已丢失”

官方排障文档给出的默认会话目录是 ~/.codex/sessions，归档会话默认位于 ~/.codex/archived_sessions。先只读确认目录和文件是否存在：

find ~/.codex/sessions -type f | head
find ~/.codex/archived_sessions -type f | head
du -sh ~/.codex/sessions ~/.codex/archived_sessions 2>/dev/null

目录中有会话文件，只能证明底层内容仍在；侧边栏还需要读取状态数据库、按项目筛选并构建列表。反过来，列表为空也不能直接证明文件被删除。

公开日志透露了什么

该问题使用 Codex IDE 扩展 26.422.30944，运行在 VS Code Server 和 Linux 远程主机上。恢复旧对话时出现了以下几类慢操作：

  • 读取 SQLx 数据库迁移版本约 5 秒。
  • 执行 PRAGMA wal_checkpoint(TRUNCATE) 约 5 秒。
  • 设置 journal_mode=WAL 等 SQLite 参数接近 10 秒。
  • 从连接池获取连接接近 10 秒。
  • 创建迁移表和清理旧日志各约 5 秒。

这些不是“数据库已损坏”的直接证据，但足以说明会话加载期间的数据库访问异常缓慢。日志中还有 query-cache-invalidate 没有处理器的警告；仅凭这条广播警告，不能断言它是失败原因。

为什么远程 VS Code 环境尤其值得检查

VS Code Server 的扩展进程和 Codex 本地数据运行在远程主机，而不是用户面前的桌面系统。远程主目录可能位于 NFS、企业网络文件系统、加密挂载或配额受限磁盘。

SQLite 的 WAL checkpoint、文件锁和同步写入对文件系统语义与延迟较敏感。若 ~/.codex 位于高延迟共享目录，即使会话 JSONL 文件可见，维护状态数据库仍可能长时间阻塞。这里是由日志推导出的排查方向，不是该 issue 已确认的根因。

记录本地端与远程端边界

在 VS Code 集成终端中运行：

hostname
uname -a
pwd
printf '%sn' "${CODEX_HOME:-$HOME/.codex}"
df -T "${CODEX_HOME:-$HOME/.codex}"
df -h "${CODEX_HOME:-$HOME/.codex}"
df -i "${CODEX_HOME:-$HOME/.codex}"

确认命令执行在远程主机，并记录 Codex 数据目录所在文件系统类型、剩余空间和 inode。磁盘未满不代表延迟正常，但空间或 inode 耗尽必须优先处理。

保存扩展与会话证据

在无法打开旧会话的现场，先从 VS Code“输出”面板保存 Codex 和扩展宿主日志，再运行 Developer: Open Logs Folder。记录点击旧会话的准确时间，便于对应慢查询。

分享日志前删除令牌、账号、服务器名、项目路径、提示词和源代码。不要把整个 ~/.codex 上传到公开 issue，因为会话目录可能包含敏感工作内容。

检查权限与异常文件

ls -ld ~/.codex ~/.codex/sessions ~/.codex/archived_sessions
find ~/.codex -maxdepth 2 -type f -size 0 -print | head -50
find ~/.codex -maxdepth 2 ! -user "$(id -un)" -print | head -50

若以前用 sudo 运行过 Codex，部分文件可能属于 root，导致扩展无法正常更新。先核实目标文件确实属于当前用户，再修正具体文件；不要对整个主目录执行递归改权。

测量文件系统而不是凭感觉判断

在 Codex 数据目录旁创建无敏感测试文件，观察同步写入和重命名是否明显卡顿：

test_dir="${CODEX_HOME:-$HOME/.codex}/io-check"
mkdir -p "$test_dir"
time sh -c 'dd if=/dev/zero of="$1/test.bin" bs=1M count=16 conv=fsync status=none' sh "$test_dir"
time mv "$test_dir/test.bin" "$test_dir/test-renamed.bin"
rm "$test_dir/test-renamed.bin"
rmdir "$test_dir"

这不是数据库基准测试，但可以快速发现极端写入延迟。企业共享文件系统上的结果应与远程主机本地磁盘做对照，不能套用统一毫秒阈值。

检查是否存在残留进程和长期锁等待

ps -u "$(id -u)" -f | grep -E '[c]odex|[v]scode-server'
lsof +D "${CODEX_HOME:-$HOME/.codex}" 2>/dev/null | head -100

多个远程 VS Code 窗口可能同时访问同一 Codex 数据目录。测试时先正常关闭其他窗口和 Codex 进程，再用单一窗口复现。不要直接终止不属于当前用户或用途不明的进程。

备份后做隔离对照

在任何重建操作前，先完全退出远程 VS Code Server 中的 Codex 会话，并备份数据目录：

backup_dir="$HOME/codex-backup-$(date +%Y%m%d-%H%M%S)"
cp -a "${CODEX_HOME:-$HOME/.codex}" "$backup_dir"
printf 'Backup: %sn' "$backup_dir"

然后可用一个全新的临时 CODEX_HOME 启动隔离测试，而不是删除原目录：

mkdir -p "$HOME/.codex-test-empty"
CODEX_HOME="$HOME/.codex-test-empty" code .

如果新目录能快速创建和打开会话，说明原状态目录参与了故障；如果新目录同样缓慢，继续检查文件系统、远程扩展宿主和系统负载。

用本地磁盘验证共享存储假设

若远程主目录位于 NFS 或其他共享文件系统，可以在管理员允许的本地磁盘位置创建临时 Codex 目录进行对照。测试目录必须只有当前用户可读：

mkdir -p /var/tmp/$USER/codex-test
chmod 700 /var/tmp/$USER /var/tmp/$USER/codex-test
CODEX_HOME=/var/tmp/$USER/codex-test code .

本地磁盘稳定而共享主目录持续出现 5 至 10 秒 SQLite 操作，才支持“文件系统延迟或锁语义”这一方向。测试目录不应作为永久迁移目标，除非已经评估备份、加密、清理和多主机访问要求。

不要盲目删除数据库文件

日志提到 WAL checkpoint，并不代表删除 -wal、-shm 或主数据库文件是安全修复。进程仍在运行时删除 SQLite 辅助文件可能造成不一致；删除主数据库还可能丢失会话索引、日志或其他状态。

若维护者要求重建某个明确数据库，应先退出所有 Codex 进程、完成可验证备份，并只移动指定文件到隔离目录。移动比直接删除更容易恢复。

排除侧边栏筛选问题

远程会话通常与项目路径绑定。确认当前打开的是原项目的相同绝对路径，而不是符号链接、容器挂载路径或重命名目录。若聊天列表提供筛选器，切换到按时间显示并检查归档列表。

如果旧会话能在其他 Codex 界面看到但当前 VS Code Server 看不到，记录两边使用的 CODEX_HOME、用户账号和项目路径。它们不同会形成两个独立的本地会话集合。

提交有效的补充信息

  1. 报告 IDE 扩展、VS Code Server、操作系统和文件系统类型。
  2. 说明会话文件是否仍存在，以及当前 CODEX_HOME。
  3. 附上脱敏后的慢查询与扩展宿主日志。
  4. 报告空白 CODEX_HOME 和本地磁盘对照结果。
  5. 说明问题是否只发生在旧会话、特定项目或所有聊天。

当前最合理的处理顺序

该公开问题尚未给出维护者确认的最终修复，因此不能承诺升级或清库必然有效。现有日志明确表明，恢复旧会话时 SQLite 初始化、WAL checkpoint 和连接获取异常缓慢。应先证明会话文件仍在，再保存日志、核对远程路径和权限、测量文件系统，最后通过空白状态目录和本地磁盘做隔离对照。这样既能避免误删历史会话，也能把“侧边栏不显示”缩小到索引状态、远程文件系统或扩展恢复逻辑中的具体一层。

相关文章

精彩推荐