Codex resume: picking CLI sessions back up without starting over

🧭 What a Codex session is and where it lives

A session in Codex CLI is the complete record of a conversation: my prompts, the model's replies, tool calls and their results. As I work, the CLI keeps writing it to a JSONL file under ~/.codex/sessions/. Saving is always on: there is no save command, because none is needed.

The important detail is that resuming is anchored to the working directory: by default codex resume considers the sessions started from the current folder. Each project therefore has its own history, and when I resume the latest session I get the one from this repo, not the last thing I did somewhere else.

There are three entry points: codex resume from the terminal, /resume from inside an already open session, and codex exec resume for non-interactive runs. I use all of them, at different moments of the day.

# reopens the latest session of the current folder
codex resume --last

# opens the interactive session picker
codex resume

# resumes a session by name or by ID
codex resume auth-refactor

# from inside an active session: switch conversation
/resume

🔁 --last, the picker, and resuming by name: how I choose

codex resume --last is the daily gesture: it reopens the most recent session of the folder I am in, with no IDs to remember and no questions asked. It is the equivalent of Claude Code's --continue, and for single-thread work it covers 90% of the cases.

When the latest session is not the right one, I run codex resume with no arguments and the picker opens: a list of recent sessions with date and preview, which I navigate with the arrow keys and confirm with Enter. By default I see the sessions of the current directory; with --all I widen the search to those started from any folder.

The third way is direct resumption: codex resume <id-or-name> accepts both the session ID (a UUID) and the session's name, and if the argument parses as a UUID, the ID wins. The name is also what I use with codex archive, codex unarchive and codex delete to keep the list tidy: finished sessions get archived, useless ones deleted.

📂 Different folder? The role of tui.resume_cwd

A case that happens often: I resume a session from a directory different from the one it started in. Codex notices and asks me which folder to use — the current one or the one saved in the session. It is a sensible question, because the folder determines what the sandbox is allowed to write.

If the answer is always the same, I pin it in config.toml with tui.resume_cwd: "current" to always use the directory I launch from, "session" to always go back to the original one. An explicit --cd (or -C) on the command line still wins over the configuration.

A handy detail: codex resume accepts the same global flags as codex, so I can resume a session while changing model or sandbox on the fly — for instance reopening in read-only a session that started in workspace-write, just to ask it questions.

# ~/.codex/config.toml

[tui]
# "current"  → use the directory I launch codex resume from
# "session"  → go back to the session's original directory
resume_cwd = "current"

🌿 codex fork and /side: experimenting without losing the thread

When I am at a good point and want to try a different route — another library, a more aggressive approach — I do not sacrifice the conversation that got me there: I use codex fork, which duplicates a previous session into a new thread while leaving the original transcript intact. From inside an active session I do the same with /fork.

For short detours there is /side: it opens a throwaway side conversation without leaving the main task. I use it for sanity checks — "does this approach have an obvious problem?" — before returning to the main thread, without polluting the session's context.

The distinction to keep in mind is the same as with any tool of this kind: the fork duplicates the conversation, not the files. Code changes made in a branch are real and shared by any session working in the same folder: for files, the restore point remains Git.

🤖 exec resume: picking up non-interactive runs too

The part I use most in scripts is codex exec resume: the non-interactive mode has its own dedicated resumption, with the same logic as the TUI. codex exec resume --last re-attaches the most recent run of the current folder, codex exec resume <session-id> a specific one, and in both cases I can pass the follow-up prompt right away.

It is the piece that makes codex exec incremental: the first run builds the context — it understands the repo, does the heavy lifting — and the following ones reuse it instead of starting from scratch. In a pipeline, each step picks up the previous step's context by passing the same session.

With --json I get JSONL events line by line, easy to process in scripts; --all widens the search for the most recent run to every directory. These are the same building blocks I use for overnight automations: one long run in the evening, targeted follow-ups in the morning.

# first run: builds the context
codex exec "analyse the repo and propose a refactor plan"

# follow-up on the same context, no restart
codex exec resume --last "apply step 1 of the plan"

# targeted resumption by session ID, with JSONL output
codex exec resume <session-id> --json "update the tests"

⚠️ The limits worth knowing: transcript, not model state

Resuming rebuilds the context by re-reading the transcript, not by restoring the model's internal state. For long sessions this means two things: reopening takes a moment, and a very long transcript can get close to the context limits before the whole history is reloaded. After resuming a task interrupted midway, two lines from me — "we were at X, the current state is Y" — reorient the model faster than letting it infer everything from the log.

Watch out for commands that look harmless too: /clear does not clean the screen, it starts a new conversation; to clear the view while keeping the context you use Ctrl+L. Mixing them up means ending up in a blank session without meaning to — recoverable via the picker, but it is an extra trip.

Finally, persistence covers the conversation, not the project's rules. Conventions, architectural decisions and constraints every session must know belong in AGENTS.md, which Codex reads at every start: the session is for "continue what I was doing", the project file is for "understand this project".

✅ The flow I follow to never lose work

Put together, these commands become a single habit: I never close a piece of work hoping to remember it, I leave it in a session I know how to find again. The mini-flow I follow, in order:

• I resume with *--last* for daily single-thread work, and switch to the picker only when there is more than one thread.
• I fork before taking risks: a codex fork costs nothing and saves the good route if the experiment does not hold up.
• I use /side for detours: sanity-check questions must not pollute the main task's context.
• In scripts I chain runs with codex exec resume --last, so each step reuses the previous step's context.
• I archive and delete with codex archive and codex delete: a short picker is a useful picker.