Resume/handoff to third-party Responses providers fails: item type "compaction" is not supported

What version of Codex is running?

codex-cli 0.154.0 (also reproduced via Codex Desktop 0.154.0-alpha.6.2)

What issue are you seeing?

When a session that has gone through auto-compaction is resumed (or handed off) with a third-party model provider using wire_api = "responses", every request fails with:

{"error":{"code":"invalid_request_error","message":"invalid_request_error: invalid_request_error: input.12: item type \"compaction\" is not supported","type":"invalid_request_error"}}

The provider is Kimi for Coding (https://api.kimi.com/coding/v1), which implements a Responses-compatible endpoint. The same problem presumably affects any non-OpenAI Responses-compatible provider.

Root cause

On resume, Codex replays the persisted rollout history into input verbatim. Sessions that were compacted contain an item like:

{"type":"compaction","id":"cmp_...","encrypted_content":"gAAAAAB..."}

compaction is an OpenAI-private item type — the encrypted_content is only meaningful to OpenAI's backend. Third-party "Responses-compatible" endpoints implement the public item subset (message, function_call, reasoning, ...) and reject unknown item types, so the whole request is rejected and the thread can never be continued with that provider.

This makes switching an existing (compacted) thread between OpenAI models and third-party providers impossible. Note that wire_api = "chat" is no longer an escape hatch since it was removed (#7782).

Steps to reproduce

1. Configure a third-party provider with wire_api = "responses" (e.g. Kimi for Coding).
2. Have a session that went through auto-compaction with any model (the rollout contains a compacted record / a compaction response item).
3. Resume the session with the third-party model (codex exec resume <id> "...", or switch the model of an existing thread in Codex Desktop).
4. Every turn fails with item type "compaction" is not supported.

What is the expected behavior?

Codex should not send OpenAI-private item types to providers that can't understand them. When the active provider is not OpenAI, history replay should strip compaction items (or downgrade them to a plain text message such as "[earlier context was compacted]"), the same way the local summary bridge messages are already plain text.

Additional information

Verified workaround: a localhost proxy that rewrites input items of type: "compaction" into a placeholder message item makes resume work with the third-party provider (all requests return 200 and the thread continues normally), which confirms the only blocker is this item type being forwarded as-is.

Start at history replay that serializes persisted rollout records into the Responses input, especially handling of compaction items and the existing local summary bridge messages. Reproduce with a compacted session and a third-party wire_api="responses" provider; done means compaction items are not forwarded to non-OpenAI providers and resume requests succeed.