[FEATURE] Let a spawned task declare it blocks its parent session, and report back when done — not every suggested task is a drive-by finding

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)

Priority: Medium
Feature Category: Other (Sessions / task orchestration)
Version: 2.1.218, Claude Desktop, Windows 11

Problem Statement

spawn_task has exactly one lifecycle model: fire-and-forget. The chip is created, Your current turn continues uninterrupted, and the spawned session never reports anything back. There is no relationship field on the tool, and no return path.

That model is correct for one of the two kinds of task Claude actually spawns, and wrong for the other:

Kind A — unrelated drive-by. While doing something else, Claude notices stale docs, dead config, a confirmed TODO. It has no bearing on what the parent session is trying to do. Fire-and-forget is exactly right here: nothing needs to come back, and the parent shouldn't be interrupted. This is the case the current design serves.

Kind B — blocking prerequisite. The parent session cannot finish its actual job until the spawned work lands. The child isn't a side note, it's a dependency that got discovered mid-task. This case has no support at all today.

Concretely, the shape that keeps happening: I ask the main session to upload an image. It turns out no MCP tool exists for that, so Claude spawns a task to add the upload tool to the MCP server. The main session is now parked on a subtask it created. When I go finish that subtask, the tool gets added — and then nothing connects the two. The parent has no idea its dependency is satisfied.

The workaround is that I become the message bus: I copy the child session's name, copy its final report (that last summary message effectively is a handoff report — it just has nowhere to go), and paste it into the parent session so it has enough context to resume the upload. Manual, lossy, and it scales badly — the more subtasks a session spawns, the more of them I'm hand-brokering.

Related but not the same ask: #71773 wants the parent to be able to identify/observe its children (spawnedBy, session id). That's the necessary primitive underneath this, but identification alone doesn't fix the handoff — even with a perfect handle, nothing pushes the result back or resumes the blocked work. #76681 covers a missing completion push as a bug; this is asking for the completion push to be a designed part of the dependency relationship.

Proposed Solution

Let a spawned task declare its relationship to the session that spawned it, and give dependent tasks a return path.

1. A relation field on spawn_task — e.g. relation: "independent" | "blocks-parent". Default independent, which is exactly today's behavior, so nothing regresses.

1. On completion, blocks-parent children report back. The child's final report gets pushed into the parent session as a first-class message — the same shape as an ordinary background task-notification, so the parent can just pick up where it left off ("upload tool now exists, retrying the upload"). This is the piece that removes the copy-paste entirely.

1. Nest dependent chips under their parent in the UI. A tree, not one flat global list. Independent chips stay top-level where they belong; blocking ones render under the session that's waiting on them. Even without any auto-resume, just a visible parent→child link plus a one-click "send this result to the parent session" button on the finished chip would kill the manual step.

1. Keep the human in the loop. I'd rather the parent surface "your subtask finished, continue?" than silently auto-start a turn. Confirm-to-resume is fine — the win is not having to reconstruct the context by hand, not the automation itself.

The distinction matters more than the exact mechanism: right now Claude has no way to express that a task it just spawned is something it's blocked on, so every task looks like a drive-by finding.

Alternative Solutions

• The Agent tool returns results to its caller, but it runs in-context and occupies the turn. Wrong fit for work that's a real side-quest I may want to run separately, on my own schedule, and interact with — and it produces no chip I can start when I choose.
• Cross-session messaging (send_message) technically exists, but it needs per-message confirmation (#79870) and the parent has no reliable handle on its own child (#71773), so I'm still the one brokering it.
• Manual copy-paste of the child's final report — what I do today.

Use Case Example

1. Main session: "upload this image to the store."
2. Claude finds there's no MCP tool that can do the upload, and spawns a chip: "Add an image-upload tool to the MCP server." Today this is indistinguishable from a drive-by cleanup suggestion.
3. I start the chip. It adds the tool, finishes, writes a perfectly good summary of what it built.
4. Today: I copy the session name and that summary, switch to the parent session, paste it in, and re-ask for the upload.
5. With this feature: the chip was spawned as blocks-parent, so its report lands in the parent automatically. The parent says "the upload tool exists now — want me to continue with the image?" and I say yes.

Additional Context

• Related: #71773 (parent→child lineage — the identification primitive this builds on), #76681 (completion push never delivered), #70388 (queued chips unreachable — another symptom of chips being modeled as a flat queue rather than a structure).
• dismiss_task already lets a chip be withdrawn when it goes stale, so chips aren't purely fire-and-forget in principle — there's already a notion of a chip's status mattering after creation. This asks for the other half: a chip whose completion matters to the session that created it.
• Nothing here needs to change the independent case. The request is additive: one more relationship type, for the tasks that already have a relationship in practice but no way to say so.