Codex Resume: Reopen Your Last or Older CLI Session

codex resume is how you reopen a previous Codex CLI conversation with its full history intact. Here are the commands:

codex resume --last                  # continue the most recent session
codex resume                         # pick from a list of recent sessions
codex resume <session-id-or-name>    # open one specific session
codex resume --last "keep going"     # reopen and send a follow-up prompt
codex resume --all                   # include sessions from other directories

Everything below explains when to use each one, how to restart instead of resume, and where the session data lives.

codex resume at a Glance

Note there is no -l short flag. codex resume -l fails with error: unexpected argument '-l' found; write out --last.

Resume Your Last Session

This is the command most people want:

codex resume --last

It reopens the most recent recorded session and skips the picker entirely. Two behaviours are worth knowing:

• It is scoped to your current directory. Codex filters sessions by working directory, so --last means "the most recent session started here", not "the most recent session anywhere". If you have switched projects, add --all.
• It ignores non-interactive runs by default. Sessions created by codex exec are excluded unless you pass --include-non-interactive.

Combine both when you genuinely want the latest thing you did on the machine:

codex resume --last --all --include-non-interactive

Resume a Specific Earlier Session

If the last session is not the one you want, run resume with no target to get the interactive picker:

codex resume

The picker lists recent sessions with their timestamps and a transcript preview. Arrow keys navigate, Enter selects. Add --all to drop the working-directory filter and show a CWD column so you can tell projects apart.

When you already know which session you need, pass it directly. Codex accepts either a UUID or a session name, and a UUID wins if the argument parses as one:

# By ID
codex resume 019dd4bf-0929-7ea0-b227-1f51085e7d71

# By name (set earlier with /rename)
codex resume "Refactor auth module"

Naming sessions is what makes the second form usable. Inside any session, run /rename to give the current thread a memorable name; the mapping is stored in ~/.codex/session_index.jsonl and the name then works anywhere a session ID does — including codex archive, codex delete, and codex unarchive.

Continue the Session You Are Already In

If Codex is still open, you do not need the CLI at all:

When a long conversation starts to feel sluggish or lossy, /compact is usually the right move — it summarizes history and frees tokens while keeping the thread going, which is different from resuming and different again from starting over.

How to Restart Codex (Not the Same as Resuming)

"Restart" and "resume" get searched interchangeably, but they do opposite things. Resuming brings history back; restarting throws it away or reloads the program. Pick by what you actually want:

Start a fresh conversation without leaving the CLI:

/new

Clear the terminal and start a fresh chat:

/clear

Quit and relaunch the program:

/quit

then

codex

Ctrl+C also interrupts; in a side conversation it returns you to the main thread rather than exiting.

Restart on a newer version — the fix when a bug or a missing flag is the reason you are restarting:

codex update
codex --version

Diagnose before restarting. If Codex is misbehaving rather than just stuck, this checks installation, config, auth, and runtime health:

codex doctor

None of these recover a conversation. If you restarted and then realised you needed the old thread, codex resume --last will still find it — the transcript was written to disk as you went.

Resume and Prompt in One Command

Any resume form accepts a trailing prompt, which is sent as soon as the session reopens:

codex resume --last "Fix the race condition you found earlier"
codex resume 019dd4bf-0929-7ea0-b227-1f51085e7d71 "Implement the plan we discussed"

This is the fastest way back into flow after a break, and it is the form to use in shell aliases.

Resuming Non-Interactively

For scripts, CI jobs, and scheduled work, use the exec subcommand:

codex exec resume --last "Complete the refactoring task"
codex exec resume 019dd4bf-0929-7ea0-b227-1f51085e7d71 "Run the test suite"

# Read the prompt from stdin
echo "Summarize what changed" | codex exec resume --last -

codex exec resume accepts a session ID or a thread name, same as the interactive form.

Fork Instead of Resume

codex fork is a top-level command, not just a slash command. It branches a new session off an existing one and leaves the original transcript untouched:

codex fork --last                    # fork the most recent session
codex fork                           # pick which session to fork
codex fork <session-id> "Try Redis instead"

Use resume when you want one continuing thread. Use fork when you want to try a second approach and keep the first. A thread must contain at least one turn before it can be forked.

Where Session State Lives — and What Happens If It Is Lost

Codex writes every session to disk as it goes, under your Codex home directory (~/.codex by default):

Find the file for the session you are in with /rollout, or list today's directly:

ls -la ~/.codex/sessions/$(date +%Y/%m/%d)/

What breaks when this is lost. The transcript files are the session — there is no server-side copy of a local CLI conversation to fall back on. If ~/.codex/sessions is deleted, wiped by a machine rebuild, or lives inside a container that was destroyed, those conversations are gone and codex resume has nothing to offer. If only session_index.jsonl is lost, the transcripts survive but name-based lookup and the picker's metadata degrade.

Two practical consequences:

• Sessions are portable. Copying ~/.codex/sessions to another machine carries your history with it.
• On Windows, mind the boundary. Sessions created inside WSL live in the WSL filesystem and are not the same set as sessions created by a native Windows install. Resume from the same environment you started in.

For a full map of Codex's on-disk layout, see where Codex configuration files are stored.

Housekeeping: Archive, Delete, Unarchive

Once you have named sessions, you can manage them by name or ID from the shell:

codex archive "Refactor auth module"     # remove from the picker, keep the file
codex unarchive "Refactor auth module"   # bring it back
codex delete <session-id>                # permanently delete (UUID required)

The same actions exist in-session as /archive and /delete, both of which exit Codex after running. codex delete prompts for confirmation; adding --force skips the prompt but then requires a UUID rather than a name.

Troubleshooting

The session I want is not in the picker. Add --all — the default view is filtered to your current working directory. If it was created by codex exec, add --include-non-interactive. Then confirm the file exists:

ls -la ~/.codex/sessions/$(date +%Y/%m/%d)/

codex resume -l errors. That short flag does not exist. Use --last.

Resume by name fails. The name must have been set with /rename; check ~/.codex/session_index.jsonl for the exact string. If the argument parses as a UUID it is treated as an ID, not a name.

The resumed session seems to have forgotten things. Long conversations get compacted, so older detail may have been summarized rather than kept verbatim. Ask Codex what it retains, and use /status to see context utilization.

resume is not a recognised command. You are on an old build. Update and re-check:

codex update      # or: npm install -g @openai/codex ; brew upgrade codex
codex --version

Next Steps

• Install Codex CLI
• Where Codex configuration files are stored
• Fix slow Codex performance if long sessions are the reason you keep restarting
• Use Git worktrees with Codex to keep one session per branch