Codex Resume: Picking Up a Previous Session

A session you closed yesterday, mid-task, doesn't have to become a session you re-explain from scratch today — codex resume is built specifically to pick up a previous session's accumulated context rather than starting cold, and knowing when that's actually the right call versus when a fresh session serves you better is worth understanding rather than defaulting to reflexively either way.

What resuming actually restores

A resumed session carries forward the accumulated context of the original — prior turns, files it read, decisions already made along the way — rather than reconstructing any of that from your memory of what happened. This is genuinely valuable for a task you stepped away from mid-stream: the model doesn't need you to re-explain what's already been established, and it can continue reasoning from exactly where the conversation left off.

When resuming is clearly the right call

A task interrupted partway through — you closed your laptop, got pulled into a meeting, needed to switch to something more urgent — is the clean case for resuming. The context that made the session productive is still relevant; nothing about the underlying task or codebase has meaningfully changed in the interim, and re-establishing all of that from scratch would just be redundant, wasted effort compared to picking up where you left off.

When resuming can actively work against you

If meaningful time has passed and the codebase has changed since the session was paused — someone else merged changes, you made edits outside that session yourself — a resumed session may be reasoning from a stale understanding of the code's current state. Unlike a fresh session, which would naturally re-read whatever it needs from the current state of the files, a resumed session can carry forward assumptions from what it last saw, which is exactly the kind of staleness this site warns about in the context of long-running sessions generally, just triggered by a gap in time rather than a long unbroken conversation.

The overlap with why sessions lose the thread

A session resumed after accumulating a lot of context before the pause shares a real risk with any other long session: the same context-dilution effect that makes very long unbroken sessions less sharp over time applies just as much to a resumed session carrying forward a large accumulated history, interruption or not. If a session was already large and unwieldy before you paused it, resuming doesn't reset that — it picks the accumulated context back up exactly as it was, dilution included.

A practical middle ground: summarize before resuming

For a session that's both meaningfully large and has a real time gap since it was paused, an alternative to a straight resume is starting a fresh session and providing your own concise summary of what the paused session had already established, rather than either accepting the full accumulated context or discarding it entirely. This captures the useful part of what resuming would give you — not re-explaining from zero — while avoiding both the staleness risk and the context-dilution risk of resuming a large session verbatim.

Checking whether the codebase has actually moved before resuming

Before resuming a session with any real time gap, a quick check — git log since the session was paused, a glance at what's changed — tells you whether staleness is a real risk for this specific case or a hypothetical one. A session paused an hour ago on a repository nobody else touched in the meantime is safe to resume without much thought; one paused days ago on an actively-developed shared repository deserves that quick check first.

Multiple sessions and which one to resume

If you're running several parallel sessions — across different worktrees, different tasks — keeping track of which session corresponds to which task matters more once resuming becomes part of your workflow, since resuming the wrong session's history into a task it wasn't actually working on produces confusing, irrelevant context rather than useful continuity. Naming or otherwise tracking sessions deliberately, rather than relying on remembering which terminal or window held which conversation, avoids this specific mix-up.

The version-specific details worth checking

Exactly how session identifiers work, how far back resumable history persists, and any flags that modify resume behavior are all details worth checking against the CLI's current documentation for your installed version — this is exactly the kind of subcommand behavior that evolves across releases, and codex resume --help on your actual installed version is a more reliable source than a static guide for the precise mechanics.

Resuming across a model switch

If the original session switched models mid-session with /model before being paused, a resumed session picks up from whatever model was active at the point you left off, not necessarily the CLI's own default — worth confirming with /status immediately after resuming rather than assuming, since continuing to work under an assumption about which model is answering is exactly the kind of mistake this site spends a lot of its guidance trying to prevent.

Why resuming is a workflow decision, not just a technical convenience

It's worth thinking of the choice to resume versus start fresh as a genuine workflow decision with real tradeoffs on both sides, not a default you reach for automatically because it's available. The technical capability to resume doesn't mean resuming is always the right call for a given gap in time or a given amount of accumulated context — treating it as one option among a few, evaluated against the specific situation, produces better outcomes than treating it as the obvious default whenever it's technically possible.