希望 Codex 会话支持消息 pending / 排队发送

[webwww123]

背景

在实际使用 Codex 的过程中，上一条消息还在执行时，用户往往已经想好了下一条指令。

目前如果必须等当前轮次完全结束后才能继续发送，操作节奏会被打断，尤其是在长会话、持续修改代码、观察执行结果再补充指令的场景里，这种感受会比较明显。

诉求

希望 hapi 在 Codex 会话中支持消息的 pending / 排队发送 能力。

也就是说：当当前消息还在处理中时，允许用户继续输入下一条消息；新消息先进入 pending / queued 状态，等当前轮次完成后，再按顺序自动发送。

为什么这个能力很重要

因为 Codex 本身就支持类似的交互体验。如果 hapi 也能补上这一层，会让 Codex 在 Web 端的使用体验更加自然，也更符合用户预期。

期望的体验

可以考虑支持：

• 当前消息执行中时，仍允许继续输入下一条消息
• 新消息显示为 pending / queued 状态
• 当前轮次结束后，队列中的消息自动按顺序发送
• 在界面上清晰区分：已发送、处理中、排队中，避免用户混淆
• 如果用户想取消排队中的某条消息，也可以手动撤销

适用场景

• 长时间运行的编码任务
• 看着输出过程临时补充要求
• 需要连续给出多步指令的会话
• 网络或模型响应较慢时，减少等待造成的操作中断

最后

顺便也想说一句，最近能感觉到项目更新挺勤，很多细节都在持续完善。维护这类工具很不容易，真的辛苦各位开发者了。

hapi 已经很好用了，如果这个交互细节也能补上，Codex 场景下的整体体验应该会再上一个台阶。感谢你们持续投入和维护！

[github-actions]

查了当前实现，这个需求目前还没有在 Web 侧打通。

已验证到两层行为：

1. Web 端当前会在会话 running 时阻止继续发送。HappyComposer 的 canSend 需要 !threadIsRunning，而 thread.isRunning 来自 session.thinking，所以 Codex 正在处理时，下一条消息不能进入“排队待发”状态。
2. Codex CLI 侧本身已经有顺序消费的消息队列。来自 hub 的用户消息会进入 session.onUserMessage(...)，随后被 messageQueue.push(...) 放进 MessageQueue2，remote launcher 再用 waitForMessagesAndGetAsString(...) 依次取出处理。也就是说，底层有 queue，但当前 Web / Hub 路径里我没有找到面向用户的 queued 状态、单条取消、或队列管理接口。

Relevant code:

• web/src/components/AssistantChat/HappyComposer.tsx:96 - 读取 thread.isRunning
• web/src/components/AssistantChat/HappyComposer.tsx:116 - canSend 明确要求 !threadIsRunning
• web/src/lib/assistant-runtime.ts:185 - isRunning 绑定到 session.thinking
• web/src/hooks/mutations/useSendMessage.ts:104 - 本地发送 mutation 未完成时直接返回 pending blocked
• web/src/types/api.ts:38 - 当前消息状态只有 sending | sent | failed
• hub/src/web/routes/messages.ts:40 - Web 侧发送入口只有 POST /sessions/:id/messages
• hub/src/sync/messageService.ts:89 - hub 持久化后把消息转发到 CLI 会话
• cli/src/api/apiSession.ts:170 - CLI 收到 new-message 后走 handleIncomingMessage(...)
• cli/src/codex/runCodex.ts:88 - Codex 会把用户消息推入 messageQueue
• cli/src/utils/MessageQueue2.ts:3 - 队列项当前只有 message/mode/modeHash/isolate，没有可单独取消的队列项 ID
• cli/src/utils/MessageQueue2.ts:224 - 队列按批次等待并取出消息
• cli/src/codex/utils/emitReadyIfIdle.ts:13 - 只有 pending 为空且 queueSize() === 0 才发 ready

Need more info:

• 这个能力是否希望先只支持 Codex，还是后续希望所有远程 agent 统一语义？

---

HAPI Bot

[webwww123]

再补充一点不成熟的小想法，仅供参考哈。这个不是我认真读完整套架构后下的结论，只是我随手让 AI 帮忙看了一下 hapi 源码，如果理解有偏差，还请轻喷，不要骂我 😄

我自己的感觉是，这个功能对 hapi 来说，可能不一定需要从底层重新发明一套消息队列，更像是 Web 这一层现在把能力拦住了。

我看到的几个点大概是：

• web/src/hooks/mutations/useSendMessage.ts 里，当前如果 mutation.isPending 或还在 resolve session，就会直接 onBlocked('pending') 返回
• web/src/components/SessionChat.tsx 里，HappyComposer 现在也是 disabled={props.isSending}，所以前端输入/发送也一起被禁掉了
• 但 hub/src/sync/messageService.ts 这边看起来更像是正常收消息、落库、广播，不像是主要瓶颈
• cli/src/codex/runCodex.ts 这边，用户消息本身就是往 MessageQueue2 里 push 的；cli/src/utils/MessageQueue2.ts 也已经有现成的队列处理逻辑

所以如果这个判断没错的话，我猜第一版也许可以先走一个比较小的方案：

1. 先只改 Web 端，不急着大动 hub / cli
2. 不要在 useSendMessage 里直接把 pending send 拦掉
3. 前端本地维护一个 queued messages 列表
4. 当前 in-flight 的消息完成后，再自动 flush 下一条
5. UI 上把这些消息标成 queued / pending，用户能看见顺序
6. 如果要更完整一点，再补一个“取消排队中的消息”

如果这样能成立的话，感觉第一版的改动范围会相对小一些，也更容易验证。

当然，这只是我自己随便猜的实现方向，未必对。如果我理解错了，欢迎直接忽略；也感谢你们一直在维护和迭代这个项目，真的辛苦了。