Sessions started from an assistant-suggested background task have no parent linkage, so findings get misrouted

Summary

When an assistant suggests a background task and the user starts it, the resulting session has no recorded link to the session that suggested it. There is no parent field on the session record, no notification back to the parent when the child finishes, and no way for either side to identify the other afterwards.

The consequence in practice is misrouted work: a child session that finishes with a finding has nowhere canonical to send it, so it messages whichever session id it happens to have seen — frequently a sibling that cannot act on the finding, while the session that actually commissioned the work never receives it.

This is adjacent to #48965 (multi-session coordination primitives) but narrower: that issue asks for coordination primitives, several of which now exist. This one is about the missing linkage that those primitives need in order to be routed correctly.

Current behaviour

1. Session A suggests a background task.
2. The user starts it. Session B is created.
3. Session B has no record that A exists. get_session exposes no parent/origin field.
4. Session A learns B exists only from a transient notice; afterwards it must enumerate sessions and guess by title, working directory, or start time.
5. When B finishes, nothing prompts it to report anywhere, and A receives no completion signal.

Why this matters more as sessions multiply

With one or two sessions a user can hold the graph in their head. With several running concurrently the coordination cost lands on the user, who ends up noticing things the tooling should — for example that one session's conclusions never reached the session that needed them. Cross-session messaging exists and works well; what is missing is knowing who to send to.

There is a related failure mode already filed in #74386, where a session cleaning up worktrees can destroy another session's uncommitted work because the only available signal is git state rather than liveness. Both issues share a root cause: sessions have no structured awareness of each other.

Proposal

In rough priority order:

1. Record the originating session id on any session created from an assistant-suggested background task, and expose it on the session record (get_session / session listing).
2. Notify the originating session on completion, in the same shape as a subagent completion notification.
3. Expose children to the parent — a way to list sessions spawned from this one, so a coordinating session can enumerate rather than infer.

(1) alone would resolve most of the misrouting, since it gives a child an unambiguous answer to "where do I report".

Related

• #48965 — multi-session coordination primitives
• #74386 — worktree cleanup discarding another session's in-progress work
• #83602 — attach an existing session as a teammate
• #77805 — expose session ID for reliable cross-session messaging
• #75474 — record source session id in teleported transcripts

Workaround

Naming the coordinating session explicitly in every task brief, with an instruction to report only there and never to sibling sessions. This works but is a convention held together by prompt text rather than a mechanism, and it depends on every brief remembering to include it.