Codex 报错 Cannot serialize value：先关新建工作树，再选隔离路线

在 Codex 里新建对话，发出第一条消息后弹出：

启动聊天时出错
Cannot serialize value: (couldn't stringify value)

英文界面的横幅是 Error starting chat。如果 app 版本是 26.1016.51333，而且这个对话开着“新建工作树”（Worktree 模式），基本可以确定碰上的是这一版的已知问题：跟你的仓库、提示词、网络和安装都没有关系，重启、重装也不会好。

马上能做的：在新对话里关掉“新建工作树”、改用 Local，再发一次，消息就能正常发出，不用重启 app。代价是 Codex 会直接改你本地检出的目录。还需要工作树隔离的话，可以先用 Local 发第一条再 Hand off 到 Worktree，或者在 Local 对话里让 Codex 自己建一个受管工作树；几条路线在哪些平台有人实测过，下面有对照。

截至 2026 年 10 月 22 日，GitHub 上的 issue #55744 仍未关闭，帖子里没有 OpenAI 成员回复，官方也没有发布修复版本。

是不是 26.1016 的 Worktree bug：版本、模式、Local 三点对照

下面三点都对得上，就是这个问题：

1. 版本号是 26.1016.51333（build 21161）。Windows 上的安装包名会显示成 OpenAI.Codex_26.1016.6573.0_x64，app 的 About（关于）信息里显示的仍是 26.1016.51333，两个数字指的是同一版。报告里有人写 Codex desktop，有人写 ChatGPT desktop，也是同一个 app：2026 年 7 月 9 日起，Codex 已经并入 ChatGPT 桌面版。
2. 只在 Worktree 模式出错。开着“新建工作树”发第一条消息就失败，连 你好 这样的纯文字都不行，跟附件、@ 引用无关。新建对话时不会报错，报错出现在点发送之后。
3. 同一条消息改用 Local 能正常发出。

据 issue 里的用户报告，macOS、Windows、Linux 都能复现；项目放在 SSH 远程主机上也一样，有人是 Windows 连 Linux 主机，有人是 macOS 连远程 Mac。多数人是 10 月 21 日更新后开始遇到。一位 Windows 用户翻了自己的日志：10 月 20 日旧版（安装包 26.1013.4894.0）还能正常创建 Worktree 对话，10 月 21 日换成新安装包后开始报错。说“是这次更新引入的”只是根据时间推断，没有人拿旧版做过对照测试。

长得像、但不是这个问题的几种情况

先把消息发出去：关掉“新建工作树”改用 Local

这是报告最多、三个平台都有人确认过的办法：

1. 回到新对话界面。按官方文档，Worktree 选项在输入框下方，切到 Local；也有用户是在新对话设置（齿轮图标）里关掉“新建工作树”。
2. 重新发送同一条消息。不需要重启 app。
3. 对话正常开始，就说明对上了这个 bug。

界面语言和版本不同，按钮名称可能不一样。中文界面里能确认的只有“启动聊天时出错”和“新建工作树”这两处叫法，下文的 Local、Worktree、Hand off 都按英文原名写。

代价要先想清楚：Local 就是你自己的检出目录，Codex 会直接改里面的文件，同一个项目也没法再并行跑几个互不干扰的对话。开始前先把手上没提交的改动 commit 或 stash，事后用 git diff 就能看清 Codex 动了什么。想收紧它在本地目录里的写入和命令权限，可以参考 Codex 沙箱与 config.toml：权限、批准和网络怎么配。

还要工作树隔离：六条路线按平台和实测情况选

修复版出来之前，想让 Codex 继续在独立的工作树里干活，有六条路可走，验证程度差别很大。先按想要的结果挑：要一个本身就跑在工作树里的对话，macOS 上用 Hand off 或让 Codex 新开工作树对话；Windows 上有实测的是让 Codex 挂载受管工作树，或者自己用 Git 建；离不开“在输入框里直接以 Worktree 启动”，只有自定义 prompt 这一个临时办法。

Local 发第一条，再用 Hand off 移到 Worktree

一位 macOS 用户验证过这条路：先在 Local 完成一轮对话，再用对话标题栏里的 Hand off 移到 Worktree，创建工作树、转移改动、切换对话三步都成功，之前的对话记录也保留了。直接以 Worktree 启动会失败，Hand off 创建工作树却没问题，说明坏掉的只是“新对话直接以 Worktree 启动”这一步。

做法：

1. 新对话选 Local，第一条消息先只让它读代码、说明计划，比如“先阅读项目结构，说明你打算怎么改，不要修改文件”。这样移交之前本地目录里不会多出改动。
2. 等这一轮结束，在对话标题栏点 Hand off，选择移到 Worktree。
3. 移过去之后，让 Codex 运行 git rev-parse --show-toplevel，确认它现在的工作目录是新建的工作树，而不是你的本地检出目录。

两点要注意。官方文档说 Hand off 会把对话连同代码一起移动，本地检出里如果有没提交的改动，也可能被带过去，先 commit 或 stash 更稳妥。被 .gitignore 忽略的文件（比如 .env）不会跟着走，除非在仓库根目录用 .worktreeinclude 列出来，让 Codex 复制到受管工作树里。

在能用的对话里，让 Codex 新开一个工作树对话

这条得到的是一个本身就运行在工作树里的新对话，不用先在本地目录里跑一轮。在任何一个能正常用的对话里（比如 Local 对话），用自然语言明确提出：在这个项目里新建一个对话，让它在工作树里运行。说法不必一字不差，例如：

在这个项目里新建一个对话，让它在一个新的工作树里运行。

一位 macOS 用户对放在远程 Linux 主机上的项目做了端到端验证：新的受管工作树建好了，新对话完成了第一轮回复；在新对话里运行 pwd、git rev-parse --show-toplevel、git status --short，确认目录就是分配给它的工作树，HEAD 处于分离状态，检出是干净的。另一位 macOS 用户在本地项目上也做了端到端验证：新对话跑在独立的工作树里，HEAD 分离、检出干净，能正常回复。按报告者的分析，这样建出来的对话不带输入框的编辑器历史，出错的那个字段根本不会出现。

需要注意：远程项目要先确认主机在线；Codex 在新对话里跑检查命令时可能需要你批准；Windows、Linux 客户端上还没有人报告过这条路。

在 Local 对话里让 Codex 创建并挂载受管工作树

这条在 macOS 和 Windows 上都有人实测成功。在一个正常工作的 Local 对话里，对 Codex 说：

Create and attach a managed worktree for this task, then do all work in that checkout.

这是报告里用的原句。Codex 会调用内置的工作树工具，建好之后把工作树挂到当前对话上，并返回它的路径。测试者确认新工作树的 HEAD 与所选分支一致，git status 干净，原来的检出目录没有被改动。

坑在于：对话本身还停在原来的检出目录里。之后每次让它改代码、跑命令，都要明确说“在 <返回的工作树路径> 里做”，否则它可能又回到你的本地目录去改。新工作树里的依赖和服务也没有准备好，需要的话让它先在那个路径里装依赖。

保持 Worktree 模式：用自定义 prompt 发第一条消息

如果一定要像原来那样在输入框里直接以 Worktree 启动，一位用户报告了一个不用关掉 Worktree 的办法（客户端是 macOS，项目在远程 Mac mini 上）：

1. 在你操作的这台电脑上新建文件 ~/.codex/prompts/worktree-start.md，内容写：

   text

   Work in the isolated worktree created for this chat. Follow the request below.

2. 重新加载 app 窗口，让它读到这个自定义命令。

3. 保持 Worktree 模式，在输入框里发送 /prompts:worktree-start 加上你的请求，例如 /prompts:worktree-start Reply OK; do not change any files.

这位用户确认 Worktree 对话能正常启动，之后的任务也可以照样加这个前缀发。报告者从安装包代码里找到的原因是：自定义 prompt 展开后，提交的文字和编辑器里的不一样了，app 就不再把编辑器文档放进开场历史，出错的字段也就不会被打包。

这只能当临时办法：目前只有这一份确认；自定义 prompt（custom prompts）已在 2026 年 1 月 22 日的 changelog 里被官方标为废弃，建议改用 skills。它在 26.1016 上还能用，但随时可能被移除。

自己用 git worktree add 建，再当作项目用 Local 打开

完全不经过 app 的工作树功能，自己用 Git 建一个：

# 在仓库根目录执行：在上一级目录建一个新工作树，并新建分支
git worktree add ../myapp-fix -b fix/my-task

# 项目依赖被 .gitignore 忽略的本地文件时，自己复制过去
cp .env ../myapp-fix/

然后在 app 里把 ../myapp-fix 这个文件夹添加为项目，用 Local 开对话。手动建工作树这一步，在受影响的机器上有人验证过，包括 SSH 连接的 Linux 主机；建好之后它就是一个普通文件夹，用 Local 打开走的是正常的路径。

几个限制：.worktreeinclude 只对 app 自己管理的工作树生效，命令行建的工作树要自己复制 .env 之类的文件；按 Git 的规则，同一个分支同一时间只能在一个工作树里检出，fix/my-task 在这里检出后，本地检出目录就不能再切到它。用完清理：

git worktree remove ../myapp-fix
git branch -d fix/my-task   # 分支已经合并或不再需要时

永久工作树：官方功能，但这个 bug 下没人试过

官方文档里，永久工作树从侧边栏项目的三点菜单创建，会作为一个独立项目出现，不会被自动删除，可以在里面开多个对话。截至 2026 年 10 月 22 日，issue 里没有人报告过它在这一版能不能绕开问题。如果想试，进去之后用 Local 模式开对话：出错的是“以 Worktree 模式启动新对话”这一步，在永久工作树里用 Local 理论上不走这条路，但这只是推断。试不通就换上面几条。

重启、重装、换分支都没用：Cannot serialize value 卡在哪一步

这里的“序列化”，指 app 在创建工作树之前，要把这次请求（包括输入框内容的结构化副本）打包，从界面传给负责建工作树的后台进程。打包失败，请求根本没发出去，工作树也没开始创建。用户贴出的日志里能看到 [Composer] submit failed、errorName=TypeError、mode=worktree，调用栈停在 managedWorktrees.pending.create(...) 的打包阶段；同一台机器上 git worktree list 一切正常，仓库本身没有问题。

更具体的原因来自社区：一位 Windows 用户和一位 macOS 用户分别挂上调试器，抓到被拒绝的值是 openingPromptForHistory.document.attrs。这是输入框编辑器生成的一个没有原型的对象，而打包器只接受普通对象；它想把这个值写进报错信息时又转不成字符串，所以界面上只剩一句 (couldn't stringify value)，看不出是哪个字段。这是社区的诊断，OpenAI 没有确认。Local 模式不需要先建工作树，不发这个请求，所以同样的消息能正常发出去。

明白了这一点，就知道下面这些为什么都没用。issue 里都有人试过：

• 重启 app、Cmd+Q 完全退出再打开，甚至重启电脑
• 退出登录再登录
• 重装 macOS app（有人验证过 app 签名完好，不是安装损坏）
• 给 app 开“完全磁盘访问权限”
• 重新选择起始分支、修复项目配置
• 改写消息内容、去掉附件

那位 macOS 用户在内存里临时打了个补丁，先把这份数据复制成普通对象再传，Worktree 对话就能启动了；重启 app 后补丁随之失效。这证实了原因，但不建议照做：app 是签过名的正式安装包，改它不受支持，下次更新也会覆盖。

降级同样不能算解决办法。有用户打算降回 26.1013.40934，但截至 2026 年 10 月 22 日还没做、也没验证；公开渠道里也找不到官方的旧版下载或回滚说明。

Cannot serialize value 修好了吗：截至 2026 年 10 月 22 日仍未修复

截至 2026 年 10 月 22 日：

• #55744 仍是开放状态，标签为 bug、app、session，帖子里没有 OpenAI 成员回复；
• 重复报告 #55823（Linux）和 #55827（Windows）也都开放；
• 官方 changelog 里最新的 Codex app 条目是 10 月 8 日的 26.1007，没有 26.1016，也没有相关修复说明。

修复时间未知。判断修复是否到了：

1. app 更新后，看 About（关于）信息里的版本号是否已经不是 26.1016.51333。
2. 版本号变了不等于修好了。开一个 Worktree 对话，发一句简单消息试一下，能正常启动再回到原来的工作流。
3. 留意 #55744 是否关闭、changelog 是否出现新的 Codex app 条目。

想让问题被看到，比在 issue 里回复“+1”更有用的是：在 app 里用 Feedback 或输入 /feedback 提交反馈，拿到反馈 ID，再把 ID、app 版本号、系统版本、对话模式（Worktree 还是 Local）一起贴到 #55744。贴日志前删掉本机路径、项目内容和任何密钥。

Cannot serialize value 常见疑问：旧对话、手机端、CLI 和插件

已经开着的 Worktree 对话还能继续用吗？

报告里失败的都是新对话的第一条消息。已经存在的 Worktree 对话能不能继续发，原帖作者写明还没确认。可以参考的是：用 Hand off 移进 Worktree 的对话在 macOS 上能正常工作，说明工作树本身没坏，坏的是新对话直接以 Worktree 启动那一步。

用手机上的 ChatGPT 开 Worktree 对话能绕开吗？

一位 macOS 用户报告，用 ChatGPT iOS 对同一台已连接的 Mac 发起 Worktree 对话是成功的。手机只负责发起和操控，仓库和工作树仍在电脑上。目前只有这一份报告，可以当临时办法试试。

codex-cli 也会报 Cannot serialize value 吗？

一位用户报告 codex-cli 仍然能用。CLI 没有桌面版的输入框，不经过出错的那一步打包，这一点是推断。

VS Code 里的 Codex 插件会受影响吗？

没有相关报告，目前未知。在插件里看到报错时，先对照上面的表格，看是不是另一个错误。