Desktop: let a Code session start a normal new session with a prompt, model and effort, with no click
Where: Claude desktop app on Windows 11, Code tab, local sessions.
Problem
Every tool call re-sends the whole conversation, so long-running work gets expensive. The fix is a handoff: save state, then continue in a fresh session that starts small. In the terminal this is fully automatic (a script launches claude with the prompt). In the desktop app a session cannot start a normal session by itself:
mcp__ccd_session__spawn_taskmakes a chip, and the user must click it.- No
start_sessionorhand_off_to_sessiontool is exposed, although the descriptions ofdetach_session,stop_session,set_session_model,set_session_effort,open_session_inandlist_sessionsall refer to them (see also #99393). - Workaround found: an ad-hoc scheduled task started with
run_scheduled_task, thenset_session_modelandset_session_effort, thensend_message. It needs no click, but the new session is a "routine run". It shows only under Routines and cannot be moved, grouped, pinned or detached (move_sessionsanddetach_sessionrefuse it). It also needs a persistent routine, and two of them so a hop can start the next hop.
Request
Expose a tool, for example start_session, with these inputs:
prompt(first user message)modelandeffortcwdor worktree optionpermission_mode
It should create an ordinary top-level session in the sidebar under the same project, with no click. Approval can follow the existing rules: a model or effort above the caller's own asks the user first.
Why it matters
Automatic fresh-session handoff is the main way to control token cost on long tasks. Without it, desktop users either click each handoff or fall back to the terminal.
Verified
set_session_model and set_session_effort already work on a session created this way. Both apply from the next turn, so a created session should take them before its first turn.
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
The other half of an automatic handoff is what the fresh session reads first. Until a start_session tool exists, a file in the repo can carry it: the outgoing session writes what is done (with commit hashes), what is in flight and the next action, and a SessionStart hook prints it into the new session. Disclosure: I maintain Succession, a free MIT plugin that does the state part (it does not start sessions): https://github.com/thecontinuitylayer/succession
+1 from another Windows desktop user. My use case adds two things to this request:
I run one Orchestration session and control it from the Claude mobile app while gone during the day. The mobile app cannot create local sessions, so I created 20 blank sessions by hand at the desktop before I left. A start_session tool would let the Orchestrator create them on demand as needed, rather than having to pull from a pre-made pile of spare threads.
+1. Same need on Windows: Claude desktop 2.31226.1.0, Claude Code 2.1.296, several long-running Code sessions.
The desktop build already ships
start_session,hand_off_to_sessionandlist_start_targets(other ccd tools reference them), but our sessions only getspawn_task, and calls return "Starting sessions is not enabled here." No local setting controls it, so it looks like a remote feature gate (the desktop "side sessions" flag). Could this be enabled for accounts that ask, or made an opt-in setting?Workaround we use meanwhile, zero-click and native:
claude --bg --name "<title>" --model <model> --effort <level> "<short first prompt>"claude stop <id>claude --desktop --resume <session-id>(run from a real terminal; it refuses non-interactive output and a still-running bg session)The model carries over. It works, but a native
start_sessionwould remove three steps.