Codex /compact completes then thread enters systemError in HAPI

[qwertlooker]

What version of HAPI is running?

0.20.2

What platform is your computer?

Linux x86_64 / WSL2

OS: Linux x86_64 / WSL2
Codex CLI: 0.142.4

What issue are you seeing?

In a HAPI + Codex session, /compact appears to complete, but the conversation becomes unusable immediately afterwards: the next user message fails with Task failed: Codex thread entered systemError; retrying same conversation.

Important detail: new Codex sessions and normal messages work. The failure is specifically tied to the Codex compact control path. If I do not compact, other sessions continue normally.

Observed UI flow:

/compact
Compaction started
Compaction completed

<next user message>
Task failed: Codex thread entered systemError; retrying same conversation (1/3)

Local evidence from Codex rollout/logs shows the compact RPC and completion happened before the thread failure:

app-server request: thread/compact/start
...
type=compacted
payload.type=context_compacted

I also saw log patterns around the failed continuation such as:

incremental request failed, items didn't match

This looks like the HAPI Codex remote /compact path successfully calls thread/compact/start, but after the compaction boundary the next turn resumes/sends against a stale or invalid Codex thread state. Once Codex reports thread-level systemError, HAPI appears to treat the Codex thread as invalid and the current HAPI session loses the usable Codex context.

What steps can reproduce the bug?

1. Start a Codex session from HAPI.
2. Use the session normally for a while.
3. Send /compact from the HAPI web UI.
4. Wait until HAPI shows Compaction completed.
5. Send any follow-up user message.
6. HAPI reports Task failed: Codex thread entered systemError; retrying same conversation, and the session cannot continue reliably.

What is the expected behavior?

After /compact completes, HAPI should refresh/resume the compacted Codex app-server thread state and the next message should continue in the same conversation with the compacted context.

If Codex returns a transient compact/system error, HAPI should either:

• preserve enough state to retry/resume the same Codex thread when possible; or
• surface an explicit recovery action instead of silently starting/invalidating a fresh thread and losing context.

Additional information

Host-specific identifiers and local paths are intentionally omitted/redacted.

Related HAPI issues/code paths:

• Codex task failure can lose previous thread context on retry #565 documents that after Codex thread entered systemError, HAPI can lose the previous Codex thread context on retry.
• 每次 Task failed Codex thread entered systemError 上下文都会丢失 #577 reports the same user-visible Task failed Codex thread entered systemError context-loss behavior.
• Add Codex clear and compact slash commands #541 added the Codex /compact slash handling via app-server thread/compact/start, which seems to be the path involved here.

Related upstream Codex compaction reports:

• Codex Desktop remote compaction repeatedly fails on long sessions openai/codex#24544 reports that normal Codex requests can work while remote compaction fails independently; OpenAI later commented that remote compaction errors were addressed by moving compaction to a more local/normal-turn path.
• Add an option to disable remote compaction and use local fallback in the CLI openai/codex#24418 requested a way to disable remote compaction / use local fallback because remote compact endpoint failures can block long-running CLI sessions even when normal requests work.

This may be a compatibility issue between HAPI's /compact handling and newer Codex compaction behavior in codex-cli 0.142.4.

[github-actions]

Thanks for the detailed report. I verified the current HAPI Codex path and your description matches the implemented control flow: manual /compact is handled as a Codex special command, HAPI calls Codex app-server thread/compact/start, then reports Compaction completed when that RPC returns.

I did not find a post-compact thread refresh/resume step in the manual /compact path before the next user turn. The code does have same-thread retry handling for Codex thread entered systemError, but that is triggered when a later task failure is received, not as part of successful manual compact completion.

Relevant code:

• cli/src/codex/codexSpecialCommands.ts:11 - exact /compact is parsed as a Codex special command; /compact ... is rejected.
• cli/src/codex/codexRemoteLauncher.ts:2665 - /compact reuses currentThreadId or resumes the stored session thread before compacting.
• cli/src/codex/codexRemoteLauncher.ts:2915 - manual /compact interrupts/reset current turn state, calls compact, and sends Compaction completed after the RPC returns.
• cli/src/codex/codexAppServerClient.ts:210 - compactThread() sends thread/compact/start to the Codex app-server.
• cli/src/codex/utils/appServerEventConverter.ts:593 - Codex thread/compacted notifications are converted to HAPI compact events.
• cli/src/codex/utils/appServerEventConverter.ts:645 - Codex thread/status/changed with systemError becomes a HAPI task_failed event.
• cli/src/codex/codexRemoteLauncher.ts:83 - codex thread entered systemerror is classified as retryable on the same thread.
• cli/src/codex/codexRemoteLauncher.ts:2055 - same-thread retry is attempted only when there is an active message and current thread id.

Need more info:

• After the first follow-up message post-compact, do you see all three same-thread retry attempts, or only the first retrying same conversation (1/3) line?
• Can you share the redacted Codex app-server notifications/events around the first post-compact failure, especially any thread/status/changed, turn/start, or thread/resumed entries?
• Does the same sequence reproduce if you send /compact from the local Codex CLI directly, outside HAPI, with Codex CLI 0.142.4?

---

HAPI Bot

[qwertlooker]

Thanks for the detailed report. I verified the current HAPI Codex path and your description matches the implemented control flow: manual /compact is handled as a Codex special command, HAPI calls Codex app-server thread/compact/start, then reports Compaction completed when that RPC returns.

I did not find a post-compact thread refresh/resume step in the manual /compact path before the next user turn. The code does have same-thread retry handling for Codex thread entered systemError, but that is triggered when a later task failure is received, not as part of successful manual compact completion.

Relevant code:

• cli/src/codex/codexSpecialCommands.ts:11 - exact /compact is parsed as a Codex special command; /compact ... is rejected.
• cli/src/codex/codexRemoteLauncher.ts:2665 - /compact reuses currentThreadId or resumes the stored session thread before compacting.
• cli/src/codex/codexRemoteLauncher.ts:2915 - manual /compact interrupts/reset current turn state, calls compact, and sends Compaction completed after the RPC returns.
• cli/src/codex/codexAppServerClient.ts:210 - compactThread() sends thread/compact/start to the Codex app-server.
• cli/src/codex/utils/appServerEventConverter.ts:593 - Codex thread/compacted notifications are converted to HAPI compact events.
• cli/src/codex/utils/appServerEventConverter.ts:645 - Codex thread/status/changed with systemError becomes a HAPI task_failed event.
• cli/src/codex/codexRemoteLauncher.ts:83 - codex thread entered systemerror is classified as retryable on the same thread.
• cli/src/codex/codexRemoteLauncher.ts:2055 - same-thread retry is attempted only when there is an active message and current thread id.

Need more info:

• After the first follow-up message post-compact, do you see all three same-thread retry attempts, or only the first retrying same conversation (1/3) line?
• Can you share the redacted Codex app-server notifications/events around the first post-compact failure, especially any thread/status/changed, turn/start, or thread/resumed entries?
• Does the same sequence reproduce if you send /compact from the local Codex CLI directly, outside HAPI, with Codex CLI 0.142.4?

HAPI Bot

only the first retrying same conversation (1/3) line

Does the same sequence reproduce if you send /compact from the local Codex CLI directly, outside HAPI, with Codex CLI 0.142.4?
-- NO