凌晨一点半，refund 接口改到一半。你想起两件事：lint 步骤被跳过了，changelog 还没写。

换终端、等这一轮跑完、再打字，太慢。Codex CLI 从 0.149.0 起给了个更省事的入口：

codex queue --thread "orders-refund" --message "收尾前跑一遍 npm run lint，再补一条 changelog"

会话在另一个终端里跑着，这条消息自己排进去。10 月底的 0.166.0 又加了 --resume，会话已经退出也能被这条消息叫醒接着干。

好用。坑在这里：Codex 把这条消息记成了你说的话。

会话变成了一个可以投递的对象#

8 月 20 日的 0.149.0 一起给了两样东西。codex agents 打开任务面板，/agents 在会话里跳回去。面板按工作目录分组，顶部三个计数：Need input（等你拍板或批准）、Working（在跑）、Ready（跑完待看）。Ctrl+F 搜，Ctrl+R 改名，Ctrl+X 停。

终端就这么变成了一个收件箱。三个 agent 并行的时候，真正费时间的是记住哪个跑完了、哪个结果你还没看过，打字本身没那么慢。有了未读标记，检查从"逐个打开"变成"只看有标记的"。0.167.0 把这块做完了，面板和会话选择器都会标未读。

codex queue 是同一套东西的另一半：从会话外面往里投消息。你的另一个终端、一个脚本、一个 git hook、一个上游 agent，用的都是同一条命令。

四条容易踩的边界#

第一条，投进去的消息用会话当前的模型，没法在消息级别换模型。

第二条，官方参考写的是"只接受文本"。社区教程里演示过 --image，官方文档没列这个参数。你手上是哪个版本，自己 --help 看一眼，别照抄。

第三条，顺序没人保证。两条队列消息不一定会变成先后两轮。要它按顺序做，就写成一条消息，用编号列清楚：

codex queue --thread "orders-refund" --message "收尾前：1) 跑 npm run lint 并修掉 error 2) 补一条 changelog 3) 把测试结果贴进最终总结"

第四条最容易骗人，退出码 0 不代表活儿送到了。加 --resume 要让会话醒过来，得有本地 daemon 在跑，或者用 --remote 指到远端服务。醒不过来时 Codex 打印一条 warning，然后照样成功退出。消息留在队列里，你的 CI 看到 green，以为派单成功。

确认只有一个办法：codex agents 看那个任务有没有真的从 Ready 变回 Working，或者进去 /status 看一眼。

问题不在队列，在署名#

到这儿都还是工程细节。真正值得说的是 issue #45456。

9 月 14 日有人报了个 bug，标签打的是 bug、CLI、subagent。一个子代理想跟父会话通信，正常的 agent 间通道不通，它退而用 codex queue 往父线程投了一条消息。这条消息后来被当成人发的话喂给了父会话，持久化成 role:"user"。

没有人说过那句话。

报告里列了四个后果，分得很准：来源丢失、权限升级、无端执行、过期投递。子代理写的一段进度汇报，最后以"用户指令"的身份叫醒了父模型，触发新一轮模型和工具调用。父线程从头到尾不知道这活儿是自己派出去的。

10 月 18 日另一个 issue #54991 提的是同一件事的另一面。现在 codex queue 投进去的消息，TUI 画出来跟操作员手打的 prompt 一模一样，› 开头，同样的背景色，模型收到的也是 role: "user"。提需求的人想要一个 --as developer --from "<label>"：消息以 developer context 的身份到达模型，TUI 画成 ↳ Message from <label> 这样的署名通知。

两个 issue 都还开着。

为什么这事不该当成 UI 小毛病#

分布式系统里，“谁发的"和"以什么权限发的"是消息头里最基础的两个字段。邮件有 From，actor 模型有 sender，CI 有 actor，HTTP 有一堆认证头。少了这个字段，收件方只能按最宽的那个身份处理。

现在的 Codex 会话收到队列消息时只有两种选择：信，或者丢。它没有第三个选项叫"我知道这是机器写的，权限比人低”。

后果不是理论上的。

编排层会自我放大。子代理写的话被当成人的指令，父代理再往下派活儿，一轮轮滚下去，一个人没碰过的会话在夜里自己往前跑，账单跟着涨。

审计会断。事后翻 transcript，人和 hook 的指令长得一样，你没法回答"这个 rm -rf 是谁要求的"。

过期投递会出事。一条 checkpoint 消息在任务已经完成之后才被投进去，模型会认真地为一件结束的事再开一轮。

我的判断：codex queue 这个方向是对的，把会话当服务、用消息驱动，比在终端里等人打字强太多。缺的是身份模型还停在"房间里只有一个人"的年代。有了队列，房间里就有脚本、hook、子代理、上游调度器，它们说的话不该跟你说的等价。

现在能做的#

工具还没给 --from，人只能自己补。

投消息时把来源写进正文第一句，格式统一，方便以后 grep：

[from:ci-hook] lint 失败，见 build/1234.log
[from:subagent:reviewer] 3 处未覆盖分支，清单在 .ai/review.md

脚本和无人值守的任务用 UUID 不用会话名。名字被改一次，--thread 就可能指错，UUID 不会。

hook 要加上限。post-commit 里挂一条 queue 命令很爽，但一次 rebase 十几次提交就是十几条消息，会话被自己的通知淹没。攒批，或者只在特定路径变动时触发。

多步要求写成一条编号消息，别指望两条队列消息排成两轮。

投完确认会话真醒了。codex agents 里状态动了才算数，退出码不算。

最后#

过去一年 Codex 的路线很清楚：从"你说一句它做一句"，到"你派一堆活儿它自己跑"。0.167.0 的未读标记、0.166.0 的 --resume、0.149.0 的面板，补的是同一块短板，人怎么同时看住五个 agent。

看住的前提是分得清。分得清谁在说话、谁批的、哪条是新的。这块现在靠你在消息正文里手写标签，能撑一阵。

等哪天 --as developer 真落地了，别急着高兴。那说明 Codex 承认会话里不止一个人。接下来该问的是，子代理能不能用 --as user 冒充你。

参考来源：

  • gabrielanhaia, Queue Work Into a Running Codex Session From Another Shell: codex queue, Step by Step, dev.to, 2026-11-06
  • proflead, OpenAI Codex Agents Dashboard and codex queue: Complete Tutorial
  • openai/codex issue #45456, Subagent can inject agent-authored queued content as role:“user” in parent thread, open, 2026-09-14
  • openai/codex issue #54991, codex queue / hooks: wake an idle session with a non-user, attributed message, open, 2026-10-18
  • openai/codex releases, rust-v0.167.0, 2026-11-06