[FEATURE] Programmatically spawn multiple named child sessions that auto-start (no manual chip click) for routine fan-out

Status Open
Maintainer reply None cached
Activity 1 comment · opened Aug 26, 2026

Preflight Checklist

  • [x] I have searched existing requests and this exact feature hasn't been requested.
  • [x] This is a single feature request.

Priority: Medium–High
Feature Category: Sessions / subagent orchestration

Problem Statement

There is no primitive that is both auto-starting and a first-class, trackable sidebar session. A parent session or a scheduled routine that discovers N independent work items today has to pick one of two lossy options:

  • create_scheduled_task (fireAt) — starts unattended, but runs invisibly and completes off-screen. It never appears as a chat you can open, follow, or re-open. Not trackable.
  • spawn_task chips — become real, named, trackable sidebar chats, but each requires a manual click to launch. N items = N chips = N clicks; nothing auto-starts.

So a "triage → fan out" pattern (a routine reads a backlog, classifies it, and wants each fixable item to become its own named, self-driving chat) is impossible to do hands-off while keeping the per-item chats trackable. You either get invisible background runs, or a wall of chips to click through.

Concrete use case: a scheduled routine triages a support tracker and, for each code-fixable issue, wants to open a standalone chat named <category> - <short title> that runs to a terminal outcome on its own. A human later scans a tidy list of per-issue chats, follows any one, and re-opens it if needed. Today this needs one click per issue, or the runs aren't trackable.

Proposed Solution

A way to programmatically spawn one or more child sessions that auto-start without a manual chip click, where each child:

  1. appears in the sidebar as a named, first-class session (title settable by the spawner),
  2. starts automatically (opt-in — e.g. a autostart: true / mode: "auto" flag on spawn_task, or a batch spawn_sessions([...]) call), respecting the user's permission mode,
  3. runs independently (its own worktree/cwd), and
  4. reports completion back to the parent (the parent is notified and can resolve the child's session id).

An autostart flag on the existing spawn_task surface would be the smallest version. A batch variant would make routine fan-out clean.

Alternative Solutions

  • Keep chips manual but add a "Start all" / "Start all from this session" action so a routine's N chips can be launched in one click.
  • Make create_scheduled_task runs surface as openable sidebar sessions (retained transcript, re-openable), which would close the gap from the other direction.

Additional Context

Related but distinct open issues (this request is the missing auto-start piece that complements them):

  • #71773 — return a session id / expose spawn lineage so a parent can observe its children (observability, not auto-start).
  • #82788 — auto-assign spawned children to the parent's sidebar group (organization, not auto-start).
  • #82203 — "Threads": interactive, context-inheriting sub-conversations with merge-back (interactive exploration, not unattended fan-out).
  • #7706 (closed, not-planned) — auto-split a session on context-limit; different motivation and framing.

Comparable session-forking/fan-out has existed in other coding agents for a while; this request is specifically about making it auto-start + trackable in Claude Code.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗