How to resume a Codex session
You closed the terminal on a Codex session you weren’t finished with, and now codex resume shows a list that doesn’t include it. The session is almost certainly still on disk. The picker just filters more than people expect.
codex resume opens a picker of recent sessions from the current directory. codex resume --last continues the newest one, and codex resume <id> opens a specific session by id or name. If a session is missing, add --all to include every directory and --include-non-interactive to include codex exec runs. Sessions live under ~/.codex/sessions, or under whatever CODEX_HOME the session ran with.
The resume commands
OpenAI describes codex resume as the way to reopen a recent chat from the current repository, or to search across local chats for older work. The flags below come from the CLI’s own help output in codex-cli 0.146.0.
# pick from recent sessions in this directory
codex resume
# continue the most recent session, no picker
codex resume --last
# open one session by id (a UUID) or by its name
codex resume 0199c3a1-7b2e-7c40-9d15-3f8e2a6b41c7
# resume and send the next instruction straight away
codex resume --last "run the tests again and fix what fails"When you pass something that parses as a UUID, Codex treats it as an id first and only then as a name. Resuming continues the same session. Earlier turns stay in its history and your new turns are added after them.
When the session you want isn’t listed
Four filters account for nearly every “my Codex session is gone” report. Check them in this order:
| Cause | What you see | Fix |
|---|---|---|
| A different directory | The picker filters to the current working directory by default | codex resume --all shows every session with a directory column |
| It was a codex exec run | Non-interactive sessions are left out of the picker and of --last | Add --include-non-interactive |
| A different CODEX_HOME | Sessions from a second account live in that account’s home | Run the command with the same CODEX_HOME the session used |
| You archived it | You ran codex archive on it | codex unarchive <id or name> |
The third row catches people who set up several Codex accounts. Each CODEX_HOME is a complete, separate state directory, sessions included, so your work account’s picker has never heard of the session you ran on your personal account.
If none of the four applies, check whether the sessions folder still exists. A machine rebuild, a deleted ~/.codex or a destroyed container takes the history with it.
Finding an id from a phrase you remember
The picker shows recent sessions. For an older one, you usually remember what you typed, not when. When history is on, Codex appends each prompt to history.jsonl in its home, one JSON line per prompt, with the session id beside it.
# every session where you typed "migration"
grep -i 'migration' ~/.codex/history.jsonl | jq -r '.session_id' | sort -u
# then open it
codex resume <session_id>That’s fine for a one-off search. Don’t build tooling on it. history.jsonl and the session files are Codex’s internal format, not a documented interface, and the shape can change between releases. Tools that need Codex history reliably should go through the codex app-server protocol, which is the supported read surface.
Resume or fork?
codex fork takes the same arguments as codex resume: a picker by default, --last for the newest, or a session id. The difference is where the new turns go. Resume adds them to the original session. Fork starts a new session from the old one and leaves the original as it was.
Fork when you want to try a different approach and might come back. Resume when you’re carrying on with the same plan.
Resuming from a script
The non-interactive form is codex exec resume. It takes a session id or --last, plus the prompt to send. A prompt of - reads it from standard input.
codex exec resume --last "summarise what changed since the last run"
git diff | codex exec resume 0199c3a1-7b2e-7c40-9d15-3f8e2a6b41c7 -Because these runs are non-interactive, they won’t show up in a plain codex resume later. That’s the second row of the table above.
Where Codex keeps sessions
OpenAI’s CLI documentation places sessions under ~/.codex/sessions. On disk they’re grouped by date, one rollout file per session, with the session id at the end of the file name:
~/.codex/sessions/2026/09/29/rollout-2026-09-29T17-16-36-0199c3a1-7b2e-7c40-9d15-3f8e2a6b41c7.jsonlEvery path here moves with CODEX_HOME. Back that directory up if the history matters to you. The same warning applies as above: read the files if you need to, but treat them as Codex’s private format.
| Codex | Claude Code | |
|---|---|---|
| Most recent | codex resume --last | claude --continue |
| Pick one | codex resume | claude --resume |
| Default scope | Current directory, --all for everything | Current directory, Ctrl+A in the picker for every project |
| Stored under | $CODEX_HOME/sessions/ | ~/.claude/projects/ |
The Claude Code side is covered in resuming or restoring a Claude Code session.
Doing it in Crowsnest
Crowsnest is ours, so weigh this section accordingly. It replaces the grep step with a search box and puts Codex and Claude Code history in one gallery.
Read through the supported protocol
Crowsnest lists and reads Codex sessions through codex app-server, never by parsing rollout files. It asks for codex exec runs by name, so they appear beside interactive sessions.
Search every message
⌘K searches every message in every conversation, Claude Code and Codex together, with each result marked by provider.
One limit worth knowing: the gallery reads Codex sessions from the default ~/.codex home. Sessions from additional Codex accounts aren’t labelled by account, and reopening one runs it under the default account. Browsing and searching history is part of every plan, including Standard.
Questions behind the search
How do I resume a Codex session?
Run codex resume to open a picker of recent sessions from the current directory, codex resume --last to continue the most recent one without the picker, or codex resume followed by a session id or name to open a specific one. Add --all to see sessions from every directory.
Why is my Codex session not showing in codex resume?
Usually one of four reasons. The picker filters to the current directory, so run codex resume --all. Non-interactive codex exec runs are excluded unless you pass --include-non-interactive. The session may belong to a different CODEX_HOME, such as a second account, so run the command with that CODEX_HOME set. Or it was archived, in which case codex unarchive with its id or name restores it.
Where does Codex store session history?
Under the Codex home directory, which is ~/.codex unless CODEX_HOME points elsewhere. Sessions are kept in the sessions folder, organised by year, month and day, as rollout files whose names end in the session id. Prompt history is kept separately in history.jsonl. Both are Codex’s internal format and can change between versions.
What is the difference between codex resume and codex fork?
codex resume continues the same session, so new turns are added to its history. codex fork starts a new session from a previous one, leaving the original as it was. Use fork when you want to try a different direction without changing the conversation you might return to.
How do I resume a Codex session in a script?
Use codex exec resume, the non-interactive form. codex exec resume --last "next instruction" continues the most recent session and sends the prompt, and you can pass a session id instead of --last. A prompt of - reads the instruction from standard input.
Codex commands above were checked against the help output of codex-cli 0.146.0 and OpenAI’s Codex CLI documentation on September 29, 2026. Crowsnest behaviour was checked against the released 0.3.1 application source on the same date. Codex changes quickly; codex resume --help on your own machine is authoritative.