Codex App thread cannot continue: remote compact task fails with unknown variant `auto`

I've been getting this immediately after the last VSCode Codex extension update. (v26.519.32039) It's killing me because it eats up my credits and then fails to complete any actual work.

I got this on my first prompt just after getting on the pro plan.

Error running remote compact task: stream disconnected before completion: unknown variant auto, expected high or original at line 1 column 63665

Additional local evidence from another affected Codex Desktop thread:

• Codex App: 26.519.81530 (3178)
• Bundled agent: codex-cli 0.133.0
• Platform: macOS 26.4, arm64
• Failing existing thread was originally created with codex-cli 0.117.0-alpha.12, then resumed under 0.133.0.
• The failure reproduced twice in the same thread during automatic remote compaction.
• Logged failing endpoint: /responses/compact
• The compact HTTP request completed with 200 OK, then the client reported:

stream disconnected before completion: unknown variant auto, expected high or original at line 1 column 63665

• Logged compaction stats for the failed turn:
• last_api_response_total_tokens=216527
• all_history_items_model_visible_bytes=1198099
• failing_compaction_request_model_visible_bytes=1203098
• model_context_window_tokens=Some(258400)
• Immediately before the failed compaction, the thread had a user screenshot attachment.
• I checked the local JSONL transcript and found no literal "detail":"auto" or "detail": "auto" entries.
• The image attached in the triggering turn is recorded as detail=high.
• The local transcript does contain many turn_context entries with summary=auto, including the turn immediately before the failing compaction.

Inference: this does not look like an obvious local transcript corruption where an image detail was persisted as auto. It may be a schema/version mismatch in the compact request or remote compact response handling, potentially involving a non-image field named summary=auto being interpreted through a detail enum that only accepts high/original.

Asked Codex to clean the whole thread. Worked

"Patched both broken transcripts:
fork transcript
original transcript
What changed:
Added "detail":"high" to every input_image object missing detail.
First pass fixed 147 direct user image entries.
Recursive pass fixed another 3,887 image entries inside compacted history records.
Validation now shows 4,079 image objects, all with detail=high, and no remaining detail:auto."

Asked Codex to clean the whole thread. Worked "Patched both broken transcripts: fork transcript original transcript What changed: Added "detail":"high" to every input_image object missing detail. First pass fixed 147 direct user image entries. Recursive pass fixed another 3,887 image entries inside compacted history records. Validation now shows 4,079 image objects, all with detail=high, and no remaining detail:auto."

i appreciate the effort, @nostitos

can you please tell me the exact prompt you used?

It's a long thread, but what I would do is refer to that issue and say, FIX

The previous reply was :

The real fix needs to happen upstream in Codex’s compaction path.

The likely code fix is:

// wherever compact request image detail is deserialized/normalized
enum ImageDetail {
High,
Original,
Auto, // accept legacy/default value
}
Then normalize before sending/processing compact work:

match detail {
ImageDetail::Auto => ImageDetail::High,
other => other,
}
More robustly: /responses/compact should never wedge a thread on one unsupported enum. It should either accept auto, downgrade the image to high, drop the media from the compact input, or fall back to text-only compaction.

For your local thread, the safest workaround is not to edit Codex’s persisted state directly. Start a fresh thread and seed it with a compact handoff summary from the broken thread. That avoids triggering remote compaction over the 573 MB JSONL history.

Riskier local attempts:

Back up ~/.codex/sessions/...019d2a61...jsonl and ~/.codex/state_5.sqlite*.
Remove or redact old image-bearing history/events from the broken transcript.
Try reopening the thread so compact has no image payload to normalize.
I would not do step 2 unless you accept possible thread corruption. The cleaner fix is upstream: accept or normalize auto in compact image detail handling, plus add a regression test using a long thread with screenshots and automatic compaction.

First promot of thread :

investigate the codex issue I have with compaction. 

them maybe file an issue at https://github.com/openai/codex/issues


Context automatically compacted
Error running remote compact task: stream disconnected before completion: unknown variant auto, expected high or original at line 1 column 63665

First promot of thread : `` investigate the codex issue I have with compaction. them maybe file an issue at https://github.com/openai/codex/issues Context automatically compacted Error running remote compact task: stream disconnected before completion: unknown variant auto, expected high or original at line 1 column 63665 ``

what exactly did you do? open a new thread (in the SAME project) and then.. wrote this prompt? and it worked? it gave you something to solve the compaction error in the affected thread?

It's a long thread, but what I would do is refer to that issue and say, FIX The previous reply was : The real fix needs to happen upstream in Codex’s compaction path. The likely code fix is: // wherever compact request image detail is deserialized/normalized enum ImageDetail { High, Original, Auto, // accept legacy/default value } Then normalize before sending/processing compact work: match detail { ImageDetail::Auto => ImageDetail::High, other => other, } More robustly: /responses/compact should never wedge a thread on one unsupported enum. It should either accept auto, downgrade the image to high, drop the media from the compact input, or fall back to text-only compaction. For your local thread, the safest workaround is not to edit Codex’s persisted state directly. Start a fresh thread and seed it with a compact handoff summary from the broken thread. That avoids triggering remote compaction over the 573 MB JSONL history. Riskier local attempts: Back up ~/.codex/sessions/...019d2a61...jsonl and ~/.codex/state_5.sqlite*. Remove or redact old image-bearing history/events from the broken transcript. Try reopening the thread so compact has no image payload to normalize. I would not do step 2 unless you accept possible thread corruption. The cleaner fix is upstream: accept or normalize auto in compact image detail handling, plus add a regression test using a long thread with screenshots and automatic compaction.

wait.. this is extremely confusing.. i don't understand what you did here

yes i open a new thread in the same project

The final prompt was just "Try to fix this locally."

<img width="751" height="678" alt="Image" src="https://github.com/user-attachments/assets/2743e189-e40f-4ee4-a54e-9292d29c0c4c" />

give me a single prompt for someone else trying to fix this

Investigate and fix Codex Desktop remote compaction failing with:

`Error running remote compact task: stream disconnected before completion: unknown variant auto, expected high or original`

Local evidence: long/forked Codex threads contain legacy `input_image` objects with missing `detail`; during `/responses/compact`, those appear to be treated as `auto`, but compact deserialization only accepts `high` or `original`. Fix by normalizing missing/`auto` image detail to `high` before compact serialization/deserialization, including inside compacted history records. Add a regression test with a long thread containing old `input_image` entries without `detail`, then trigger compaction and verify it succeeds instead of wedging the thread.