Codex 在 Linux 的 NTFS 项目中为何出现“AbsolutePathBuf deserialized without a base path”？

Codex 在 Linux 的 NTFS 项目中出现“AbsolutePathBuf deserialized without a base path”，公开案例实际影响的是 Linux 原生 ChatGPT 桌面端的 Plugins 页面。只要桌面项目列表中保留一个位于 NTFS/ntfs3 挂载点的项目，plugin/installed 请求就会失败；同一环境中的 plugin/list 和 Codex CLI 仍可正常工作。

先明确已确认与未确认的部分

案例运行在 Arch Linux 原生桌面环境，项目路径类似 /mnt/d/FromGithub/SomeRepo，挂载类型为 ntfs3。报告者验证了以下事实：

• 项目路径是合法的 POSIX 绝对路径。
• realpath 和 stat 可以访问该目录。
• Codex CLI 能以该目录作为工作目录运行。
• 从桌面项目列表移除 NTFS 项目并重启后，Plugins 页面立即恢复。
• 重新添加普通主目录项目不会触发错误。

尚未确认的是请求内部究竟收到了 null、相对残留路径还是其他值。报告者推测工作区根规范化失败后，错误值进入 cwds，但没有捕获到最终请求载荷。因此不能把这段实现推断写成维护者确认的根因。

为什么路径合法仍会被拒绝

AbsolutePathBuf 是 Codex 核心用于保证路径绝对性的类型。报错意味着反序列化收到的某个值不满足绝对路径契约，不代表用户最初选择的 /mnt/d/... 字符串本身一定不合法。

桌面端在请求插件状态前还可能规范化、解析或转换项目根。若其中一步失败并把空值或不完整结果保留下来，Rust 核心看到的是转换后的值，而不是用户界面显示的原路径。当前证据只确认 NTFS 项目是稳定触发条件。

复现故障的条件

1. 在 Linux 原生桌面系统挂载 NTFS 数据盘。
2. 把挂载点下的本地仓库添加到 Codex 桌面项目列表。
3. 打开 ChatGPT 桌面端并进入 Plugins 页面。
4. 观察页面加载失败，日志中 plugin/installed 返回 -32600 和 invalid_config。

如果错误发生在 VS Code 新建聊天、Windows WSL 或远程线程恢复中，虽然错误文本相同，也不能自动归入这一 NTFS 案例。应按照各自请求中的路径来源排查。

检查项目所在文件系统

project=/mnt/d/FromGithub/SomeRepo
findmnt -T "$project"
df -T "$project"
realpath "$project"
stat "$project"

findmnt 可以显示具体挂载点、文件系统和选项。记录是内核 ntfs3、FUSE 驱动还是其他实现，因为不同驱动的权限、符号链接和文件名语义可能不同。

验证 CLI 是否受到影响

cd /mnt/d/FromGithub/SomeRepo
codex --version
codex exec "列出当前目录的顶层文件，不要修改任何内容"

若 CLI 能正常以该目录运行，而桌面 Plugins 页面失败，说明问题集中在桌面项目列表到插件请求的路径处理。若 CLI 也失败，应先调查挂载权限、路径可访问性和更广泛的 Codex 配置问题。

首选规避：从项目列表移除

最安全的临时方案是通过桌面界面移除位于 NTFS 的项目，然后完全退出并重新打开应用。移除项目条目不应删除磁盘上的仓库，但操作前仍应确认界面动作是“Remove”而不是文件删除。

恢复后添加一个位于 Linux 主目录原生文件系统的测试项目，例如 ~/Projects/test-app，再打开 Plugins 页面。如果页面正常，说明触发条件已被隔离。

状态不在 config.toml 中

桌面项目列表保存在 ~/.codex/.codex-global-state.json 的 local-projects 和 project-order 中，与 config.toml 里的项目配置是不同存储。只修改 config.toml 不会移除这个触发路径。

优先使用界面移除。只有界面无法打开时，才考虑手动编辑状态文件，并且必须先关闭应用、备份文件：

state="$HOME/.codex/.codex-global-state.json"
backup="$state.backup-$(date +%Y%m%d-%H%M%S)"
cp -a "$state" "$backup"
printf 'Backup: %sn' "$backup"

使用 JSON 编辑器删除目标项目在 local-projects 和 project-order 中的对应条目，不要用简单文本替换破坏 JSON 结构。修改后先运行解析检查：

jq empty "$HOME/.codex/.codex-global-state.json"

不要直接删除整个全局状态

全局状态文件还可能包含其他项目顺序和应用设置。删除整个文件会造成比当前问题更大的状态丢失，也无法帮助维护者定位是哪一个根触发错误。

正确做法是先备份，只移除已确认的 NTFS 项目条目，并保留修改前后的脱敏差异。若手动编辑后应用行为异常，应在应用完全退出时恢复备份。

迁移到 Linux 原生文件系统

需要继续从桌面端使用该项目时，可以把仓库复制或重新克隆到 Linux 原生文件系统。重新克隆更容易避免携带文件权限和大小写语义问题：

mkdir -p "$HOME/Projects"
cd "$HOME/Projects"
git clone repository-address project-name

未提交改动、Git LFS 对象、子模块和未跟踪文件需要单独核对。不能把重新克隆当成原目录的自动完整备份。

如何确认规避方案有效

测试	期望结果
项目列表含 NTFS 根	Plugins 页稳定复现错误
移除 NTFS 根并重启	plugin/installed 返回成功
添加主目录项目	Plugins 页继续正常
CLI 在 NTFS 根运行	若与原案例一致则不受影响
重新加入 NTFS 根	仅在需要提供复现证据时测试

不要在包含重要工作状态的环境中反复加入触发项目。完成一次可重复对照并收集日志后，应恢复到可用状态。

开发者侧应修正什么

无论规范化失败的具体原因是什么，一个坏项目根都不应让整个插件查询失败。更稳健的请求构造应：

1. 逐个规范化项目根并记录失败原因。
2. 过滤空值、相对路径和不可表示的结果。
3. 只把合法绝对路径传给 plugin/installed。
4. 某个根失败时继续处理其他有效项目。
5. 向界面返回可理解的项目路径错误。

另一种思路是在反序列化时提供明确的基础路径，但这只适合真正可相对解析的输入。对于规范化失败产生的空值，过滤和诊断比猜测基础路径更安全。

收集可用的问题报告

1. 记录桌面应用、内置 Codex CLI、内核和发行版版本。
2. 提供 findmnt -T 的文件系统类型和脱敏挂载选项。
3. 说明 realpath、stat 和 CLI 是否成功。
4. 附上 plugin/installed 的错误码和时间。
5. 说明移除 NTFS 项目后是否立即恢复。
6. 避免公开完整项目路径、账号、令牌和会话内容。

当前结论

该问题确认了一个窄而稳定的触发条件：Linux 原生桌面端的项目列表中存在 NTFS/ntfs3 项目时，Plugins 页的 plugin/installed 请求会因 AbsolutePathBuf 反序列化失败而中断。项目原路径本身已被验证为健康，具体在哪一步转成坏值仍未捕获。

用户侧最可靠的临时方案是从桌面项目列表移除 NTFS 项目，或把仓库迁移到 Linux 原生文件系统；CLI 可以继续作为不受该页面故障影响的替代入口。永久修复需要桌面端在发送 cwds 前过滤规范化失败的根，并避免一个坏条目拖垮整个请求。