Add a first-class workflow for reviewing and clearing old CLI sessions

Open 💬 2 comments Opened Apr 29, 2026 by pmetzger

What variant of Codex are you using?

CLI

What feature would you like to see?

Add a first-class workflow for reviewing and clearing old CLI sessions

Codex CLI currently makes it easy to resume previous sessions, but there does not appear to be an equally clear workflow for clearing out sessions that are no longer useful.

Over time, ~/.codex/sessions accumulates many old session transcripts. Some are valuable because they preserve context for active work, but many are one-off experiments, abandoned attempts, or sessions tied to branches and directories that no longer matter. Right now, deciding what is safe to delete seems to require manually inspecting raw JSONL files, grepping for repo paths or branch names, and then deleting files by hand. That feels fragile and easy to get wrong.

The main problem is not disk usage alone. It is that old sessions become operational clutter:

  • codex resume --all becomes harder to scan.
  • It is difficult to distinguish active, useful sessions from stale ones.
  • There is no obvious way to tell which sessions are tied to current work versus obsolete branches or temporary directories.
  • Users who want to clean up must reason about internal storage layout rather than using the CLI.
  • Deleting raw files directly feels unsupported, even if it works in practice.

It would be helpful for Codex CLI to provide an intentional workflow for session cleanup, comparable in polish to the resume workflow. Ideally, a user should be able to review old sessions with enough context to decide whether they are still useful, then remove the ones they no longer care about without manually operating on files under ~/.codex.

The workflow should support the core user question: “Which of these sessions are still relevant to active work, and which can I safely remove?”

Useful context during review would include things like the working directory, last activity date and time, session summary/title if available, session size, git repository and branch the session was running on, etc. The important part is not the exact UI, but that users should not have to open raw transcripts to answer basic cleanup questions.

This would make long-term CLI usage feel much healthier. Session history is valuable when it is curated, but without a cleanup path it gradually turns into noise. A first-class cleanup workflow would also make users more comfortable relying on session persistence, because they would know there is a supported way to manage it later.

Additional information

_No response_

View original on GitHub ↗

2 Comments

LeeeeTX · 3 months ago

We built a small open-source macOS tool for managing local Codex App/CLI conversation history:

https://github.com/LeeeeTX/codex-history-cleaner

It provides a terminal UI to list, search, preview, and delete local Codex sessions from ~/.codex. Deletion is recoverable by default with backups, and permanent deletion is also available with an extra confirmation step.

Hope this is useful for anyone who wants local controls for Codex history cleanup.

islandpreneur007 · 3 months ago

+1 on this from a production VPS deployment perspective.

We run codex-cli on a long-lived Ubuntu VPS as part of a multi-agent governance system. Current state:

  • ~/.codex/sessions = 335M accumulated rollouts.
  • Newest rollout is more than 3 weeks old (post-2026-04-19 cutoff under our current operating model).
  • All rollouts are from pre-migration agent sessions that are no longer relevant to active work.

We have a substrate-discipline rule in our governance docs that forbids manual purging of native tool state directories when no documented native cleanup surface exists — manual rm-ing files under ~/.codex/sessions/ is treated as a Frankenstein anti-pattern because:

  1. There is no guarantee that the codex-cli internal state machine tolerates removal of arbitrary rollout files (data-loss risk like #21196 / #19480).
  2. We cannot script a safe cleanup policy without knowing which files codex-cli's internal index considers "live" vs "orphaned".
  3. A future codex-cli version might depend on retention semantics that aren't documented.

This means a piece of operational work in our governance roadmap — "codex-home tier cleanup" — is currently PARKED indefinitely. We would rather wait for a native CLI cleanup surface than risk corrupting state.

The author's proposal — a first-class review/cleanup workflow with metadata (cwd, last activity, repo/branch, size) — would fully unblock this. Even a minimal codex sessions list --older-than 30d --json + codex sessions delete <id> pair would be enough for us to write a safe age-based retention policy.

If the maintainers want to track concrete deployment data for prioritization: we are happy to share aggregate metrics (rollout count, total size, age distribution) from our production directory.