Cloud-spawned tasks have no discoverable handle — invisible in desktop UI, unstoppable from agent

Summary

A task spawned via mcp__ccd_session__spawn_task and started by the user becomes invisible: it does not appear anywhere in the desktop client, the spawning agent has no way to list it to obtain a task_id, and the documented /tasks slash command is not available in the environment. The task runs to completion silently and there is no path to inspect or stop it.

Environment

• Claude Code desktop client
• Agent session with mcp__ccd_session__spawn_task exposed
• TaskStop exposed to the agent (but no list_tasks equivalent)
• /tasks slash command not available in this environment

Repro

1. In an active session, the agent calls mcp__ccd_session__spawn_task with title, prompt, tldr. A chip appears in the UI.
2. User clicks the chip — task spawns to a fresh worktree.
3. After spawn, the task is not visible in the desktop client. No entry in any session list, no panel, no chip remains.
4. Agent has TaskStop available but no list_tasks / list_spawned_tasks tool, so it cannot obtain the task_id required by TaskStop.
5. User runs /tasks — returns "/tasks isn't available in this environment."

Net effect

A task can be created that neither the human nor the agent that created it can locate, inspect, or stop. It runs silently to completion (or failure). If it touches a shared branch it can block subsequent local work in the same repo without warning.

Minimum fix (any one would unblock the user)

1. Surface spawned tasks in the desktop session list with status, branch, and a stop control. (preferred — matches user mental model that a click-to-spawn action is reversible by another click)
2. Expose a list_spawned_tasks tool to the agent that spawned them, returning at least task_id, title, status, branch. Pairs with the existing TaskStop.
3. Wire /tasks into the environments where mcp__ccd_session__spawn_task is available, so the documented handle actually works.

Related observation

The TaskOutput tool description tells agents that "Task IDs can be found using the /tasks command". This reinforces that /tasks is the documented handle, so its absence here reads as a wiring gap rather than an intentional omission.

Why this matters

Spawning a task is a single click. The cleanup path needs to be at least as accessible as the creation path. Today there is no cleanup path once the chip is gone.