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

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:

1. Reopen the canonical issue and mark related issues as duplicates of that open tracker.
2. Keep this issue open as the canonical tracker for local session deletion, retention, and cleanup UX.
3. Clearly state that this work is tracked internally and link or label the public issue accordingly.
4. 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.