A session in Codex is not the repository's state, and they must not be confused. It stores the conversation transcript and the context of decisions made, but it does not replace git: the code history, collaboration and review live in version control, while the session is the task's working memory. Once this distinction is grasped, the session lifecycle operations stop being a mystery and are chosen by meaning: new, resume, fork, side, archive, delete and compaction - each has its own role, not just different buttons.
New and resume answer the question "continue or start over". /new opens a new chat in the same CLI process - this is for a new task in the same repository, when the previous context would only get in the way. /resume or codex resume continues a saved transcript - this is a return to a previous task with its decision history. Mixing them means either dragging extra context into new work or losing the needed one by starting from scratch where it was worth continuing.
Fork and side solve subtler branching tasks. Fork creates a separate line from an existing session - when you need to try an alternative path without losing the original. Side, as we saw, opens a temporary side chat for exploration without breaking the main transcript. The difference is in purpose: fork is a fork of the work itself, side is an exploratory question off to the side. A conscious choice between them keeps the history a set of clear lines rather than a dump.
Archive and delete manage what remains after a task. Archiving removes the session from the active list while keeping it; deletion removes it entirely. These are actions of different irreversibility, and they should not be confused: archive is for finished but potentially needed work, delete is for what will definitely not be needed. As with git, the important is better carried outward - into an issue, PR or docs - than relying on the needed transcript always being findable in the session list.
It helps to gather the lifecycle operations into a table once, to choose by meaning rather than by habit. Below is such a map: what happens on each operation and when to apply it. You return to it when work on a task stretches over several runs: clear session names and a conscious choice between continuing, branching and finishing turn the history from chaos into a set of named lines of work that are easy to return to.
Compaction is a separate mechanism with its own cost, and it is worth knowing in advance. When the history is long, Codex compresses it into a summary to free up context. But the summary may lose details that were not explicitly declared important. So after compaction it helps to ask Codex to restate the goal, constraints, decisions made and the next verification step - and make sure nothing critical dissolved. Compaction at a bad moment risks carrying off exactly the context the work was for.
| Operation | What happens | When to use |
|---|---|---|
| /new | A new chat in the same CLI process | A new task in the same repository |
| /resume, codex resume | Continuing a saved transcript | Return to a previous task |
| fork | A separate line from an existing session | Try an alternative path |
| /side | A temporary side chat | Exploration without spoiling the main transcript |
| archive | Remove from the active list, keeping it | Finished but potentially needed work |
| delete | Remove entirely | What will definitely not be needed |
| /compact | Compress the history into a summary | A long session at a natural boundary |
Session discipline comes down to a few habits. Give sessions clear names so resume finds the right one rather than sifting through nameless ones. End a logical task with /new rather than growing one history endlessly. Call /compact at a natural boundary, not in the middle of an unresolved incident. And carry the important result outward rather than keeping it only in the transcript. A session is working memory, not an archive; long-term history lives in git and the tracker.
The typical session failures are predictable. Confusing a session with the repository's state and relying on the transcript as a replacement for git. Starting a new task in the old context or, conversely, losing the needed one by starting from scratch. Compacting the history in the middle of an incident and losing details not declared important. And deleting what was worth archiving. Choose the operation by meaning, give sessions names and after compaction check that the goal and decisions are in place.