Resume runs before every turn
A Codex client re-establishes the thread each time you send a message. Nothing carries over implicitly between turns, so nothing can go stale between them either.
Codex CLI guide: resuming a session
Codex takes the opposite approach to Claude. Rather than resuming once when a process starts, it resumes the thread before every single turn. That is slower on a long conversation and it buys something real: the session can never be out of date.
OpenAI
A Codex client re-establishes the thread each time you send a message. Nothing carries over implicitly between turns, so nothing can go stale between them either.
Because the thread is re-read every turn, work you did in the terminal between two browser messages is already there. Claude needs a process restart for the same thing.
Resuming takes a thread id and the working directory together. A thread resumed against the wrong directory is not the same session, which is why a moved project can look like lost history.
The cost scales with the conversation, so resuming is the slow part of a turn on a thread with a long history. It is worth a much longer timeout than a normal request, and it is the usual explanation for a Codex turn that seems to hang before it starts.
The stored rollout is filed by date rather than by project, so a resume is always keyed on the session id. There is no path you can compute from the project directory.
Compare
| Claude Code | Codex CLI | Grok CLI | |
|---|---|---|---|
| Resume mechanism | A flag on the next run | An explicit resume call | Session state re-read per turn |
| Happens | Once, at process start | Before every turn | Before every turn |
| Picks up terminal edits | At the next process start | Yes, every turn | Yes, every turn |
| Identified by | Session id | Thread id plus working directory | Session id |
| Cost of resuming | Cheap | Can be slow on a long thread | Cheap |
Termdeck drives all three from one console, so the differences above stop being three separate habits to remember.
FAQ
Codex resumes the whole thread before every turn, and that cost grows with the length of the conversation. The delay lands before the first token rather than during the response, which is why it reads as a hang rather than as slowness.
Yes. Because the thread is resumed before every turn rather than once at process start, anything appended to the rollout between two messages is picked up on the next one.
Yes. A resume takes the thread id and the working directory together. Resuming against a different directory does not restore the same session, so a moved or renamed project looks like missing history.
Yes. Codex compresses older rollouts to .jsonl.zst in place and reads them back transparently. Only a third-party tool that looks solely for the .jsonl extension will fail to find them.
Claude Code, Codex and Grok in one browser console