Repository navigation
Feature request: Built-in session storage dashboard, backups, and safe bulk cleanup #38838
Description
What variant of Codex are you using?
CLI and App
What feature would you like to see?
Codex needs a supported session-storage control surface, not only single-session deletion.
On 2026-08-16, a privacy-safe scan of my Linux machine found:
- 938 local Codex sessions using 42,254,816,761 bytes (~39.4 GiB)
- 732 subagent sessions using 24,349,191,222 bytes (~22.7 GiB)
- one session file close to 9.5 GB
I would like Codex to provide both a built-in UI and a stable machine-readable CLI/API for:
- reporting total session storage and grouping it by project, source type, age, and size
- distinguishing main sessions, subagents, active writers, pinned sessions, and orphaned records
- exporting selected sessions before cleanup
- copying sessions while preserving the paths required for restoration
- safely deleting selected or filtered sessions in batches
- configuring global and per-session quotas or retention policies
- warning before session storage exhausts the disk
Suggested commands could include:
codex sessions list --json
codex sessions storage --json
codex sessions export <id...> --output <path>
codex sessions delete --ids-file <path> --force
codex sessions prune --older-than <duration> --source subagent --dry-run
The destructive path should re-check active writers and locks immediately before deletion, explain which resume data and associated artifacts will be removed, and fail closed if safety cannot be established.
I built a localhost-only prototype to test this workflow. It scans multiple CODEX_HOME roots, shows storage by project and source type, exports ZIP backups with a manifest, preserves provider-relative paths for migration, protects active/writer-locked/pinned/recent/unindexed sessions, and delegates Codex deletion to codex delete --force instead of unlinking JSONL files directly.
The prototype demonstrates the UX, but it still has to read internal SQLite and JSONL layouts. A supported listing/export/batch-delete interface would let external tools avoid depending on unstable internal storage details.
Additional information
Related issues:
- Insane Codex Disk Usage from Subagents #34061 documents extreme disk growth from subagent session logs.
- Clarify tracking for Codex local session deletion, retention, and cleanup UX #28187 tracks deletion, retention, and cleanup UX.
- "codex delete <session>" #8784 requested
codex delete <session>, which now addresses individual deletion but not discovery, backup, storage accounting, or safe bulk cleanup.
This request is specifically for a supported end-to-end session lifecycle interface shared by the CLI and App, including storage accounting, export/backup, and batch operations. It is broader than adding another delete button.
I have intentionally omitted transcript contents, project paths, usernames, and session IDs.
Activity
github-actions commentedon Aug 16, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Nan-WenYuan commentedon Sep 13, 2026
Adding feedback from a Windows Codex App user: project-level storage management is also needed when finishing and removing projects.
The Remove Project dialog explicitly says that local files and existing chats will not be deleted. That distinction is understandable, but there is no obvious end-to-end workflow to remove a finished project’s associated Codex data while preserving its source folder and all other active projects. Data is distributed across sessions, generated images, visualizations and shared databases, making manual cleanup difficult to reason about safely.
Requested UX:
During assistant-assisted cleanup through a separately launched app-server, stale sidebar entries were observed after the underlying tasks were deleted; opening an entry produced
no rollout found for thread id. This is specifically a cross-entry-point cleanup observation, not a confirmed reproduction using only the desktop UI. A supported cleanup workflow would avoid users having to inspect or repair internal indexes themselves.The main need is a clear project lifecycle: finish a project, review what will be retained or deleted, and reclaim its Codex-managed storage without touching current projects. Private project names, paths, session IDs, logs and screenshots are intentionally omitted.
shawnholt commentedon Sep 15, 2026
Lost many hours of work in Windows. Need backup and restore for reliability.
Vulcan-Approach commentedon Sep 30, 2026
Feature request: Unified storage visibility and cleanup across AI projects
I strongly support this request. I’m a godmode power user of ChatGPT on Windows, using Work and dot across multiple projects, and I’m creating disk clutter faster than I can clean it up.
I estimate I could be generating around 10 GB of clutter every three days. That’s an estimate, not a measured figure. I don’t have a reliable dashboard showing everything the AI creates or downloads, which is part of the problem.
Right now, I rely on ChatGPT to investigate what is no longer useful, find associated files and environments, check dependencies, and help me clean up. Doing that repeatedly is a pain in the butt. Cleanup becomes another project instead of a normal part of finishing work.
This issue and the project-lifecycle suggestions already posted here cover much of what I need. I’d like to emphasize the broader scope: local files, cloud workspaces, Library, conversations, generated artifacts and downloaded resources should all be understandable and manageable from one place.
What I want in practice:
1. Track everything from creation or download
Every generated or downloaded item should have a recorded owner: which project or conversation created it, why it exists, where it lives, its size and what still depends on it.
Include temporary files, build outputs, screenshots, logs, caches, virtual environments, dependencies, model downloads, backups and final deliverables. Clearly distinguish my original files from AI-generated copies and disposable supporting files.
2. Give me a live storage dashboard
Show storage by project, conversation, location and category, plus growth over time, large items, duplicates and likely cleanup candidates. Separate local disk usage from cloud storage.
Let me configure storage warnings and cleanup reminders. I want to know what is being produced while work happens, rather than discover later that my drive is full.
3. Support both fast cleanup and surgical cleanup
Sometimes I want to clean every finished project in one pass. Sometimes I want to remove only two files.
Give me filters for age, size, file type, location, project, conversation and usage status, with bulk selection and individual overrides. Don’t force me into one cleanup workflow.
4. Show a real preview before deletion
Show exactly what will be removed, why it appears unused, what depends on it and how much space can actually be recovered.
Let me choose recoverable deletion or permanent deletion without creating another backup behind my back. Explain any retention delay or location where permanent deletion is not available.
5. Protect active work without trapping old data forever
Never silently delete files or dependencies needed by a project that is still in use. Shared resources need protection.
But “still in use” must not become a permanent roadblock because I forgot to close an old conversation. Show me what is holding the dependency and let me explicitly retire that project or conversation, review the consequences, and remove the selected items together.
I want safety against accidents and the final say over my own data. If ownership or usage is uncertain, tell me instead of guessing.
6. Connect conversation cleanup to file cleanup
When I finish or delete a conversation, offer to review its associated data. Let me keep the final deliverables while removing temporary files, unused environments and other leftovers.
Show which files are shared with other projects. Deleting one conversation must not silently break another project, but it also shouldn’t leave a pile of forgotten data with no clear owner.
7. Make the result verifiable
After cleanup, report what was removed, retained, failed or is still pending deletion, and how much space was actually recovered. For anything that cannot be removed, show its location and the supported manual steps. Conversations should have current titles and usable links.
Related to that, my Windows app currently shows Archive but no Delete for cloud Work conversations, including after unarchiving. I’ve submitted feedback about that separately. A unified cleanup feature needs a clear, supported deletion lifecycle across these different storage locations.
The practical test for this feature would be simple: I finish a project, open its cleanup view, keep the useful deliverables, review shared dependencies, remove the rest, and see an honest result. Or I select several old projects and do the same thing in bulk.
As agents get faster and run more work in parallel, this problem will get worse. I don’t want to spend thousands on extra storage just to keep forgotten AI-generated data.
ChatGPT should know what it creates and downloads. Give me god-mode visibility and control over that data, with safeguards and explicit confirmation when cleanup could affect something else. Managing the mess should be built in.
v-49 commentedon Oct 16, 2026
Windows App use case: deleting a chat should offer a safe cleanup review of associated local data
Adding concrete Windows App evidence and the affected user's requested workflow, with their explicit authorization. This supports the existing request rather than opening a duplicate.
Read-only snapshot, October 16, 2026
26.1013.31256, build20586; MSIX package26.1013.3656.0; bundled engine0.163.0-alpha.10.2.The user's problem
The user has accumulated many conversations and reports that the delete-chat flow explains that local files are retained. The resulting uncertainty is: what owns those files once the conversation is gone, where can I find them, and how can I clean them without losing the useful deliverables?
Preserving user files is appropriate, but the product should also provide an optional, supported lifecycle for the data the agent creates while working. Users should not need an agent to reverse-engineer internal SQLite layouts and filesystem ownership each time they finish a task.
Requested behavior
The desired everyday workflow is: finish or delete a chat → review its associated data → keep the useful outputs → remove selected intermediates → see verified results.
The separate configuration/update-recovery discussion is #52747. These are distinct concerns; this feedback does not claim one causes the other.
Prepared with Codex assistance at the user's request. Only aggregated measurements are shared; no project paths, names, account/session identifiers, credentials, raw history or configuration are attached.
PabloJustDevelops commentedon Oct 17, 2026