Add /resume (session resume) to desktop app
Status Fixed / completed
Maintainer reply None cached
Activity 7 comments · opened Apr 17, 2026 · closed Aug 17, 2026
Summary
The CLI supports resuming prior sessions via claude --resume / claude --continue / /resume, but the desktop app has no equivalent. There's no /resume slash command and no session picker UI.
Request
Bring session resume to the desktop app at parity with the CLI:
/resumeslash command, or- A session history picker (list prior sessions, select to resume with full context)
- Support for
--continueequivalent (resume most recent session in the current working directory)
Why
- CLI and desktop currently diverge on a core workflow feature.
- Users who switch between CLI and desktop lose the ability to pick up prior work when in the desktop app.
- Session history already appears to be saved — exposing it in the UI should be mostly a surfacing problem.
Environment
- Claude Code desktop app (latest)
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Found 1 possible duplicate issue:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
+1 — also covers the broader case of any CLI session (not just
-p/scripted): the JSONL files at~/.claude/projects/<slug>/<session-id>.jsonlare invisible to the desktop app's sidebar. Having the app read that directory would let users move between terminal and desktop without losing history.Related gap from a different angle: I've got an MCP tool that full-text searches session transcript content (the built-in picker/session list only matches the auto-generated title, so anything not literally in the title — a ticket ID, error string, filename — never surfaces). It reliably finds the right session, but there's then no way to actually open it: the tool can hand back a session UUID and title, but nothing turns that into something clickable or resumable.
Same underlying gap as the /resume ask above — a session picker (or a UUID-addressable resume) would close it either way. Worth noting there's a search/discovery use case here too, not just CLI/desktop parity: anything that surfaces a session ID programmatically (MCP tools, logs, scripts) currently has no way to hand it back to the user as something they can click into.
(Started on the near-duplicate #50345, which auto-closed/locked as a dupe before I could post — landing this here instead per its own bot comment.)