Feature request: invocation-bound subprocess lifecycle with observed close

[flujo-app]

Use case

A desktop or server host supervising multiple Agent SDK queries needs to cancel a single original subprocess, await its actual closure, and keep cancellation available even when the message consumer stalls or stops reading. A cancellation request must be distinguishable from confirmed process exit before the host releases that query's resources or starts replacement work.

API reviewed

@anthropic-ai/claude-agent-sdk@0.3.220, bundled Claude Code 2.1.220, published TypeScript declarations: Query exposes interrupt() and close(): void. The caller-provided spawnClaudeCodeProcess option can supply a custom spawner, but users of the SDK-owned default process do not receive its original-child lifecycle through Query.

Requested capability

Please expose an invocation-bound lifecycle capability on each original Query, without requiring a replacement spawner or inspection of private transport fields:

1. Bind it to the SDK-owned child instance at spawn, with a stable in-process invocation identity and diagnostic PID; a PID or session ID alone is not proof of that original child.
2. Distinguish unstarted/spawn-failed, spawned, exited, and fully closed states, independently of message iteration.
3. Provide idempotent cancelAndWait() / closeAndWait() that target that exact child and settle only after observed terminal closure; a signal, interrupt() response, close() call, iterator completion, or cleanup timeout must not count as confirmed exit.
4. Support cancellation when the caller has never read the iterator, has a pending read, stalls after a message, or stops reading early; explicitly report unresolved or unknown terminal status when close cannot be observed.
5. Report unsupported for transports without a local subprocess. If a fresh liveness probe is provided, specify what it verifies and ensure it does not reconnect, reinitialize, or replay callbacks as a side effect.

Scope and validation

This is a public API feature request based on the pinned declarations, not a report of measured production failure or a claim that current methods promise the proposed contract. No Claude SDK source was copied or modified, no Claude binary was run for this request, and no paid model request was made. Related startup, interrupt, and session-close issues do not appear to expose a per-invocation observed-close capability.