codex resume fails for specific sessions with "stream disconnected before completion", while new sessions work normally #8256

What version of Codex is running?

0.73.0

What subscription do you have?

business

Which model were you using?

gpt-5.2 high

What platform is your computer?

Linux 3.10.0-957.el7.x86_64 x86_64 x86_64

What issue are you seeing?

When using codex resume to continue certain existing sessions, the session fails almost immediately with errors like:

Conversation interrupted - tell the model what to do differently.
stream disconnected before completion: Transport error: error decoding response body

However, starting a brand new session with codex or /new works reliably with the same model, network, proxy, and authentication.

Key observations:

• Only specific existing sessions are affected.
• New sessions created with the same Codex version and model work normally.
• The failure appears during session resume / history replay, not during normal request handling.
• The same environment can successfully make API calls to https://api.openai.com through the configured proxy (verified with curl).
• Killing and restarting local SSH tunnels does not change the behavior.
• Creating a new session and manually copying the relevant context from the old session works as a workaround.

This suggests a bug related to session resume, history replay, or context reconstruction for certain sessions, rather than a networking or authentication issue.

What steps can reproduce the bug?

Uploaded thread: 019b2b81-1f7e-7b23-ad5c-f7d3e5d10776

What is the expected behavior?

codex resume should reliably restore and continue an existing session, or gracefully fall back to a summarized context if the full history cannot be replayed.

At minimum, resuming a session should not fail due to corrupted or partial history data.

Additional information

• The problem is not resolved by restarting the CLI, SSH session, or proxy.
• The problem does not occur for newly created sessions.
• The issue appears consistent with a session-level bug rather than an account- or network-level issue.
• Workaround: start a new session and manually paste relevant context from the old session.

If helpful, I can provide affected session IDs or logs with sensitive information redacted.