[Bug] Codex heterogeneous agent loses session continuity every turn (sessionId missing from stream_start, regression of #16855)

快速结论：这个报错通常出现在 LobeChat 使用 Codex 异构代理（heterogeneous agent）时，同一话题的每一轮对话都新建 Codex 会话、丢失上下文。优先排查第一轮 Codex exec 是否非零退出，以及对应版本的 sessionId 持久化路径是否修复。

适用环境：Issue 报告环境为 LobeChat Desktop App (Electron) v2.2.18（stable，main 分支同样存在）；官方复测使用 LobeHub 开发分支 + Codex CLI 0.159.2。报告者未说明操作系统、Python、CUDA 或显卡信息。

最快修复方案：暂无确认的一步修复方案。官方确认可复现的窄场景是“首轮 Codex exec 非零退出时 native session ID 未持久化”，该问题已在 #20245 修复，等待合并与发布；升级到包含 #20245 的版本后可优先尝试。

注意事项：报告者提出的“stream_start 缺少 sessionId 导致每轮新会话”在官方正常完成的轮次中未能复现，因此恢复该字段并非已确认的通用修复。官方尚未在 v2.2.18 上重复验证；如果你的问题发生在“成功完成”的轮次之后，仍需提供 Codex 版本、传输模式和脱敏日志进一步排查。

问题场景

用户在 LobeChat（Desktop App / Electron）中使用 Codex 异构代理，在同一个 topic 里连续进行多轮对话时，Codex 无法记住上一轮内容。表现为每一轮都会生成新的 UUIDv7 thread_id，即每轮都是一次全新的 Codex 会话。同一环境下 Claude Code 的 session id 在各轮之间保持稳定，因此报告者判断这是适配器层面的回归。

报错原文

[Bug] Codex heterogeneous agent loses session continuity every turn (sessionId missing from stream_start, regression of #16855)

原因分析

报告者分析：PR #16855 曾为 Codex 适配器的 stream_start 补上 sessionId 字段，但 PR #16873 在解决 adapters/codex.ts 冲突时删除了这 7 行，回归一直存在于 main 分支（约 line 1229）；codexAppServer.ts 的 streamStartData()（约 line 802）也存在同样缺失。消费端逻辑（renderer 的 heterogeneousAgentExecutor.ts 与 server 的 HeterogeneousPersistenceHandler.ts 均在 stream_start 持久化）仍然完整，因此问题只出在适配器字段未写入。此时 topic.metadata.heteroSessionId 保持为 {}，下一轮 startSession 拿不到 resumeSessionId，Codex driver 走普通 exec 而非 exec resume，于是每轮创建新线程。

官方复测结论不同：在正常完成的轮次中无法复现会话丢失，Codex exec 与 Codex App Server 都保留了同一 native thread，并能在不重发的情况下回忆上一轮信息；正常完成路径也会获取并持久化 session ID，因此仅缺少 stream_start.sessionId 并不必然导致每轮新会话。官方确认可复现的是一个更窄的场景：首轮 Codex exec 非零退出时，其 native session ID 未被持久化，导致下一轮新建会话，该问题已由 #20245 修复。可优先按“首轮非零退出”方向排查，但该结论尚未在 v2.2.18 上复测。

环境排查

确认 LobeChat / LobeHub 版本：报告版本为 v2.2.18（stable），main 分支同样存在；官方测试使用 LobeHub 开发分支。
确认 Codex 版本：官方测试使用 Codex CLI 0.159.2；报告者未在正文中给出自己的 Codex 版本。
确认传输模式（Codex exec 还是 Codex App Server）。
确认第一轮 Codex exec 是否以非零状态退出。
检查 topic.metadata.heteroSessionId 是否被持久化（报告者使用 SELECT metadata->>'heteroSessionId' FROM topics; 验证，结果为 {}，而同一数据库中 Claude Code 话题已填充）。
操作系统、Python、CUDA、显卡信息在 Issue 与评论中均未提供，无需臆测。

解决步骤

先判断问题触发条件：确认是否只在“首轮 Codex exec 非零退出”后每一轮都新建会话。如果是，这属于官方已确认的窄场景，优先升级到包含 #20245 的版本（该修复通过既有 early-persistence 路径保存 session ID，官方验证首轮报错后随后两轮恢复为同一线程并保留原始上下文）。
如果问题出现在“成功完成”的轮次之后，则不属于上述已修复场景。按官方要求整理并反馈：Codex 版本、传输模式（exec 或 App Server）、脱敏后的 completion/exit 与 resume 日志。
报告中提到的 adapters/codex.ts 恢复 sessionId 字段的做法，是报告者自行验证的方案（在 v2.2.18 asar-patched 二进制上本地验证），并非官方确认的通用修复，不建议在未确认触发条件前直接采用。
若你使用自托管服务，可通过上述 SQL 检查 heteroSessionId 是否被写入，用于区分“会话 ID 未持久化”与“持久化了但没有 resume”。

验证方法

在同一个 topic 中连续进行多轮 Codex 对话，观察后续轮次是否复用同一 thread_id、是否能回忆起上一轮内容；同时查询 topic.metadata.heteroSessionId，确认其不再为空 {}。官方验证方式是：在首轮报错后继续两轮对话，确认两轮恢复到同一线程并保留原始上下文。注意官方明确说明尚未在 v2.2.18 上重复这些检查。