Codex VS Code 创建聊天时为何报错“AbsolutePathBuf deserialized without a base path”？

作者：袖梨 2026-09-12

Codex VS Code 创建聊天时报错“AbsolutePathBuf deserialized without a base path”，一个已复现原因是当前工作区包含非 file: 协议的虚拟文件夹。扩展把所有工作区 URI 的 fsPath 当成本机路径发送给 Codex 核心；在 Windows 上，部分虚拟 URI 会转换为没有盘符的 Root 一类字符串。Rust 核心要求绝对路径，反序列化整个请求时就会拒绝该值。

受影响的精确条件

公开复现使用 Windows、VS Code 1.131.0 和 Codex 扩展 26.721.41059，较早的 26.721.30844 也能复现。只要工作区中存在一个由 FileSystemProvider 提供的虚拟文件夹，新建聊天就可能失败。

常见来源包括 GitHub Repositories、Remote Repositories、Azure Repos 和第三方虚拟文件系统。即使多根工作区的第一个目录是正常本地文件夹，只要后面还有一个不合格的虚拟根，整个请求仍会失败。

为什么错误信息看起来与工作区无关

Codex 核心使用 AbsolutePathBuf 表示工作目录和工作区根。该类型要求输入已经是完整绝对路径，但扩展提交了缺少基础路径的字符串，因此错误发生在请求反序列化阶段。

它不会先创建聊天再忽略坏目录，而是把全部根目录作为一个请求解析。任一条路径不符合契约，整个新聊天创建都会失败，所以界面只显示底层路径类型错误。

虚拟 URI 如何变成无效路径

工作区 URIWindows fsPath 示例能否作为原生工作目录
GitHub 虚拟仓库microsoftvscode不能，缺少盘符或 UNC 主机
自定义虚拟根Root不能，属于盘符相对形式
映射到本机目录的 providerC:Usersmeanchor可以
本地 file URIC:Usersmeproject可以

关键不是 URI 名称，而是最终路径是否能作为操作系统原生的完全限定工作目录。

用公开扩展稳定复现

  1. 在 VS Code 安装 GitHub Repositories 扩展。
  2. 从命令面板运行“Open GitHub Repository”。
  3. 打开任意公开仓库，使工作区根使用 vscode-vfs: 协议。
  4. 打开 Codex 面板并发送任意新提示。
  5. 观察聊天创建是否报告 AbsolutePathBuf 错误。

为了证明多根工作区也受影响，可以再添加一个正常的本地文件夹。若错误仍存在，就说明一个虚拟根足以使整个请求失败，而不是第一个工作区根选择错误。

最快的用户侧规避方法

把虚拟目录从当前工作区移除，只保留真实本地目录，然后重新创建聊天。对于只存在于远程 provider 中的仓库，应先克隆到本地磁盘：

git clone repository-address
cd repository-directory
code .

打开 Codex 面板，确认项目指向这个本地目录后再发送提示。不要在同一个多根工作区中保留原虚拟根，否则坏路径仍可能随请求一起发送。

检查当前工作区是否含虚拟根

普通资源管理器不会总是明显显示 URI scheme。可以检查工作区文件：

{
  "folders": [
    { "path": "C:\src\local-project" },
    { "uri": "myfs:/Root" }
  ]
}

带 uri 且不是 file: 的条目通常是虚拟工作区。另一个信号是窗口由“Open Remote Repository”一类命令创建，而本地磁盘上没有对应仓库目录。

保存修改前备份 .code-workspace 文件。移除条目只会改变工作区组成，不会把远程仓库自动下载到本地。

为什么添加一个本地根仍然无效

公开代码显示，扩展会映射全部 workspaceFolders，再把结果用于活动工作区根和工作区选项。请求反序列化是整体操作，不会因为第一个根有效就跳过后面的无效根。

因此，改变根目录顺序通常只是碰运气，不能构成修复。用户侧必须移除或关闭虚拟根，扩展侧则应在发送请求前过滤不能作为原生工作目录的值。

不要把所有非 file scheme 都简单丢弃

从扩展开发角度看，直接判断 uri.scheme === 'file' 虽然能排除常见虚拟 URI，却可能误删合法的 passthrough provider。某些 provider 使用自定义 scheme，但其 fsPath 最终确实是完整的本机路径。

真正的契约应是“最终字符串是不是完全限定的原生绝对路径”。Windows 上通常要求盘符加根分隔符，或合法 UNC 路径；POSIX 上则要求以 / 开始。

为什么 path.isAbsolute 仍可能太宽松

Windows 的 path.win32.isAbsolute 会把 Root 判断为绝对形式，但它没有盘符或 UNC 主机，仍不能满足 Codex 核心的完整路径要求。因此，只调用通用 isAbsolute 可能让同一个错误值继续通过。

扩展需要验证盘符根路径或 UNC 路径，并为 POSIX 单独处理。过滤后如果仍有合法根，可以用第一个根作为工作目录；如果一个都没有，应显示“Add a project to use Codex”一类可理解状态，而不是发送必然失败的请求。

扩展实现应如何修正

  1. 读取每个工作区文件夹的 URI 和 fsPath。
  2. 按照目标平台验证最终路径是否完全限定。
  3. 过滤不能作为原生工作目录的根。
  4. 只把合格根发送为 cwd 和 workspaceRoots。
  5. 零个合格根时显示明确的项目选择提示。
  6. 在错误中包含经过脱敏的根类型或 scheme。

扩展还应声明对 virtual workspace 的支持程度，让 VS Code 在功能受限时提前提示，而不是默认表现为完全支持。

开发者回归测试矩阵

工作区组合预期结果
仅本地 file 根聊天正常创建
仅普通虚拟根提示添加本地项目，不提交坏路径
本地根加虚拟根过滤虚拟根，使用本地根
虚拟根加本地根结果与顺序无关
自定义 scheme 映射完整路径若路径契约满足则保留
Windows 盘符相对路径拒绝并给出可理解提示
UNC 路径合法时正常使用

如何确认自己遇到的是这一缺陷

  1. 错误发生在创建新聊天时，文本完全匹配 AbsolutePathBuf。
  2. 当前窗口至少包含一个 virtual workspace。
  3. 只打开同一仓库的本地克隆后，聊天可以创建。
  4. 把虚拟根加入多根工作区后，错误再次出现。

如果纯本地 file: 工作区也同样失败，就不能直接归因于这一缺陷。相同错误还可能来自 WSL 路径、恢复后的远程会话或其他路径转换问题，应另行保存日志和复现条件。

当前结论

在这个可复现问题中，原因不是聊天内容或 API 密钥，而是扩展把虚拟工作区 URI 派生出的非完整路径传给了要求绝对路径的 Rust 核心。用户当前最可靠的规避方式是只在真实本地项目目录中创建聊天，并从多根工作区移除虚拟根。永久修复需要扩展在请求前验证最终原生路径、过滤不合格根，并在没有可用项目时显示明确提示。

相关文章

精彩推荐