Feature Request: Add `/archive` command to Codex CLI

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

• #13354

Powered by Codex Action

Potential duplicates detected. Please review them and close your issue if it is a duplicate. * Command for deleting conversation history #13354 _Powered by Codex Action_

My FR is closer to https://github.com/openai/codex/issues/8784. That is a FR for /delete, though. So a slight different taste. I think it's okay to merge these two FR or track and close them separately.

Analysis

Good news: the archive infrastructure already exists in the core layer. The gap is just the TUI slash command to trigger it.

What already exists:

• codex-rs/core/src/state_db.rs:152 has an archived_only: bool field for querying archived vs active sessions
• codex-rs/core/tests/suite/rollout_list_find.rs:208-213 shows archived_sessions directory usage and find_archived_thread_path_by_id_str for locating archived threads
• codex-rs/core/tests/suite/personality_migration.rs:39 has write_archived_session_with_user_event - showing the archive data format is established

What's missing:

• No Archive variant in the SlashCommand enum (codex-rs/tui/src/slash_command.rs)
• No command handler wiring to trigger archival from the TUI

Proposed Implementation

1. Add enum variant in slash_command.rs:

• Archive with description "archive the current conversation"
• available_during_task should return false (matches pattern of /new, /resume, /fork)

1. Command handler:

• Get current session/thread ID
• Move session from active to archived_sessions/ directory
• Update state DB archived flag
• Start a new session (similar to /new flow)
• Display confirmation

1. Consider /resume integration: Should /resume surface archived sessions in a separate section? This would allow un-archiving, which completes the feature.

This looks like a straightforward addition since the data layer already supports it. The Codex App and IDE extension likely use the same core archive APIs - this just surfaces them in the TUI. Happy to submit a PR if invited.

Happy to submit a PR if invited.

Me too, but they freeze non collaborator PR now IIRC.

https://github.com/openai/codex/blob/main/docs/contributing.md#contributing

If I understand correctly, for the TUI we are essentially talking about archiving removing items from codex resume. Are there other UX surfaces this would hit?

Beyond codex resume, here are the other UX surfaces:

1. Slash command dispatch - new /archive variant in SlashCommand enum (tui/src/slash_command.rs), with available_during_task returning false (matching /new, /resume, /fork)

1. Session picker - resume_picker.rs currently only shows active sessions. Archived sessions could surface in a separate section (or behind a flag) to support un-archiving. The SessionPickerAction enum would need an Archive variant.

1. Status line - brief feedback after archiving ("Session archived, starting new session") via the bottom pane status indicator

1. App event loop - new AppEvent::ArchiveSession variant (alongside NewSession, OpenResumePicker, ForkCurrentSession in app_event.rs)

The good news is the heavy lifting is already done. The app-server protocol already defines ThreadArchiveParams, ThreadUnarchiveParams, ThreadArchivedNotification, and ThreadUnarchivedNotification in protocol/v2.rs. There's even a full test suite at app-server/tests/suite/v2/thread_archive.rs that shows the archive flow (move rollout to archived_sessions/, emit notification, support re-resume). The state DB already filters on archived_only.

So TUI-side it's mostly wiring: slash command -> app event -> protocol call -> status feedback. The resume picker integration (showing/hiding archived sessions) is the only part that needs a UX decision.

@mvanhorn Dude, you rely on AI too much. This is exactly why OpenAI and so many FOSS projects refuse unsolicited PRs. Revise the AI slop and transform it to your own output before post. For example:

Status line - brief feedback after archiving

This is not how Codex TUI handle thread status change right now. For /compact and /fork, a command finish message is appended at the end of the (new) conversation, not "the bottom pane status indicator".

App event loop - new AppEvent::ArchiveSession variant

Why is this even mentioned when talking about UX?

I know your first comment is AI generated, too. So I only quoted the last paragraph you write by yourself. Please show some respect to other's effort and revise AI output before posting in this doomed AI era.

---

@kendonB I think it would be helpful to let users archive sessions from codex resume and maybe also provide an /archive command in the main chatting UI. For an /archive command it would be cool to redirect user to codex resume UI rather than exiting and prepend an "archived" message.

I have a working TUI implementation for this feature in a fork, but cannot open an upstream PR because this repository currently limits PR creation to collaborators.

Implementation artifact:

• Fork PR: https://github.com/MichaelSpece/codex/pull/2
• Commit: https://github.com/MichaelSpece/codex/commit/df0349fd3b61a251ac02b6220f5eb52def20437a
• Branch: MichaelSpece:codex/tui-archive-chats
• Validation: cargo test -p codex-tui archive

What the patch adds:

• /archive and /unarchive slash commands in the TUI.
• /archive <id-or-name> and /unarchive <id-or-name> direct targeting.
• Archive and unarchive picker modes using the app-server thread archive APIs.
• In-chat success/failure messages after archive operations.
• Focused slash-command and archive-picker tests.

I also verified the upstream compare page directly in the browser. The branch compares cleanly and shows the expected commit, but GitHub does not expose the Create Pull Request control for this account. The page states that repository owners have limited PR creation to collaborators.

Any interest in this from openai?

This will be included in the next release. I've added both an /archive slash command and a codex archive and codex unarchive command-line option.