摘要
当 Hive 用已有 session id 启动 agent,但 Codex 因本地启动/配置问题直接非零退出时,Hive 当前会清掉 worker 持久化的 last_session_id。
结果是下一次启动不再带 --resume,用户在 UI 上会感觉“当前会话上下文丢了”。但实际底层 Codex 的 session JSONL 通常并没有被删除,只是 Hive 不再保存并传入那个 resume id。
我本地遇到的几个触发错误包括:
Error: Missing optional dependency @openai/codex-win32-x64
Cannot open external editor: set $VISUAL or $EDITOR before starting Codex.
failed to parse hooks config ... unknown field SessionStart
这些错误都发生在 Codex 真正进入交互会话之前,并不能证明原来的 session id 是坏的。
期望行为
如果 resumed CLI 因为可恢复的本地启动/配置问题退出,Hive 应该保留持久化的 session id。
用户修好本地 Codex 安装、hooks 配置或 $VISUAL / $EDITOR 后,再次启动同一个 worker,Hive 仍应传入同一个:
同时,Hive 仍然应该在真正的 stale/bad resume 失败时清理 session id,避免持续重试一个已经无效的会话。
实际行为
Hive 会把任意 resumed run 的非零退出都当作“保存的 session id 已经坏了”:
agent-run-exit-handler.ts 在非零退出时清理。
agent-run-starter.ts 在 startAgent 立即返回 error run 时清理。
这会把“session id 坏了”和“CLI 本地环境坏了”混为一谈。
复现 Demo
用一个 fake Codex 命令模拟启动失败:
// fake-codex-startup-failure.mjs
console.error('Error: Missing optional dependency @openai/codex-win32-x64')
process.exit(1)
配置 worker launch,带 resume template:
{
"command": "node",
"args": ["C:/tmp/fake-codex-startup-failure.mjs"],
"resumeArgsTemplate": "--resume {session_id}",
"sessionIdCapture": null
}
给 worker 预置一个持久化 session id,例如:
INSERT INTO agent_sessions (agent_id, workspace_id, last_session_id, updated_at)
VALUES ('agent-1', 'ws-1', '88888888-8888-4888-8888-888888888888', unixepoch() * 1000);
启动 worker 一次。
当前行为:
- Hive 用
--resume 88888888-8888-4888-8888-888888888888 启动 fake command。
- fake command 打印 Codex 启动错误并以退出码
1 退出。
- Hive 清掉
agent_sessions.last_session_id。
- 下一次启动 worker 时不再带
--resume。
修复后行为:
- Hive 仍然用
--resume 88888888-8888-4888-8888-888888888888 启动 fake command。
- fake command 因已知本地启动/配置错误退出。
- Hive 保留
agent_sessions.last_session_id。
- 下一次启动 worker 时仍然带
--resume 88888888-8888-4888-8888-888888888888。
影响
用户在 Codex 本地安装或配置短暂损坏后,Hive 可能丢失“应该恢复哪个会话”的指针。底层会话文件仍在,但 Hive 后续不会再传入 resume id,因此 UI 上表现为上下文丢失。
摘要
当 Hive 用已有 session id 启动 agent,但 Codex 因本地启动/配置问题直接非零退出时,Hive 当前会清掉 worker 持久化的
last_session_id。结果是下一次启动不再带
--resume,用户在 UI 上会感觉“当前会话上下文丢了”。但实际底层 Codex 的 session JSONL 通常并没有被删除,只是 Hive 不再保存并传入那个 resume id。我本地遇到的几个触发错误包括:
Error: Missing optional dependency @openai/codex-win32-x64Cannot open external editor: set $VISUAL or $EDITOR before starting Codex.failed to parse hooks config ... unknown field SessionStart这些错误都发生在 Codex 真正进入交互会话之前,并不能证明原来的 session id 是坏的。
期望行为
如果 resumed CLI 因为可恢复的本地启动/配置问题退出,Hive 应该保留持久化的 session id。
用户修好本地 Codex 安装、hooks 配置或
$VISUAL/$EDITOR后,再次启动同一个 worker,Hive 仍应传入同一个:同时,Hive 仍然应该在真正的 stale/bad resume 失败时清理 session id,避免持续重试一个已经无效的会话。
实际行为
Hive 会把任意 resumed run 的非零退出都当作“保存的 session id 已经坏了”:
agent-run-exit-handler.ts在非零退出时清理。agent-run-starter.ts在startAgent立即返回 error run 时清理。这会把“session id 坏了”和“CLI 本地环境坏了”混为一谈。
复现 Demo
用一个 fake Codex 命令模拟启动失败:
配置 worker launch,带 resume template:
{ "command": "node", "args": ["C:/tmp/fake-codex-startup-failure.mjs"], "resumeArgsTemplate": "--resume {session_id}", "sessionIdCapture": null }给 worker 预置一个持久化 session id,例如:
启动 worker 一次。
当前行为:
--resume 88888888-8888-4888-8888-888888888888启动 fake command。1退出。agent_sessions.last_session_id。--resume。修复后行为:
--resume 88888888-8888-4888-8888-888888888888启动 fake command。agent_sessions.last_session_id。--resume 88888888-8888-4888-8888-888888888888。影响
用户在 Codex 本地安装或配置短暂损坏后,Hive 可能丢失“应该恢复哪个会话”的指针。底层会话文件仍在,但 Hive 后续不会再传入 resume id,因此 UI 上表现为上下文丢失。