Resume a Codex session with codex resume or /resume

You closed the terminal mid-task yesterday. The code may be committed; the reasoning about what to do next may exist only in that closed session. Codex persists sessions to disk. Reopening one is cheaper than retyping a recap from memory, and far more faithful than a paraphrase the agent will treat as ground truth.

A session, in this chapter, means that saved conversation: messages, tool traces, and decisions in Codex’s session store, restorable with codex resume. It is not the same as the files in your repo.

Picking the session back up

From the shell:

codex resume          # open a picker of past sessions, choose one
codex resume --last   # skip the picker, reopen the most recent session
codex resume <SESSION_ID>   # reopen one specific session by id
codex resume --all    # widen search beyond the current directory (see reference)

Inside a running TUI, /resume opens the saved-session picker and reloads the chosen transcript without leaving the session.

For day-to-day work in one repo, codex resume --last from that repo’s root is often enough:

$ cd ~/code/budgetcli
$ codex resume --last

> where did we leave the amount parsing?

What answers is the restored thread, not a summary of it. If yesterday’s session recorded that a date fix was committed, that a float parse line was flagged and left for later, and that app/services/categorise.py exists but has no callers, those settled facts should come back as they were closed, not be re-debated from scratch.

Use plain codex resume when the most recent session is not the one you want (for example after a quick README edit that ran after the real work). An illustrative picker list; yours shows your sessions:

$ codex resume

  Select a session to resume:
    budgetcli · README + run notes        yesterday 19:10
  ❯ budgetcli · date fix                 yesterday 18:40
    budgetcli · first look at the repo    2 days ago 16:22

The picker is scoped to where you stand

codex resume --last resumes the most recent session for the current working directory. Run it from your home folder and you may get the wrong thread or none. cd into the project first. The --all flag widens the search across directories; the default cwd scope is intentional.

A restored conversation is not a restored world

Resuming restores the conversation, not the world on disk. The transcript may still show three failing tests, a proposed diff, and review notes from before you committed. On disk, pytest may now pass and the tree may be clean. Treat code as whatever git status and your tests report now. Treat the chat as intent and history that may lag the filesystem.

That gap is normal. No amount of resuming makes the transcript authoritative about disk state. Anything that must survive whichever session opens next (money stored as integer cents, how to run tests, naming conventions) belongs in durable project context such as AGENTS.md, which Codex loads into every new session. In budgetcli (the course’s running example, a small self-hosted personal-finance API in Python and FastAPI), the integer-cents rule already lives there; it did not depend on you resuming yesterday’s thread.

When not to resume

Resuming is cheap when you are continuing the same line of work. Its failure mode is habit: opening yesterday’s thread for a unrelated question because it is convenient. Unrelated turns still occupy the window and steer the model. Resume when the task genuinely continues; start clean when it does not.

When the next step is to compare two implementations from the same starting point without mixing designs in one thread, use /fork instead of stuffing both approaches into the resumed session.