[FEATURE] Session-as-process primitive: spawn, communicate, and terminate isolated sessions programmatically

Open 💬 3 comments Opened Jun 17, 2026 by nzaytsev

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:

  1. Spawn another isolated session (own context window, own shell state)
  2. Communicate with it (send prompts, read results via stdin/stdout or a structured channel)
  3. 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 claude process 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) and ReadFromSession(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)

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗