[FEATURE] VS Code extension: archive/unarchive sessions and an Archived view, alongside Rename and Delete

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

The session list in the VS Code extension sidebar offers exactly two per-row actions on hover: a pencil (rename) and a trash can (delete). There is no archive.

Prior requests exist and are all closed: #63705 and #43132 were closed by bot (duplicate and inactivity) and are now locked, so neither can be commented on. Rationale for refiling is the first line of Additional Context.

That leaves one lever for two different intentions. "I never want this again" and "this work is finished, get it out of my way" both have to be expressed as Delete. Delete does not appear to destroy the transcript (see the implementation note below), but it is one-way in the UI: no undo, no restore, and no view of removed sessions. So a finished session is either hidden irreversibly, as far as the extension is concerned, or left in the list forever. With many parallel sessions, finished rows accumulate quickly, at which point the default list stops being navigable and text search is the only way through it.

Archive is the standard answer: clear the row out of the default list, keep the transcript, keep the session resumable, and allow it back.

Proposed Solution

Scope: the Local session list. Web sessions already carry an archived state server-side and are covered by #84083; aligning the two later is fine, but this request is the local list.

Add archive as a distinct action.

1. Per-row Archive action. A third always-visible hover icon would crowd an already-truncating row, so an overflow menu collecting Rename, Archive and Delete may fit better, but the placement is yours.
2. A way to see archived sessions. Either an entry beside the existing Local and Web tabs, or a filter in the search row. Labeled text rather than an unlabeled icon would help here, and it should be reachable without knowing the session title: the desktop app's archived view has open discoverability complaints on exactly that point (#74018, #83084).
3. Unarchive from that view, returning the session to the normal list.
4. Archive stays non-destructive: transcript retained, session still resumable, and Delete keeps its current meaning, so the destructive and the tidy-up intents stop sharing a button. Archive here means only: remove the row from the default list, keep the transcript, allow restore. It does not need to stop the session's work or clean up a worktree, which is what the desktop app's archiving is documented as doing.

Alternative Solutions

• Pin, sort, or group (open umbrella #80099). Useful, but it reorders a long list rather than shortening it; finished sessions still occupy it. If you would rather track one lifecycle issue than two, folding this into #80099 as its archive component is fine by me -- the ask is that archive, unarchive and an archived view exist somewhere, not that they have their own issue.
• Make Delete recoverable (undo toast, or a trash view). Closer than it sounds, given the implementation note below, but it keeps the two intentions conflated, and "archive" is the clearer vocabulary for the common case.
• Search only. Already available, but it requires remembering a title and does nothing to keep the default list short.
• A user-side workaround. None for the restore half. Delete already performs the hide, but the extension contributes no command that lists or restores hidden sessions, and the hidden-id list lives in extension global state, so no keybinding, task, or command-palette route reaches it. (The nearest-named command, Reopen Closed Session, reopens a recently closed panel and does not touch hidden sessions.)

Priority

Medium - Would be very helpful

Feature Category

Other

Use Case Example

I work across several repositories and routinely have a dozen or so sessions open or recently used at once: a few active, the rest finished. Today, clearing the finished ones means Delete, which is one-way in the UI with no restore and no view of what was removed, so they get kept instead. Within a week the sidebar is a long undifferentiated list in which the three sessions that matter are indistinguishable from the twenty that are done.

With archive the flow is: finish a piece of work, archive the row, and the default list shows live work only. If that work needs a second look a week later, open the archived view and unarchive it.

Additional Context

Filing fresh because the two closest requests (#63705, #43132) are closed and locked, and both closures were bot actions rather than decisions on the merits; the locked-issue notice itself asks that a new issue be filed referencing the old one. The one open request on this surface, #80099, asks for pin, a settable Active/Done state and grouping; this is narrower and complementary.

Parity, stated precisely. Anthropic's desktop documentation (https://code.claude.com/docs/en/desktop) says that to remove a worktree when you are done you "hover over the session in the sidebar and click the archive icon" -- so the affordance there is a hover icon on a sidebar row, though the documented purpose in that line is worktree cleanup. The same page establishes that archive is non-destructive: it says Claude skips archived sessions unless you ask for them, and that a message cannot be delivered to an archived session, so an archived session persists as a distinct state rather than being removed. That page never uses the word unarchive and does not name an Archived view, and the tracker evidence conflicts: #30869 ("Unarchive Claude Code sessions in desktop app option") is closed as completed, while #67835 is open and reports desktop archive is still one-way with no Archived view, and #83084 describes the desktop archived filter as an existing but unlabeled icon. I am not claiming the restore half is finished anywhere, and I have not inspected the desktop UI myself; I am asking for archive plus a way back on this surface.

Per https://code.claude.com/docs/en/sessions the desktop app, the web, and the VS Code extension each maintain their own session history. This is therefore a comparable feature on a separate surface, not a missing button on a shared list.

Implementation note, read from the shipped bundle rather than observed on disk. In the extension bundle the delete request handler appends the session id to a persisted hidden-session list, and the session listing filters that set out; no transcript file appears to be removed on that path. I have not confirmed it by comparing a transcript file before and after a delete, so treat it as a hint. If it holds, the persistence and list-filtering an archive feature needs already exist, and what is missing is a restore path (nothing removes an id from that list), a view of hidden sessions, and separating archive from delete. (#84083 contains its own reading of the same bundle, for the remote path.)

Related, for triage, not duplicates.

• #63705 "[FEATURE] Archive (hide-but-keep) chat sessions in VS Code sidebar" -- closest prior art. Auto-closed by the duplicate bot onto #63586, a Claude consumer-app request rather than a Code-tab one. #63705 itself is now locked, so it cannot be commented on.
• #43132 "Feature Request: Archive/pin sessions in VS Code sidebar" -- auto-closed for inactivity with no human comment; also locked.
• #65716 -- bundles archiving with other asks; auto-closed onto #49824, a delete-button bug.
• #80099 "[FEATURE] VSCode session lifecycle: pin + active/done state + grouping" -- open, same surface; differentiation above.
• #84083 -- open bug: the extension's Web section lists cloud sessions that are archived server-side. That report finds the extension discards the status field and states the extension has no concept of archival anywhere in its session-listing path, which is the same gap this request is about, on the remote half.
• #70380 -- open, same mechanic (hide plus a filter), on a different surface.

If an auto-archive preference ever comes to the extension, matching the semantics of the desktop's (named there "Auto-archive after PR merge or close", scoped to local sessions that have finished running) would help. That is a follow-up, not this request.

Environment. Claude Code VS Code extension 2.1.222 (win32-x64); VS Code 1.131.0; Windows 11. Still absent in 2.1.222, so this is not moot.

(The form has no IDE or editor-extension category. This targets the VS Code extension session list; suggested labels: area:vscode, platform:vscode, area:ide.)