Codex CLI cannot reliably resume session

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #37694

Powered by Codex Action

I’ve now shipped Codex Rescue 0.1.0a3 with regression coverage for this exact oversized persisted-output pattern. It detects oversized JSONL records locally, keeps the original rollout untouched, and fails closed with REVIEW_REQUIRED — it does not claim to fix the WebSocket/502/503 failure itself.

If you still have the affected session, would you be willing to try:

pipx install codex-rescue==0.1.0a3
codex-rescue doctor --latest

If it identifies the affected rollout, a sanitized doctor / salvage --fork / verify result would be very useful. Please don’t post the raw rollout, images, prompts, databases, or credentials.

https://github.com/shleder/codex-rescue

Your 19.3 MB custom_tool_call_output is the whole story, and the mechanism is a byte-vs-token budget mismatch.

Rollout persists tool outputs verbatim — there is no byte cap at persist time — and resume rebuilds the model request from the full history, so every attempt re-sends ~20 MB of inline base64. Codex's context management is token-denominated: images are counted as patches/image tokens (core/src/image_preparation.rs#L29-L36 resizes by dimension/patch limits, not payload bytes), so the session can pass every token check while the serialized request body is far beyond what the gateway accepts. That's why you see the WebSocket drop before response.completed, the HTTPS fallback, and then 502/503 from the edge — and since these surface as generic stream failures, the retry loop just re-sends the same oversized body for 30+ minutes. Smaller sessions work because they're under the byte limit; codex doctor passes because the handshake is fine — only the request body is rejected.

Fix outline: (1) cap/externalize large tool outputs at persist time (store images as files, reference them); (2) add a serialized-request byte guard that triggers compaction or image dropping before send; (3) treat oversized-payload gateway rejections as terminal, not retryable.

For the large rollout and inline payload case, please record whether Vetto fails closed on a budget or returns a bounded diagnostic rather than reading unbounded content.

Thanks for the detailed report. This is a good candidate for a bounded recovery check. Vetto 0.2.0-alpha.2 is available from npm and adds a read-only, copy-only Codex rescue adapter. It does not resume Codex, edit rollout files, or write vendor SQLite. On a disposable copy, try: npm install --global @shleddy/vetto@next; vetto rescue --adapter codex --root <CODEX_HOME> --json scan; then use the exact returned key with diagnose and snapshot ... --output ./vetto-recovery/session.jsonl. Please report OS, Codex/Vetto versions, sanitized JSON, and source SHA-256 before/after; never upload raw transcripts, auth/config, prompts, or tokens. An explicit unavailable/unsupported result is useful too.