Cold resume can replay undecryptable encrypted reasoning without a safe fallback

Start with the runtime paths responsible for replay serialization, pending-turn state, and side-effect ordering, using the deterministic provider fixture reproduction described in the issue. Done means a structured decrypt/parse failure can trigger one atomic pre-side-effect retry without duplicating the user event, while later resumes avoid the invalidated prefix and unrelated or repeated failures remain terminal.

Summary

When a cold-resumed session preserves prior reasoning fields, the first model request can fail with HTTP 400 if the provider can no longer validate the replayed encrypted_content:

Encrypted content ... could not be decrypted or parsed.

The logical model identifier can remain unchanged while the provider's underlying deployment or encryption domain changes. The SDK currently treats this as a terminal session error. Consumers cannot atomically remove the incompatible pre-resume reasoning, retry the pending turn, and prevent the same payload from being replayed on later resumes.

This leaves consumers with two unsafe choices:

1. Strip reasoning on every resume, losing reasoning continuity and prefix-cache reuse.
2. Preserve reasoning on every resume, leaving the session unrecoverable when a previously valid blob becomes unverifiable.

This is related to #615, which correctly preserved encrypted_content for stateless multi-turn requests. Preservation should remain the normal path, with a bounded recovery path for blobs that a provider can no longer verify.

Versions and configuration

• Reproduced with the resume behavior in @github/copilot CLI 1.0.78.
• The same relevant behavior is present in CLI 1.0.73.
• Prior reasoning is preserved on resume by setting COPILOT_STRIP_REASONING_ON_RESUME=false.
• The provider uses a stable logical model name but may route requests across compatible model deployments.

Reproduction

A provider fixture can reproduce the failure deterministically:

1. Create a session with a reasoning model.
2. Complete a turn whose assistant reasoning contains encrypted_content.
3. Disconnect and cold-resume the session with reasoning preservation enabled.
4. Send the next user message.
5. Have the provider reject the replayed blob with HTTP 400 and the decrypt/parse error above.

Actual behavior

The resumed turn fails terminally. A generic consumer retry reuses the same incompatible history. The public SDK API does not provide an atomic way to sanitize the resumed prefix without risking a duplicate user event or repeated tool side effects.

Expected behavior

The SDK should preserve reasoning by default, but recover safely when the first post-resume call proves that prior encrypted reasoning is incompatible.

One possible design is a resume policy such as preserveWithStripFallback:

1. Match only the structured HTTP 400 decrypt/parse failure, not every encrypted-content or invalid-request error.
2. Recover only before assistant output or tool execution has started.
3. Atomically strip incompatible pre-resume opaque reasoning and retry the same pending turn once.
4. Do not append the user event twice.
5. Persist an invalidation cutoff or generation so later resumes do not replay the poisoned prefix.
6. Continue preserving reasoning generated after recovery.
7. If available, use an opaque provider-issued verification-domain identity to avoid replay proactively when compatibility does not match.

Unrelated errors, failures after side effects, and a failed recovery attempt should remain terminal. The retry must never loop.

Why this belongs in the runtime

The runtime owns replay serialization, pending-turn state, and side-effect ordering. Handling this outside the SDK cannot reliably distinguish a safe first-call recovery point or rewrite session history atomically.

This recovery keeps the cache and multi-turn reasoning benefit for healthy resumes. Only a session with incompatible ciphertext loses its old hidden-reasoning prefix once, after which newly generated reasoning can be preserved normally.