Codex resume: how to continue a Codex CLI session

All of these are in codex-cli 0.163.0:

Every form takes an optional prompt after the id, so you can resume and send the next message in one line:

codex resume --last "now add tests for the parser"

Plain codex resume lists your saved sessions and reloads the one you choose with its history intact. Two filters decide what you see:

• Directory. By default the list only shows sessions whose working directory matches the one you are in. Run it from the project folder, or add --all to drop the filter and get a CWD column so you can tell projects apart.
• Interactive only. Sessions created by codex exec are left out. Add --include-non-interactive to include them in the picker and in --last.

cd ~/code/my-app && codex resume
codex resume --all
codex resume --all --include-non-interactive

When the folder you are in and the folder the session was saved in differ, Codex has a setting for which one to use, under its preferences for resuming and forking. The picker layout (dense or comfortable rows) is set in the same place.

codex resume --last skips the picker and continues the newest recorded session. It is the Codex equivalent of what other tools call continue.

There is no --continue flag in Codex. That is Claude Code's spelling (claude --continue), and Codex stops with error: unexpected argument '--continue' found whether you put it after codex or after codex resume. If a script or an old answer tells you to run codex --continue, replace it with codex resume --last.

codex resume takes either a session UUID or a session name. If the argument parses as a UUID, it is treated as one. Names come from the thread title, and you can set your own with /rename inside the TUI, which makes a long running session easy to reach:

codex resume 0199f3c2-5e1a-7b3d-9c40-2a8e1f6b7d15
codex resume "Fix login redirect"

Three ways to find the id when you do not have it:

• The index. ~/.codex/session_index.jsonl has one line per session with id, thread_name and updated_at. Search it by name: grep -i "login" ~/.codex/session_index.jsonl.
• Your prompts. ~/.codex/history.jsonl stores each prompt you typed with its session_id, so you can find a session by something you said in it: grep -i "migration" ~/.codex/history.jsonl.
• The file name. Each rollout file ends in the session UUID: rollout-<time>-<uuid>.jsonl.

codex resume accepts the same options as codex itself, including -m, --sandbox, --ask-for-approval and -C, so you can pick up a session on a different model or with tighter permissions than it started with.

codex exec is the non-interactive mode, and it has its own resume subcommand. It takes the same --last, --all, id or name, and the prompt can come from stdin with -:

codex exec resume --last "run the test suite again and fix what fails"
codex exec resume 0199f3c2-5e1a-7b3d-9c40-2a8e1f6b7d15 "summarise what changed"
git diff | codex exec resume --last -

Two things trip this up. A run started with codex exec --ephemeral writes no session file, so there is nothing to resume afterwards. And exec sessions are hidden from the interactive picker unless you pass --include-non-interactive.

Resuming appends to the same session. Forking copies it into a new session and leaves the original untouched, which is what you want when you are about to try something you may throw away.

codex fork            # pick a session to fork
codex fork --last     # fork the most recent one
codex fork <SESSION_ID>
codex exec fork <SESSION_ID> "try the other approach"

Inside the TUI, /fork forks the chat you are in and /new starts a fresh chat in the same CLI session.

A session that does not appear in the picker is almost always still on disk. Check these in order:

1. Wrong folder. The picker filters by working directory. Try codex resume --all.
2. It was an exec run. Add --include-non-interactive.
3. It was archived. Archive hides a session without deleting it. codex unarchive <id or name> brings it back.
4. It predates the current storage layout. codex migrate-rollouts reports legacy sessions that the picker cannot see, and codex migrate-rollouts --apply moves them.

The full diagnosis, including compressed .jsonl.zst rollouts, is in Older Codex sessions are missing from resume.

If the session is listed but will not open, and Codex says This thread is open elsewhere. Close it there and retry resume to continue., another Codex process still holds it. Close that one first. See Codex thread already has an active writer.

Codex keeps two different histories under $CODEX_HOME (~/.codex by default). history.jsonl is your prompt history, one line per message you typed. The sessions themselves are rollout files in a dated tree under sessions/, which is what codex resume reads. Setting history.persistence = "none" in config.toml stops prompts from being written to history.jsonl.

The exact layout, the index files and why a session path cannot be worked out from the project folder are covered in Where Codex CLI stores sessions.

Codex has no sync and no export or import command for sessions. A session exists only in the rollout file on the machine that ran it, and it is tied to a working directory path that has to exist where you resume it. Copying rollout files between machines is not a documented workflow, so do not count on a copied file showing up in the picker.

The reliable approach is to keep the session where it is and reach that machine instead: SSH in and run codex resume there, or use a tool that drives the original machine remotely.

Termdeck lists the Codex sessions in the folders you have added on each connected machine in one sidebar, including the ones you started in a terminal, so you do not need the picker or the session id. Open one and keep typing. It reads and writes the same rollout files, so the next codex resume in your terminal picks up what you did in the browser, and the other way round.

While a local Codex process still holds the thread open, Termdeck shows the chat as controlled by Codex CLI and keeps it read only rather than writing alongside it. You can still watch it live, from any machine or your phone. See Chats and sessions for how the handoff works, and Codex CLI web UI for the overview. The same task on the other engines: resume a Claude Code session and resume a Grok CLI session.