Session archive is one-way: no unarchive tool and no Archived view in desktop

[BorrowedFire]

Summary

Archiving a session has no inverse exposed to either the assistant or the user, leaving archived sessions effectively orphaned.

Two related gaps:

1. MCP gap: mcp__ccd_session_mgmt__archive_session exists, but there is no unarchive_session. The assistant can put a session into the archived state but cannot take it out.
2. Desktop UI gap: the macOS desktop app's sidebar (Chat / Cowork / Code panels) has no Archived view, filter, or per-project toggle. Archived sessions are not visible anywhere in the sidebar I can find. "More" doesn't surface them either.

Repro

1. In the desktop app, archive a session (e.g. via auto-archive on PR merge, or by asking the assistant to archive).
2. Try to find it again from the sidebar — no Archived filter or section.
3. Ask the assistant to restore it. It can list_sessions({include_archived: true}) and search_session_transcripts to find the session ID, but there is no tool to flip isArchived back to false.
4. mcp__ccd_session_mgmt__send_message also rejects archived sessions with "Session ... is archived; unarchive it first." — pointing at an action that has no exposed path.

Workaround discovered

Editing the session JSON file directly (e.g. ~/.claude/.../local_<id>.json) and flipping isArchived: true → false restores the session. Quitting and reopening Claude Desktop refreshes the index. This works but is undocumented and requires file editing.

Suggested fixes

• Add mcp__ccd_session_mgmt__unarchive_session(session_id) symmetric with archive_session.
• Add an Archived view (or per-project filter) in the desktop sidebar with a restore action.
• Until then: when send_message / archive_session errors mention "unarchive," link or document the exact path.

Environment

• Claude Code desktop app (Mac), Opus 4.7
• macOS Darwin 25.5.0

[mcc42dev]

For anyone hitting this: there is an undiscovered workaround for unarchiving on desktop — right-click the session name in the chat pane and select "Unarchive." It works but is not documented anywhere obvious.

Related: filed #69457 which describes how the X button on home screen session cards (tooltip-labeled "Archive") leads to accidental archival due to the standard X-means-dismiss convention. The lack of a visible unarchive path compounds that issue.

[geokao]

Still reproduces on current builds — Claude Code 2.1.219, desktop app 1.24012.x, macOS Darwin 25.5.0 — so the stale label looks premature. Re-confirmed today (2026-07-26) by reading the live tool schema rather than inferring from a failed call: mcp__ccd_session_mgmt exposes archive_session and no unarchive_session.

Adding an angle I don't see raised here or in the adjacent session-management issues (#79126, #51831, #72468, #70006): this is not only a user-accident problem — the assistant can be granted standing authority to archive.

I run a session-hygiene rule that tells Claude to archive a session once its substance has been carried into my project files, without asking me each time. That's a reasonable grant on its own. But it means the agent holds a one-way action with no inverse anywhere on its own surface. Every other agent-facing action I've granted is either read-only or reversible by the agent itself; archive is the sole exception, and neither of us discovers that until the moment it matters.

The concrete incident, 2026-07-25: I archived a session by accident and asked Claude to bring it back. It could find the session (list_sessions({include_archived: true})) and read it, but had no way to restore it — so it had to work the recovery path out live and hand the click back to me.

Two things would close this, in priority order for me:

1. unarchive_session(session_id), symmetric with archive_session. This is the one that matters — an agent that can do X should be able to undo X.
2. Put the recovery path in the error text. send_message already says "unarchive it first" while pointing at an action with no exposed path; naming the right-click → Unarchive gesture right there would have saved the entire detour. (Thanks @mcc42dev — that workaround does work, and it is genuinely undiscoverable.)

One housekeeping question: this is labeled duplicate but without a pointer to the canonical issue. If there is one, could it be linked? This is the most complete statement of both halves I've found, and I'd rather add weight to the right thread than split it across two.

For what it's worth, the session-management surface is a genuinely good primitive — being able to list, search and read across past sessions from inside a session has changed how I work. That's exactly why the one missing inverse stands out.