Skip to content

Desktop: provide supported external/cold archive storage before local rollout history exhausts disk #37216

Open

Description

@jasonarend

Summary

Codex Desktop needs a supported way to move archived conversations to an external drive or cold-storage tier without deleting them and without breaking archive, resume, unarchive, search, or project history.

This is an urgent storage-management gap, not a request to hide chats.

User impact

On macOS, one active Codex Desktop profile currently has:

  • ~/.codex: 172 GiB
  • ~/.codex/archived_sessions: 147.97 GiB
  • 1,641 archived threads
  • only 30 GiB free on the internal SSD

The historical record is important across active projects, so UI deletion is not an acceptable remediation:

  • StackControl-related archived sessions: 129.61 GiB across 1,188 threads
  • Control Design System: 15.71 GiB across 26 threads
  • Other projects: 2.66 GiB

Many individual JSONL rollouts are multiple GiB. This grows while Codex is running.

Why current options are not viable

The documented UX supports archive and permanent deletion, but there is no documented retention policy, archive-size control, external archive location, or migration workflow.

Manual filesystem relocation is unsafe:

  1. The local state database stores rollout paths under ~/.codex/archived_sessions.
  2. Current archive code moves a live rollout using a filesystem rename from sessions to archived_sessions. Simply redirecting only the archive folder to another volume risks cross-device rename failures.
  3. Symlinking ~/.codex has known Desktop compatibility problems, and there is no supported guarantee for piecemeal rollout links.
  4. Deleting the files by hand risks leaving task metadata that points to unavailable history.

This leaves users facing an unreasonable choice: sacrifice durable project history or let Codex consume the internal drive.

Requested capability

Please add a first-class external/cold archive storage feature for Desktop and CLI. For example:

  • configurable archive target (archive_storage_path / CODEX_ARCHIVE_HOME) with a Desktop migration wizard;
  • a safe cross-volume migration implementation: copy to a staged destination, verify size/checksum and durability, update state atomically, then remove the source;
  • a visible dry run, storage report, rollback path, and target-space/preflight checks;
  • keep archived conversations fully reopenable/unarchivable/searchable while the archive volume is mounted;
  • clear, non-destructive unavailable-volume behavior when it is not mounted;
  • optional retention rules such as “offload archived chats older than N days”;
  • optional compression and archive-by-project views;
  • a supported export/import or restore path independent of undocumented SQLite/path surgery.

The migration must preserve thread IDs, project association, descendant/subagent lineage, and any history references.

Expected outcome

Users should be able to retain years of project history on encrypted external storage while keeping Codex’s local control plane lightweight. “Archive” should mean durable, accessible retention—not a path toward forced deletion.

I can provide a sanitized inventory and reproduction details if that would help triage.

Activity

  1. added
    enhancementNew feature or request
    appIssues related to the Codex desktop app
    CLIIssues related to the Codex CLI
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    configIssues involving config.toml, config keys, config merging, or config updates
    on Aug 6, 2026
  2. github-actions commented on Aug 6, 2026

    @github-actions
    Contributor
  3. jsegeren commented on Sep 19, 2026

    @jsegeren

    Strongly agree with the need, but I would avoid making a cloud-synced directory the live mutable Codex data directory. SQLite databases and partially synchronized rollout files can produce inconsistent state if another process or device observes them mid-write.

    A safer model is scheduled, versioned snapshots to a user-selected destination, with verification, retention controls, search, export, and an explicit restore operation. The destination can be local storage or a folder managed by OneDrive, Google Drive, Dropbox, iCloud Drive, or another backup system without making that provider the live Codex data authority.

    I built that model into Codex Vault for macOS: automatic or manual backups, daily by default, destination-awareness, conversation search, export, and restore:

    https://migrate.segeren.com/codex-vault

    Disclosure: I maintain it; it is an independent tool rather than an OpenAI feature. I would still welcome native archival support in Codex because local task history is valuable data and should not depend on one mutable local copy.

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

    CLIIssues related to the Codex CLIappIssues related to the Codex desktop appconfigIssues involving config.toml, config keys, config merging, or config updatesenhancementNew 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