Codex 新聊天提示 Cannot serialize value？先查版本，再区分 Local 与 Worktree

Codex 新聊天一发送就报 Cannot serialize value: (couldn't stringify value)，先记下应用版本并检查更新。如果仍然出现，再用同一个项目，对比新建 Local 聊天与 Worktree 聊天。 不要一上来就删除聊天记录、换 API Key，或重置代码仓库。

2026 年 10 月的桌面端报告里出现过这个错误。目前相关问题已关闭，也有用户报告在特定 macOS、Windows 版本更新后恢复。因此，先核对版本，比照搬旧帖里的所有处理办法更有意义。

本文针对的是新聊天提交失败，尤其是选择 Worktree 时失败。依据为公开问题报告与保守的排查流程；Ofox 没有在受控环境复现原始故障。下面是诊断步骤和有条件的替代路径，不是保证有效的修复，也不表示更换 Ofox API Key 可以解决客户端故障。

先看版本，别把历史故障当成所有版本的现状

以下内容整理自 OpenAI 仓库的 issue #55744，核对日期为 10 月 28 日。这是用户报告汇总，不是覆盖全部平台的官方支持表。

macOS 恢复反馈与 Windows 恢复反馈是两条独立观察。如果较旧版本的更新器显示“已是最新”，它只说明当前安装环境暂时没有可用更新，不能证明其他平台提到的修复已装到本机。

先把未发出的提示词保存在本地，保存或暂停正在进行的工作，再通过应用支持的方式检查更新。分别记下更新前后的版本；按更新提示重启后，回到同一项目，用一条简单消息测试。不要从非官方镜像下载旧安装包，也不要直接改应用安装目录里的代码。

确认失败阶段，而不是只搜索一句报错

序列化是把数据转换成便于传递或保存的形式。单看这个词，不能知道哪个数据有问题、模型请求是否已经发出，更不能认定仓库损坏。

改设置前，先记三项：

1. 发生阶段：应用打不开、首条消息发不出去，还是任务运行到中途才失败？
2. 运行模式：新聊天选的是 Local 还是 Worktree？是否关联 Git 项目？
3. 错误原文：保存完整短消息，包括括号里的文字。旁边如果有另一种报错，要分开记录。

实际提示是 couldn’t load workspace settings，应查工作区初始化；扩展提示 couldn’t load its resources，应查资源加载；输入框提示 permission mode is unavailable，则按权限模式的提交检查处理。都发生在打开聊天附近，不代表原因相同。

问题帖中有对客户端序列化的分析，也有人提出富文本文档属性可能相关。这些分析有助于缩小调查范围，但不足以要求每个用户删掉标点、改用英文输入，或重写项目里的 JSON 文件。短纯文本提示词可以用作对照，不是保证有效的修复。

用最小操作对比 Local 与 Worktree

先用下面的诊断提示词，不要直接拿真实开发任务试：

只回复 OK。不要读取或修改文件，不要执行命令，
不要安装依赖，也不要开始任何项目任务。

保持账号、项目、应用版本不变。先在新 Local 聊天发送，再在新 Worktree 聊天发送同一条消息。注意，新建工作树可能触发项目配置的初始化脚本：先检查该配置；如果会产生额外操作，就改用无副作用的测试仓库。不要为收集更多样本而反复测试生产项目。

拿到有用的对照结果就停止重复点击发送。连续重试会增加日志噪声，也容易把第一次失败与后续问题混在一起。Local 收到回复，只能说明这条路径在当时可用，并未验证工作树隔离或初始化成功。

Local 能用时，先决定是否需要隔离目录

Local 在当前选中的代码目录里工作；独立 Worktree 有自己的工作目录。因此，切到 Local 不只是换一个选项，还可能改变后续修改落到哪里，不能把它当作相同的隔离保障。

如果只是讨论或只读分析，可以先留在正常的 Local 聊天。允许改代码之前，要检查当前目录状态，并确认没有其他任务同时修改它。保留未提交和未跟踪文件。git reset --hard、git clean 或清空缓存，都不应被当成序列化报错的通用修复。

如果任务确实需要隔离，问题帖中有“先启动 Local，再创建应用管理的工作树”的成功报告。只有当前安装版本确实提供这项能力时才尝试，并在修改文件前检查它返回的目录。可以使用下面的任务说明：

不要修改当前代码目录。先确认本任务需要的起始分支或提交，
并报告解析后的 commit。若应用支持，使用其正式能力创建独立的
受管理工作树，返回绝对路径与 HEAD。此后的项目操作全部在该路径中进行。
若创建或关联失败，停止修改文件，报告具体错误。

起始版本应按任务要求确定，不要照抄 master。新建工作树不会自动继承原目录的未提交修改；如果任务需要这些内容，应先保存，再明确安排如何转移。

继续工作前，用只读 Git 命令核对返回的路径：

git -C /absolute/path/to/worktree rev-parse --show-toplevel
git -C /absolute/path/to/worktree rev-parse HEAD
git -C /absolute/path/to/worktree status --short
git -C /absolute/path/to/worktree worktree list

把示例路径换成真实路径；含空格时加引号。确认它是独立目录，提交与约定的起点一致，初始改动也都有解释。目录存在，不等于应用已经关联成功，更不等于后续命令自动在该目录执行。如果应用没有相应能力，就保留只读工作，或使用已有的受支持开发方式，不要把普通文件夹复制冒称受管理工作树。

诊断信息怎样整理才有用

使用应用支持的反馈或诊断入口。公开报告中有 TypeError、输入框提交失败、mode=worktree 等信息；应查自己测试时间附近的对应事件，而不是把别人的调用栈当成本机日志。

只保留相关事件。原始日志可能包含提示词、本地路径、仓库名、认证信息或会话标识，分享前应脱敏。下面是编辑整理的记录模板，不是本次实际日志：

系统与架构：
桌面应用版本及 build：
测试时间与时区：
界面错误原文：
新聊天还是已有聊天：
项目类型：Git / 非 Git / 无项目
Local 测试：成功 / 具体错误 / 未测试
Worktree 测试：成功 / 具体错误 / 未测试
是否有更新，更新后结果：
是否创建了工作树目录：
相关诊断字段（已脱敏）：
两次测试之间改了什么：

不要把尚在推测的序列化机制，写成已经证实的本机根因。对维护者更有帮助的是：失败发生在目录创建前、初始化中，还是任务已经启动后。给出这个阶段区别和最小复现过程，无需上传私有项目源码。

怎样判断真正恢复

恢复的标准是原来要完成的操作可以成功，而不是提示条消失。针对直接新建 Worktree 失败，应验证：新 Worktree 聊天能接收简单提示词，应用显示的是预期代码目录，再新建一次也能正常启动。然后在核实过的目录里继续一个小任务，检查实际改动。

如果只有 Local 正常，就记录为“临时替代路径可用，直接创建 Worktree 仍失败”。如果还没有可用更新，保留版本和诊断证据提交支持。若报错变了，从 Codex 报错索引转到对应问题，不要继续把旧帖里的办法全部执行一遍。

本文由 Ofox 面向开发者整理。更换模型供应商、购买 API 额度或提高模型限额，都不能据此证明桌面端序列化故障得到修复。