[FEATURE] Show routine (scheduled-task) sessions in the desktop session list

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

I run a long-lived session on my machine that watches our team's Slack for incoming feature
requests and bug reports. When one arrives, it should start a new session to do that work — one
request, one session, its own worktree. I then review each of those sessions myself by clicking
into it from the desktop sidebar: what was asked, what was done, does it need me.

Two properties are both required and neither is negotiable:

1. Starting a session must not require me to be present. Requests arrive while I am asleep or in

a meeting. A pipeline that pauses until I click is not a pipeline.

1. Every session must be a separate, openable entry in the desktop sidebar. That entry is my unit

of review. A session that runs but never appears there is work I cannot audit — which is worse
than work that never happened.

Today I have to choose one or the other. Every mechanism I can find gives exactly one half:

| Mechanism | Appears in desktop sidebar | Starts unattended | Agent can start it |
| --- | --- | --- | --- |
| mcp__ccd_session__spawn_task chip | yes | no — the click is the start | proposes only |
| Local routine / scheduled task (fireAt) | no | yes | yes |
| Agent / subagent tool | no — not a session | yes | yes |
| /fork, /bg, agent view | no | yes, once typed | no |
| A settings flag | — | — | nothing exists |

The closest thing to a solution is a local routine: it already fires with no click and opens a
real session that can edit files, run commands and commit. The autonomy I need already exists and
is already sanctioned. The blocker is only that its session does not show up where all my other
sessions are, so I cannot review it.

Proposed Solution

Show routine/scheduled-task runs in the project session list, grouped under the project they ran
in, alongside manually created and spawn_task sessions — ideally with a small marker indicating
the session came from a routine.

Clicking that entry should open the session exactly like any other: full transcript, ability to
answer a pending question, ability to keep working in it.

This adds no new autonomy. Creating a routine already requires an explicit approval that no
permission mode can waive, and each run already carries its own permission mode. The authority has
already been granted by the user; only the session's placement in the UI is missing.

Note the docs already describe this behaviour:

"When a task fires, you get a desktop notification and a new session appears under a Scheduled
section in the sidebar."
https://code.claude.com/docs/en/desktop-scheduled-tasks

In my testing that did not happen (details under Use Case Example). If that section is meant to be
the session list and simply is not appearing, this is a bug rather than a feature request — the
fix is the same either way.

Alternative Solutions

Things I tried, and why each fell short:

1. Local routine with fireAt — fires with no click, opens a working session, but the session never

appeared in the project session list. Tested twice; second run wrote to a path inside the
working directory, ruling out a permission stall as the cause. Reachable only via the separate
Routines page.

1. spawn_task chip — session appears correctly in the sidebar, but the click is what starts it, so

nothing happens while I am away. Chips also queue: with two pending, only the front one is
reachable (#70388).

1. Agent / subagent tool — starts immediately with no click, but is not a session at all: it never

appears in the sidebar and dies with its parent.

1. /fork, /bg, agent view — per the docs, background sessions do not appear in the Desktop sidebar,

and "No tool Claude calls itself. These are user-typed commands; Claude doesn't autonomously
dispatch new sessions." (https://code.claude.com/docs/en/agents)

1. A settings flag — nothing relevant in user, project, or local settings.json.

1. Automating the chip click with computer-use — correctly and permanently refused:

"Claude cannot be granted control of its own window: doing so would let you operate Claude's
own interface and change your own permissions, settings, and allowed behaviors. This can
never be granted."

I am not trying to route around that, including via the Accessibility API. A click that can
dismiss a task chip is the same click that can dismiss a permission dialog, and the boundary has
to sit in front of both.

An acceptable alternative to the proposal above would be a sanctioned, explicit opt-in for
spawn_task to start without a click — for example a spawn_task.autoStart setting or an allow-rule
scoped to a directory. Off by default, visible in settings, revocable, and chosen once by the user
rather than inferred. This is second choice: it touches a confirmation gate, whereas the proposal
above does not.

There is no workaround I am currently using. The pipeline is simply blocked.

Priority

High - Significant impact on productivity

Feature Category

Interactive mode (TUI)

Use Case Example

Step by step, what I want to happen:

1. A teammate posts in Slack: "the course list should separate archived courses into its own tab".
2. A long-lived session on my machine, polling Slack, picks it up at 3am while I am asleep.
3. It starts a new session for that one request, in its own git worktree, with a prompt describing

the change.

1. That session appears in my desktop sidebar under the project, titled after the request.
2. Three more requests arrive overnight. Each becomes its own sidebar entry.
3. In the morning I open each one, read what it did, run the tests, and accept or discard it

individually.

Steps 3 and 4 cannot both happen today. Using spawn_task, step 3 never fires at 3am because it
waits for my click. Using a routine, step 3 fires correctly but step 4 does not happen, so by
morning I have work that ran with no per-task entry to open and review.

What I tested, concretely:

• Created a one-time local routine with fireAt set two minutes out, notifyOnCompletion true.
• It fired on schedule with no interaction from me and opened a working session — confirmed in the

main pane.

• No "Scheduled" section appeared in the sidebar, and no new entry appeared under the project

group; the group still listed only my spawn_task sessions.

• Repeated the run with the output path inside the working directory to rule out a permission

stall. Same result.

Additional Context

Environment: Claude 1.30096.5, macOS 26.4.1, arm64.

Why I cannot solve this by batching several requests into one session: one request per session is
the point, not an implementation detail. Each needs its own worktree, its own transcript, and its
own accept-or-discard decision. Merging them gives up exactly the isolation and reviewability that
make an autonomous pipeline safe to run at all.

Related issues:

• #53494 — cloud-spawned tasks have no discoverable handle, invisible in desktop UI
• #70388 — queued background-task chips: only the front chip is reachable
• #67432 — sessions spawned via spawn_task chips start without external MCP servers until the first

user message

• #42286 — hooks triggered when Claude prompts for user input; a general-purpose outlet for this

class of problem