[FEATURE] Scheduled task runs are isolated sessions with no shared context — let the main agent own the schedule

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

Every scheduled task run spawns an independent session that knows nothing about any other session, including the main session that created the task. In practice this makes recurring work unmanageable.

I set up an hourly monitoring task. Over a day it produced more than ten separate sessions. Each one had no memory of the conversation that created it, no awareness that the other runs existed, and no visibility into instructions or corrections I had given in a different session. When I adjusted the task's behaviour from inside one session, nothing else knew about it. Reviewing what the task had actually done meant opening sessions one at a time.

The docs state each run "starts fresh with no memory of this conversation", so I understand the isolation is intentional. But the consequence is that everything a coordinator would naturally hold — accumulated context, corrections, state — has to be manually serialised to disk and re-taught to every run.

I ended up deleting all my scheduled tasks and going back to running the work by hand once a day. The feature cost me more to manage than it saved.

Proposed Solution

Let the main agent own the schedule. The main agent understands the intent, holds the accumulated context, and dispatches the individual runs. Corrections given to the main agent apply to subsequent runs automatically, because the instructions live in one place instead of being copied into a standalone prompt.

If full main-agent-mediated scheduling isn't feasible, any one of these would substantially reduce the pain, roughly in order of preference:

Scheduled runs inherit context from the session that created them, instead of starting blank
One durable task session that is resumed on each fire, rather than a new session per fire
A way to list and read what past runs of a task actually did, without opening each session individually
A minimal cross-run coordination primitive — at least "another run of this task is already in flight"

Alternative Solutions

I implemented the documented workaround: keep all state on disk and have every run re-read it. A JSON file for counters and a dedup ledger, a markdown file for the run log, and a runbook describing the procedure.

It works, but it is a patch rather than a design:

Every run needs a self-contained prompt re-explaining context the main session already had. For a fairly simple recurring task, that prompt grew to several hundred lines, most of which was re-teaching things I had already told the main agent.
There is no cross-run coordination primitive at all. A run cannot tell whether another run is in flight, there is no lock, and concurrent writes to the shared state file have no reconciliation path.
Knowledge learned during a run (a new API quirk, a corrected heuristic) has nowhere to go except back into the prompt by hand.
I have since abandoned scheduled tasks entirely and moved the work back to a manual once-a-day invocation, with the procedure written into a runbook file in the repo. That is strictly worse than automation, but cheaper than managing the session sprawl.

Priority

High - Significant impact on productivity

Feature Category

Other

Use Case Example

Concrete scenario, from the task I actually built:

In my main session I work out a scanning procedure with Claude — which sources to check, what selection criteria to apply, several API quirks we discovered by trial and error.
I ask for it to run hourly. Because the run gets no context, the entire procedure has to be re-written as a standalone prompt. It ends up several hundred lines long.
Mid-day I notice one of the selection criteria is wrong and tell Claude in my main session. That correction is invisible to every scheduled run — I have to edit the task prompt separately.
The task has now produced a dozen sessions. To find out what it actually did, I open them one by one.
A run discovers a new quirk. There is nowhere for that knowledge to live except a file I have to update by hand.
With main-agent-mediated scheduling, steps 2 through 5 mostly disappear: I describe the job once, corrections land in one place, and I ask the main agent what the runs have been doing.

Additional Context

This is about the scheduled tasks feature (tasks stored under ~/.claude/scheduled-tasks/<id>/SKILL.md, dispatched via the scheduled-tasks MCP server).

Not a duplicate: this is distinct from the process-leak reports (#89205, #88982, #80885) and the unattended-permission hang (#86915). Those are bugs in how runs terminate — orphaned processes, sessions that never exit, runs that block forever on a permission prompt. This request is about the model itself: even when every run exits cleanly, N isolated sessions with no shared context is the wrong shape for recurring work.

I likely hit some of those bugs too — a single hourly task accumulating more than ten sessions in a day is consistent with runs not terminating — but fixing termination would not address what I'm describing here.

Environment: Claude Code 2.1.222, macOS (Darwin 25.5.0). Recurring hourly cron tasks plus one-time fireAt tasks.