Codex task failure can lose previous thread context on retry

[Shujakuinkuraudo]

Summary

When a remote Codex task fails before/around model execution, e.g.

• Task failed: Codex thread entered systemError
• Task failed: Selected model is at capacity. Please try a different model.

continuing from the HAPI UI can lose the previous conversation/task context. The next user message is treated like a fresh request and the agent no longer has the earlier instruction/context.

Example observed flow:

1. User asks: 现在给我一个完整的表格，关于这些方法的数据
2. Codex task fails with capacity/systemError.
3. User retries/sends again.
4. Agent answers as if it has no previous context: 可以，但我现在还不知道“这些方法”具体指哪些。

Expected behavior

After a task fails due to a transient model/provider error, HAPI should preserve enough session/thread state so a retry or follow-up continues the same Codex thread/context, or at least offers an explicit “resume/retry with previous context” path.

Actual behavior

The retry/follow-up appears to lose the prior task context and behaves like a new empty interaction.

Relevant code/data points

I traced the current runner/session path and noticed most of the active session tracking is in runner memory only:

Area	File	Data	Persistence	Risk
runner local state	cli/src/persistence.ts	pid, httpPort, version, startedWithApiUrl, startedWithMachineId, token hash, heartbeat	~/.hapi/runner.state.json	only runner process metadata, not full session/thread state
active sessions	cli/src/runner/run.ts	pidToTrackedSession	memory only	lost on runner restart/crash
spawn awaiters	cli/src/runner/run.ts	pidToAwaiter, pidToErrorAwaiter	memory only	lost on failure/restart
session webhook	cli/src/runner/run.ts	happySessionId, metadata, PID	memory map update	not enough if not persisted
resume path	cli/src/runner/run.ts	resumeSessionId passed to agent command	request only	depends on caller preserving/providing resume id
Codex command	cli/src/commands/codex.ts	parses hapi codex resume <id>	no	ok as CLI path, but HAPI retry may not re-use it correctly
Codex session	cli/src/codex/loop.ts, cli/src/codex/session.ts	resumeSessionId ?? null as sessionId	no	session can resume only if the id is still known

The runner README also documents that runner.state.json only stores runner process state, not session mapping.

Possible fix direction

A robust fix may be one or more of:

1. Persist session/thread mapping (happySessionId, provider-specific session/thread id such as Codex resume id, PID, cwd, agent, model settings) beyond in-memory pidToTrackedSession.
2. On task failure (systemError, capacity, provider transient errors), keep the same Codex thread/session id and expose retry against that same id.
3. Make the HAPI UI/backend send resumeSessionId when retrying a failed Codex task if a prior session/thread id exists.
4. Add diagnostics/logging around failed Codex tasks to show whether a resume id was available and whether it was used.

Environment

• HAPI CLI version observed: 0.17.1
• Agent: Codex
• Start path observed in logs: hapi codex resume <resumeSessionId> --hapi-starting-mode remote --started-by runner ...
• Runner keeps process metadata in ~/.hapi/runner.state.json; active session maps are in-memory.

[github-actions]

Verified. The current Codex remote path can do what you observed: a thread-level systemError is converted into a visible task failure, then that thread id is marked invalid. The next queued/follow-up message starts a fresh Codex app-server thread instead of resuming the failed one, so prior thread context is not preserved in that path.

I also did not find a web spawn/resend path that automatically supplies the previous Codex thread id back as resumeSessionId. The lower hub/runner layers accept resumeSessionId, and hapi codex resume <id> is wired through, but the normal web spawn route passes undefined for it and message retry only reposts the same text to the same HAPI session.

Relevant code:

• cli/src/codex/utils/appServerEventConverter.ts:320 - maps Codex thread/status/changed with systemError into task_failed from thread_status.
• cli/src/codex/codexRemoteLauncher.ts:273 - detects thread-status failures.
• cli/src/codex/codexRemoteLauncher.ts:295 - records the failed thread as invalidThreadId, clears currentThreadId, and sets hasThread = false.
• cli/src/codex/codexRemoteLauncher.ts:791 - only resumes when session.sessionId exists and is not the invalid thread id; otherwise the path falls through to starting a new thread.
• cli/src/codex/codexRemoteLauncher.ts:814 - starts a new app-server thread when no valid resume thread id is available.
• cli/src/codex/codexRemoteLauncher.test.ts:306 - test currently asserts that the next queued message after thread-level systemError starts a fresh thread.
• cli/src/runner/run.ts:130 - active runner sessions are held in a process-local Map.
• cli/src/runner/run.ts:145 - spawn awaiters are also process-local maps.
• cli/src/persistence.ts:166 - runner persistence reads runner.state.json; this is runner process state, not the active session/thread map.
• cli/src/runner/run.ts:918 - runner can build codex resume <resumeSessionId> when a resume id is supplied.
• hub/src/sync/rpcGateway.ts:135 - hub RPC layer accepts resumeSessionId and forwards it to spawn-happy-session.
• hub/src/web/routes/machines.ts:54 - normal web machine spawn currently passes undefined for resumeSessionId.
• web/src/hooks/mutations/useSendMessage.ts:159 - UI retry for failed messages resends the original text; no Codex resume id is included.

This looks actionable from the codebase side. The concrete gap is preserving/choosing a valid Codex thread id for transient provider failures, or making retry/resume explicitly route through the known codexSessionId when that id is still usable.

---

HAPI Bot