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

> Codex 26.1016 在 Worktree 模式发首条消息报 Cannot serialize value，是该版已知 bug，重启重装无效；关掉新建工作树改用 Local 即可发出，要隔离另有绕法。

- Source: https://www.aifreeapi.com/zh/posts/codex-cannot-serialize-value
- Language: zh
- Published: 2026-10-22
- Updated: 2026-10-22
- Publisher: AI Free API (https://www.aifreeapi.com)

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

```text
启动聊天时出错
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](https://github.com/openai/codex/issues/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 里的用户报告](https://github.com/openai/codex/issues/55744#issuecomment-6309500081)，macOS、Windows、Linux 都能复现；项目放在 SSH 远程主机上也一样，有人是 Windows 连 Linux 主机，有人是 macOS 连远程 Mac。多数人是 10 月 21 日更新后开始遇到。一位 Windows 用户翻了[自己的日志](https://github.com/openai/codex/issues/55744#issuecomment-6308796330)：10 月 20 日旧版（安装包 26.1013.4894.0）还能正常创建 Worktree 对话，10 月 21 日换成新安装包后开始报错。说“是这次更新引入的”只是根据时间推断，没有人拿旧版做过对照测试。

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

| 你看到的情况 | 判断 | 下一步 |
| --- | --- | --- |
| Local 模式也报 `Cannot serialize value` | 不符合这个 bug 的特征，目前的报告里 Local 都正常 | 先确认版本号，再按完整报错单独排查 |
| VS Code 插件里报 `Error creating chat` | 这是插件 9 月出现过的另一个报错；这次的 bug 会不会影响插件，没有任何报告 | 按插件里的完整报错排查 |
| 横幅是 `Error submitting message`，第二行是别的内容 | 另一个错误，原因看第二行 | 按第二行原文排查 |
| app 整个打不开，提示 app-server 无法启动 | 启动层的问题，跟发消息无关 | [Codex app-server 启动失败：按报错原文对症修，先别删 .codex](/zh/posts/codex-app-server-failed-to-start) |
| 还没进入对话就卡住、提示超时 | 启动阶段加载失败 | [Codex 启动超时：先查云端配置包，再处理连接、MCP 和进程](/zh/posts/codex-timeout) |
| 对话能开，但反复显示 Reconnecting | 连接问题 | [Codex 一直 Reconnecting：先保住任务，再定位是哪一层断了](/zh/posts/codex-stuck-reconnecting-fix) |

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

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

1. 回到新对话界面。按[官方文档](https://learn.chatgpt.com/docs/environments/git-worktrees)，Worktree 选项在输入框下方，切到 Local；也有用户是在新对话设置（齿轮图标）里[关掉“新建工作树”](https://github.com/openai/codex/issues/55744#issuecomment-6309973471)。
2. 重新发送同一条消息。不需要重启 app。
3. 对话正常开始，就说明对上了这个 bug。

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

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

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

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

| 路线 | 能否保持隔离 | 实测情况（截至 2026 年 10 月 22 日） | 适合谁 |
| --- | --- | --- | --- |
| Local 发第一条，再用 Hand off 移到 Worktree | 能 | macOS 上 1 位用户完整实测成功；Windows、Linux 没有报告 | macOS 用户，想要 app 原生的 Worktree 对话 |
| 在能用的对话里让 Codex 新开一个工作树对话 | 能，新对话本身就在工作树里 | macOS 客户端上 2 份端到端实测（1 份是远程 Linux 项目，1 份是本地项目）；Windows、Linux 客户端没有报告 | 想要干净的新对话、又不想先在本地目录里跑一轮的人 |
| 在 Local 对话里让 Codex 创建并挂载受管工作树 | 能，但后续要明确用返回的路径 | macOS、Windows 各有实测成功 | Windows 用户，或不想动当前对话的人 |
| 保持 Worktree 模式，用自定义 prompt 发第一条 | 能，仍是直接以 Worktree 启动 | 1 位用户确认（macOS 客户端，项目在远程 Mac mini 上）；这个功能官方已标为废弃 | 离不开原来的启动方式、能接受临时办法的人 |
| 自己 `git worktree add`，再把文件夹当项目用 Local 打开 | 能 | 受影响的机器上手动建工作树成功，包括 SSH 远程主机 | 熟悉 Git、项目在远程主机上、想完全自己掌控 |
| 从侧边栏建永久工作树 | 能 | **未验证**，这个 bug 下没有人试过 | 本来就打算建长期环境的人 |

![按是否需要隔离选路线：不需要就关掉新建工作树用 Local；需要则在 Hand off、让 Codex 新开工作树对话、让 Codex 挂载工作树、自定义 prompt、git worktree add、永久工作树六条路线中选，并标出各自截至 10 月 22 日的实测程度](https://www.aifreeapi.com/posts/zh/codex-cannot-serialize-value/img/worktree-isolation-routes.webp)

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

一位 macOS 用户[验证过这条路](https://github.com/openai/codex/issues/55744#issuecomment-6312311473)：先在 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 对话），用自然语言明确提出：在这个项目里新建一个对话，让它在工作树里运行。说法不必一字不差，例如：

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

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

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

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

这条在 [macOS](https://github.com/openai/codex/issues/55744#issuecomment-6321353776) 和 [Windows](https://github.com/openai/codex/issues/55744#issuecomment-6308796330) 上都有人实测成功。在一个正常工作的 Local 对话里，对 Codex 说：

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

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

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

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

如果一定要像原来那样在输入框里直接以 Worktree 启动，[一位用户报告](https://github.com/openai/codex/issues/55744#issuecomment-6314030212)了一个不用关掉 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](https://learn.chatgpt.com/docs/changelog) 里被官方标为废弃，建议改用 skills。它在 26.1016 上还能用，但随时可能被移除。

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

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

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

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

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

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

```bash
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 用户](https://github.com/openai/codex/issues/55744#issuecomment-6328626611)和[一位 macOS 用户](https://github.com/openai/codex/issues/55744#issuecomment-6313659834)分别挂上调试器，抓到被拒绝的值是 `openingPromptForHistory.document.attrs`。这是输入框编辑器生成的一个没有原型的对象，而打包器只接受普通对象；它想把这个值写进报错信息时又转不成字符串，所以界面上只剩一句 `(couldn't stringify value)`，看不出是哪个字段。这是社区的诊断，OpenAI 没有确认。Local 模式不需要先建工作树，不发这个请求，所以同样的消息能正常发出去。

![Worktree 模式下发送第一条消息后，在打包建工作树请求时因 openingPromptForHistory.document.attrs 失败，工作树没有创建；Local 不发这个请求；重启、重装、重选分支、改写消息都碰不到这一步](https://www.aifreeapi.com/posts/zh/codex-cannot-serialize-value/img/worktree-start-failure-point.webp)

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

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

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

降级同样不能算解决办法。[有用户打算降回 26.1013.40934](https://github.com/openai/codex/issues/55744#issuecomment-6312682209)，但截至 2026 年 10 月 22 日还没做、也没验证；公开渠道里也找不到官方的旧版下载或回滚说明。

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

截至 2026 年 10 月 22 日：

- [#55744](https://github.com/openai/codex/issues/55744) 仍是开放状态，标签为 bug、app、session，帖子里没有 OpenAI 成员回复；
- 重复报告 [#55823](https://github.com/openai/codex/issues/55823)（Linux）和 [#55827](https://github.com/openai/codex/issues/55827)（Windows）也都开放；
- [官方 changelog](https://learn.chatgpt.com/docs/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 用户报告](https://github.com/openai/codex/issues/55744#issuecomment-6320056397)，用 ChatGPT iOS 对同一台已连接的 Mac 发起 Worktree 对话是成功的。手机只负责发起和操控，仓库和工作树仍在电脑上。目前只有这一份报告，可以当临时办法试试。

### codex-cli 也会报 Cannot serialize value 吗？

[一位用户报告](https://github.com/openai/codex/issues/55744#issuecomment-6310150944) codex-cli 仍然能用。CLI 没有桌面版的输入框，不经过出错的那一步打包，这一点是推断。

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

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