Thread gets stuck after failed auto-compact; app-server keeps stale in-memory history until unload #31579

Summary

A Codex Desktop thread became unable to continue after a failed auto-compact. Every follow-up immediately failed before normal sampling with Failed to run pre-sampling compact. The thread only recovered after unloading the app-server's in-memory session cache and reloading the repaired persisted history.

Environment

• Codex CLI: codex-cli 0.142.5
• Codex Desktop on macOS
• Local app-server launched by Desktop
• Observed response header included x-app-version: 1.20.2-beta.1
• Follow-up verification used gpt-5.4-mini with minimal reasoning

What happened

1. A long thread with many MCP/tool/search outputs hit auto-compact.

2. The UI/context showed an error shaped like:

   No tool output found for tool search call call_...
   

3. After that, each attempt to continue the same thread created a new turn but failed before the model produced an answer:

   Failed to run pre-sampling compact
   

4. Logs showed the pre-turn compact request going to /responses and returning 400 Bad Request. One failed attempt logged approximately:

   pre_compression_bytes=1084457
   post_compression_bytes=269771
   status=400 Bad Request
   

5. I repaired the persisted rollout JSONL by backing it up, removing failed/incomplete tail turns, and replacing large persisted function_call_output / event payload bodies with short placeholders while preserving the original call_id entries. The JSONL was valid afterward and the on-disk file dropped from roughly 840 KB to roughly 316 KB.

6. Despite the repaired persisted history, follow-ups still sent the old ~1.08 MB compact payload. This indicated the local app-server session loop was still using stale in-memory history for the loaded thread.

7. Archiving and immediately unarchiving the thread changed the thread status from systemError to notLoaded, apparently unloading the in-memory session. After that, sending the same one-line recovery prompt succeeded. The request went through normal sampling rather than pre-sampling compact and completed with:

   status=200 OK
   pre_compression_bytes=263616
   assistant final answer: OK
   thread status: idle
   

Expected behavior

A failed auto-compact should not leave a thread permanently unable to continue. At minimum, one of these should happen:

• the compacted history should be validated before it becomes the model-visible state;
• missing tool-output references should fall back to persisted history or a safe lossy representation;
• the app-server should provide a visible reload/unload repair path for a poisoned loaded thread;
• if persisted rollout history is changed or repaired, the loaded session cache should not keep using a stale broken copy indefinitely.

Actual behavior

The thread stayed in systemError, and every follow-up retried the same stale pre-sampling compact path. Repairing the persisted JSONL was not enough until the app-server was forced to unload/reload the thread by archive/unarchive.

Workaround used

• Back up the rollout JSONL.
• Remove incomplete failed tail turns.
• Preserve tool-call pairing, but shrink large function_call_output / event payload bodies to placeholders.
• Archive and unarchive the thread to unload the stale app-server session cache.
• Send a small follow-up to verify the thread returns to idle.

Why this seems worth fixing

The visible error (No tool output found for tool search call ...) looks like a corrupt compacted history/tool-call pairing issue, but the recovery was blocked by an app-server caching behavior. Users can get stuck repeatedly hitting the same compact failure even after the persisted history is no longer oversized or malformed.