[FEATURE] Allow -p sessions to appear in Claude Desktop sidebar (triggered remotely or via script)

Resolved 💬 3 comments Opened Apr 5, 2026 by thedug Closed May 26, 2026

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

Problem

Developers sometimes kick off Claude Code sessions from outside the terminal — via Slack, automation scripts, scheduled tasks, or mobile triggers — and then want to pick up that work later in the Claude Desktop app. Today there's no path from a remotely-triggered -p session to the Desktop UI. The session exists on disk but is invisible in Desktop, forcing users to manually track session IDs and resume via terminal.

My specific use case

I run a team of named agents, each in their own project subfolder. I trigger sessions from Slack — sending a task to an agent, letting it run, then wanting to open Desktop later to review the work and continue the conversation interactively. Today I have to track session IDs myself and resume via terminal, which breaks the Desktop-first workflow I use for interactive sessions.

The gap

The initiation and continuation surfaces are completely disconnected. Users who trigger sessions remotely must build their own session ID tracking infrastructure just to get back to work that should naturally appear alongside their other sessions.

Related issues that establish this gap:

  • #22723 — CLI sessions don't show in Desktop's "Local" filter (the bug version of this problem)
  • #10366 — Deep linking support requested for VS Code; this is the Desktop equivalent

Proposed Solution

Proposed solutions (in order of preference)

  1. --add-to-desktop flag for -p invocationsclaude -p "..." --add-to-desktop registers the session in the Claude Desktop session registry on completion, the same way /desktop does interactively. The flag name makes the destination explicit — this is specifically about adding the session to Desktop's registry, nothing else. Zero added friction for existing workflows that don't need it.
  1. claude-desktop://resume?session=<id> deep link — A dedicated URL scheme that opens a specific session directly in the Claude Desktop app. A single click from any linked surface — Slack, a log file, a script notification — would open the session in Desktop ready to continue interactively. This is distinct from the existing claude-cli:// scheme which targets terminal sessions.
  1. SessionEnd hook exposes a register-to-desktop mechanism — Allow hook scripts to emit a structured signal that registers the completed session in Desktop. This would let users build their own remote-trigger workflows without depending on undocumented registry formats or internal app state.

What this is NOT asking for

Live streaming -p output into the Desktop UI, or changing how interactive sessions work. Just discoverability after the fact — so remotely-triggered sessions can be named, resumed, and organized alongside interactive sessions in Desktop.

Alternative Solutions

Current workaround

A Stop hook that writes session metadata to an HTML log file with claude --resume <id> links and an osascript launcher that opens Terminal and runs /desktop automatically. It works but requires maintaining custom infrastructure for something that should be a first-class workflow.

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

_No response_

Additional Context

_No response_

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗