[FEATURE] Session-as-process primitive: spawn, communicate, and terminate isolated sessions programmatically
Summary
Expose a first-class tool/API for spawning an isolated Claude Code session as a manageable subprocess — with stdin/stdout communication and PID-based lifecycle control — from within a running session.
Motivation
Today, parallel sessions require a human to open a new terminal and run claude manually. There is no programmatic way for a running session to:
- Spawn another isolated session (own context window, own shell state)
- Communicate with it (send prompts, read results via stdin/stdout or a structured channel)
- Terminate it (by PID or session ID)
This is a basic process-management primitive that the architecture already supports — sessions are already isolated processes with independent context windows. The missing piece is a clean spawn/communicate/kill contract exposed as a tool.
How this differs from existing primitives
| Primitive | Gap |
|---|---|
| Subagents (Agent tool) | Share the parent's context window and cwd. Not isolated sessions — they inherit the parent's CLAUDE.md, tools, and conversation history. |
| Agent Teams | Hierarchical (lead + teammates), shared task list. Models "many hands on one objective", not "hand off a discrete job and read the result." |
| Headless claude -p | Blocks the parent. No structured result-readback. Not presented as a supported tool. |
| #65456 (cross-project handoff) | Related but scoped to cross-directory handoff with different CLAUDE.md. This request is about the lower-level primitive: process lifecycle management for any session, same or different project. |
Proposed capability
A tool (e.g. SpawnSession) that:
- Starts a new
claudeprocess with its own context window and shell - Accepts: working directory (optional, defaults to current), initial prompt, model override, permission scope
- Returns: a session handle (PID or session ID)
- Provides:
SendToSession(handle, message)andReadFromSession(handle)for structured communication - Provides:
TerminateSession(handle)for cleanup - The spawned session runs asynchronously — the parent continues working while it runs
The key insight: sessions are already processes. The tool just needs to expose fork + pipe + kill semantics that the OS already provides, wrapped in a clean contract.
Use cases
- Parallel ticket work: spawn a session per ticket, each in its own worktree, coordinate from an orchestrator
- Review isolation: spawn a clean session for code review without context bleed from the implementation session
- Research + implementation: spawn a research session while continuing implementation, read findings when ready
- CI/automation: programmatically manage session lifecycles without human terminal management
Related
- #65456 — cross-project session handoff (higher-level, focuses on different-directory identity switching)
- #52051 — parallel session working tree conflicts (focuses on git isolation, not session lifecycle)
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗