Resume session: stream disconnected before completion

What version of Codex CLI is running?

v0.116.0

What subscription do you have?

vertex ai key based

Which model were you using?

gpt-5.4

What platform is your computer?

linux

What terminal emulator and version are you using (if applicable)?

bash

What issue are you seeing?

Unable to resume session after few days. I get error:
■ stream disconnected before completion: stream closed before response.completed

Here is what I found

----
When you send include: ["reasoning.encrypted_content"] (codex always does for reasoning models — core/src/client.rs:834), the upstream Responses API returns each reasoning item with an opaque blob:

"encrypted_content": "gAAAAABpxomMi1m..." ← Fernet ciphertext (Python cryptography lib)

The blob is the model's internal reasoning trace — chain-of-thought tokens, hidden state — encrypted with a server-side key. The client cannot read it. The contract is: hold it, send it back on the next turn, and the server decrypts it to give the model continuity of reasoning. This exists so clients can use store: false (no server-side conversation persistence) yet still get reasoning continuity across turns.

Why it works "in‑session" but not "on resume"

Nothing changes on the codex side. What changes is which key is alive on the server. Two ways that key dies:

1. Snapshot rotation. Today's gateway response identifies the upstream as prod-japaneast-... That's an Azure deployment of OpenAI's gpt-5.4-2026-03-05 snapshot. Azure regularly redeploys with patched snapshots; each new snapshot has its own key set. Blobs encrypted under the old snapshot's key won't decrypt under the new one.
2. Key TTL / rotation. Even within a single snapshot, the encryption keys are typically bound to a relatively short window (think hours/days — common practice with Fernet keys for forward secrecy). The server rotates keys; old ciphertexts become unreadable.

Your session was created 2026‑03‑27, ~24 days ago. By 2026‑04‑20, at minimum the keys have rotated; very likely the snapshot has also been redeployed at least once. Both effects make the historical encrypted_content blobs un-decryptable now.

Why nothing client-side can "fix" the encryption

The blob is opaque. There is no decryption key on your machine. There is no way to "renew" or "re-encrypt" it — only the original snapshot's server, with the keys that were live at 2026‑03‑27, could have read it. Those keys are gone.

That's why the only options are: drop the encrypted blobs (lose reasoning continuity, keep visible history), or abandon the conversation. There is no third path.

What steps can reproduce the bug?

Try resuming older session when using token based auth.

What is the expected behavior?

Session should continue to work as expected.

Additional information

_No response_