Skip to content

Customizable retention period for sessions #6015

Open

Description

@BobbyWang0120

What feature would you like to see?

I would like Codex CLI to periodically clean up old conversation history files based on a user-defined retention window. Currently, Codex retains every conversation indefinitely, so the history folder grows larger over time even though many of those conversations are no longer useful.

The proposed feature would allow users to specify a retention period (for example, 30 or 60 days), and Codex would automatically remove conversations older than that window. This would help keep the history directory at a manageable size and prevent storage from being consumed by outdated or irrelevant sessions. It would also be helpful if the retention duration were configurable so users could choose the period that best fits their needs.

Additional information

No response

Activity

  1. changed the title [-]Feature request: Automatically purge conversation history after a customizable retention period (e.g., 30-60 days)[/-] [+]Customizable retention period for sessions[/+] on Nov 15, 2025
  2. kt-devoss commented on Feb 11, 2026

    @kt-devoss

    +1

    Also, it would be great if retention could be configured per session, not only globally.

    In practice, I have different types of sessions:

    • one-off review requests or quick investigations that I’m fine with deleting very quickly (e.g., after 1 hour or a few hours; ideally configurable either at creation time or later, including “ephemeral” sessions that disappear soon),
    • and long-running sessions that I don’t want to be removed automatically.

    So it would be helpful to have:

    • a way to set a short retention/TTL when starting a session (or mark a session as ephemeral),
    • and a pin / keep option to prevent certain sessions from being cleaned up.

    Finally, I’d like the same capability not only in the CLI but also in the VS Code Extension, so retention/TTL and pinning can be managed consistently from both environments.

  3. mrexodia commented on Feb 25, 2026

    @mrexodia

    If you add this, please do not enable it by default.

  4. added
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    and removed
    agentIssues related to the core agent loop
    on Apr 11, 2026
  5. Ashwanisr commented on Apr 20, 2026

    @Ashwanisr

    Any plans to add this feature anytime soon? @etraut-openai

  6. kt-devoss commented on Apr 25, 2026

    @kt-devoss

    It would be great if it could be used not only in the CLI but also in apps and extensions.

  7. claell commented on Jul 25, 2026

    @claell

    Please make this opt-in, and never a silent default.

    As a data point for how this goes wrong: Claude Code ships exactly this feature with a 30-day default, hard unlink(), no consent prompt, no in-app way to view the setting or see what's about to be swept, and no restore path. The result is multiple open data-loss reports from users who lost months of history without ever knowing the mechanism existed — anthropics/claude-code#59248 and anthropics/claude-code#62476, both labelled data-loss by the maintainers.

    Disk pressure is a real problem and worth solving. But the fix for "my history folder is large" should not silently destroy other people's history. Concretely: default off; if enabled, an explicit prompt on first run; a dry-run mode; a visible next-sweep indicator; and delete to a trash/quarantine directory rather than straight to unlink().

  8. rodneyjoyce commented on Aug 3, 2026

    @rodneyjoyce

    I would also like to see this.

  9. ewzxyh commented on Aug 8, 2026

    @ewzxyh

    Adding an independent Windows Codex Desktop data point for the need for session retention and storage controls.

    On Windows 11 x64 with Codex Desktop build 26.803.5235.0, my local Codex directory reached approximately 398.8 GB, of which 396.5 GB was under sessions across 554 rollout-*.jsonl files. The C: drive reached 0 bytes free; the largest rollout was 9.37 GB.

    I had to manually delete 273 older rollout files to reclaim approximately 104.7 GB. Codex was still writing during the cleanup and added approximately 11.6 GB in a short interval.

    This makes an opt-in retention policy, a size/age report, compression/vacuuming, and a supported Desktop delete/archive workflow important. Any retention feature should preview the files, require confirmation, and provide a restore/backup path rather than silently deleting history.

  10. thnk2wn commented on Aug 26, 2026

    @thnk2wn

    Would love this as well. Ideally I'd love a global default with the ability to override per project. For example I have some misc script or daily standup type projects I only need maybe a week or two of history on but mission critical apps would prefer a longer retention. I'd love to not have to script something outside the app (or scheduled task within) to cleanup.

    Edit: Here's a workaround script where I have a daily archive scheduled task and a weekly cleanup:

    • bash {path}/codex-thread-cleanup.sh --archive --days 60 --execute
    • bash {path}/codex-thread-cleanup.sh --delete --days 90 --execute

    codex-thread-cleanup.sh

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestsessionIssues involving session (thread) management, resuming, forking, naming, archiving

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions