Clarify tracking for Codex local session deletion, retention, and cleanup UX

Open 💬 3 comments Opened Jun 14, 2026 by Aesthermortis

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

This issue is not intended to duplicate a single existing feature request. It is meant to clarify the tracking status for Codex local session deletion, retention, and cleanup UX.

Several related issues exist, but the current triage state is confusing because some issues have been closed while the user-facing problem appears unresolved.

Related issues:

#13018 — delete threads in the Codex app
#20251 — delete local threads and associated session data from the UI
#8784 — "codex delete <session>"
#6015 — configurable retention period for sessions

Problem

Codex stores local session/thread data, but users do not currently have a clear, discoverable workflow to answer:

What session/thread data is stored locally?
Where is it stored?
How can a specific session/thread be deleted?
How can archived or old sessions be deleted?
How can local logs/history/session artifacts be cleared?
How can retention be configured?
Which issue is the canonical tracking issue for this work?

This is not only a UI preference. It is also a local data hygiene, privacy, and trust issue.

Triage concern

#20251 was closed as a duplicate of #13018. However, #13018 is also closed, and it appears to cover a narrower request: deleting archived threads from the app UI.

#20251 covered a broader local data-management problem, including local session data, logs, history, storage discoverability, and retention controls.

If #13018 is considered the canonical issue, please clarify whether it was resolved, rejected, or moved to internal tracking.

If #6015 is now the canonical tracking issue for retention and cleanup, please link the related issues there and clarify the expected scope.

If none of the existing issues are canonical, please keep this issue open as the tracking issue or reopen the appropriate existing one.

Expected outcome

One of the following would resolve the triage ambiguity:

Reopen the canonical issue and mark related issues as duplicates of that open tracker.
Keep this issue open as the canonical tracker for local session deletion, retention, and cleanup UX.
Clearly state that this work is tracked internally and link or label the public issue accordingly.
Split the work into explicit sub-issues:

delete thread/session from UI
delete archived sessions
clear local logs/history
show/open local storage location
configure retention by age/count
disable future local transcript/session persistence

Why this matters

Manual deletion of internal files should not be the primary workflow for managing Codex local data.

Codex sessions can contain source code, file paths, diffs, commands, logs, project names, environment details, personal notes, and accidental secrets.

Users need a clear and supported way to manage that data without reverse-engineering internal storage folders.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#28095
#28166
#27741
#27717
#27207

Powered by Codex Action

Aesthermortis · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate. Archived chats show a Delete button, but deletion does not work #28095 Cold start scales badly with large ~/.codex state: 419 MB logs DB + 625 MB sessions cause 1–5 min startup on WSL2 #28166 Desktop launch can fail when logs_2.sqlite grows large: app-server SQLite pool times out during startup #27741 Feature request: view archived chat contents from Settings #27717 * Restore archived chats access from the main Codex UI #27207 _Powered by Codex Action_

Thanks. These are related, but this issue is intentionally about canonical tracking and triage ambiguity, not only the deletion workflow itself.

If #20230 is the intended canonical tracker, that would be a reasonable outcome. In that case, please link #13018, #20251, #8784, #6015, and this issue there, and clarify that #20230 covers local session deletion/cleanup/retention UX.

The main concern is that related issues have been closed as duplicates of closed or narrower issues, leaving no clear public tracker for the broader local data hygiene problem.

linerking · 1 month ago

Adding a current macOS/Codex Desktop data point for why archive is not enough as a local data-management workflow.

A user asked whether archiving threads prevents local or remote storage from continuing to grow. On the local machine, archive appears to be only a visibility/state change, not a storage cleanup mechanism.

Observed local ~/.codex sizes on 2026-07-05:

~/.codex total:              ~5.0G
~/.codex/sessions:           ~2.6G
~/.codex/logs_2.sqlite:      ~1.1G
~/.codex/generated_images:   ~233M
~/.codex/archived_sessions:  ~98M
sessions + archived_sessions files: 504

This reinforces the user-facing ambiguity:

Archive hides a thread, but it does not communicate that local transcript/log/image storage remains.
There is no obvious supported way to delete or purge old/archived session data from the app.
There is no visible retention policy by age/count/size.
Users cannot easily tell which local files are safe to remove without reverse-engineering ~/.codex internals.
It is also unclear what, if anything, archive does for remote/cloud-retained state.

Expected UX would ideally make the distinction explicit:

Archive = hide from normal sidebar/list, keep history and local data.
Delete = remove selected thread/session data, with confirmation and clear scope.
Purge old archived = bulk-delete archived sessions older than N days or over a size/count limit.
Clear diagnostics/logs = manage logs_*.sqlite separately from user transcripts.
Storage view = show local storage usage by category and open the local storage folder.

Without this, archive can look like cleanup while local data continues growing indefinitely.