subagent: a continuable child of a non-continuation parent is owned by nothing, and outlives the parent unheard

[nokkies]

Raising this as a question about intended ownership rather than a defect claim, because the individual behaviours are each documented and the gap is in how they compose. I was not able to demonstrate it at runtime — see the last section — so this is a structural argument plus a reachability check.

The composition

startContinuable accepts any live Agent as parent, with no gate on whether that parent is continuation-managed. Ownership is then acquired like this:

private acquireOwnership(parent: Agent, childId: SessionId): void {
  const parentActivation = this.activations.get(parent.id)
  if (parentActivation === undefined) return
  ...
  parentActivation.ownedChildren.add(childId)
}

The early return is deliberate and its JSDoc says so: a top-level or otherwise non-continuation agent "has no Activation and stays outside the waiting graph". Likewise notifySettlement documents dropping the notice when the parent is no longer live: "A parent that is no longer live is not an error; the child's own Session remains the durable record either way."

Both are reasonable in isolation. Composed, they describe a child that nothing owns and whose settlement nothing hears.

Why it looks reachable in the shipped preset

apps/cli/config/agent-presets/standard/agent.cordis.yml composes both subagent tools with backgroundMode: continuable and no maxDepth (default 3), and a child inherits the same composition through applyChildComposition. So:

1. The root calls subagent with run_in_background: false — which is exactly what the tool description recommends when the next action depends on the result. That child is one-shot, and has no Activation.
2. That child calls subagent on the default background route, so the manager materializes a continuable grandchild.
3. acquireOwnership early-returns, because the one-shot parent has no Activation. Nothing owns the grandchild.
4. The one-shot child settles and disposes. The grandchild's Activation was created under the manager's own owner scope, so the parent's disposal touches nothing.

The grandchild then keeps running model turns — billed, doing work — until it finishes on its own or app teardown cancels it, and its settlement notice is dropped because the parent is no longer registered.

The agent/disposed listener closes the scope but does not drain the disposed agent's continuable descendants, and drainDescendants is only reached for the host's top-level agents via the ACP bridge. Once the intermediate parent is gone, liveLineage cannot climb through it, so a later drain no longer sees that subtree.

What I could not establish

I did not get a runtime reproduction. agentLoop.create() returns the Agent and discards the disposer — the owned handle is a separate capability — so disposing a parent mid-flight needs more scaffolding than the existing continuation tests carry, and I did not want to assert a leak I had only reasoned about. If someone with that harness closer to hand can dispose the parent and check whether the child's Activation survives, that settles it either way in a few lines.

The questions

1. Is a non-continuation parent starting a continuable child intended to be supported, or should startContinuable refuse it? Note the existing tests use a plain agentLoop.create parent, so refusing would change what they exercise.
2. If it is supported, should agent/disposed drain the disposed agent's continuable descendants rather than only closing the scope?

Not proposing a patch: both answers change ownership semantics, and picking one from outside is guesswork.

[argszero]

Verified the structural argument against b150a551b8 — every claim checks out, and the reachability through the shipped preset is real. The composition is exactly as you describe: apps/cli/config/agent-presets/standard/agent.cordis.yml sets backgroundMode: continuable on both subagent tools (:191, :198) while also shipping one-shot variants (:210, :219), and children inherit the composition — so a one-shot child of the root, spawned the way the tool description recommends when the next step depends on the result, can indeed materialize a continuable grandchild that nothing owns.

Confirmed at source

1. acquireOwnership (continuation.ts:1162-1174): early-returns when parentActivation === undefined; JSDoc confirms "A top-level or other non-continuation Agent has no Activation and stays outside the waiting graph." No ownership edge, no refusal.
2. notifySettlement (continuation.ts:1462+): const parent = this.ctx.agents.get(activation.parentSession); if (parent === undefined) return — the settlement notice is silently dropped once the parent is gone.
3. agent/disposed (continuation.ts:385-386): only this.closingScopes.delete(agent) — scope cleanup, no descendant drain.
4. liveLineage (continuation.ts:881-891): climbs agent.session.header.parentSession, but breaks at the first unresolvable parent — a disposed one-shot parent is exactly that wall. So your "a later drain no longer sees that subtree" claim is precise.

The gap is a sibling of the orphan-tree class this repo already tracks

#3911 (the pwsh tool hang): the settlement path times out and settles the handle but does not kill the tree — orphaned grandchildren keep running after settlement. Your case is the Activation-tree analogue: settlement/teardown of the one-shot parent settles itself but leaves the continuable descendant running, billed, with no listener. Same root shape: the settle/dispose boundary cleans up what it owns directly, not the subtree beneath it. Worth cross-linking the two threads — they reinforce each other's fix shape.

On your two questions — the design answer is probably "2", with a twist

1. Should startContinuable refuse a non-continuation parent? I'd argue no. The tool description explicitly recommends run_in_background: false when the next action depends on the result — refusing continuable grandchildren from that path would break a legitimate, documented composition, and the preset ships exactly that mix.
2. Should agent/disposed drain the disposed agent's continuable descendants? Yes — but the semantic needs care. Two different moments are involved: parent settles normally (turn ends, parent still live) vs parent disposes (agent leaves the registry). For disposal, draining the continuable descendants is clearly right — nothing will ever own or hear them again, and the liveLineage wall you identified means a later host-level drain cannot reach them either, so they would run until app teardown. For normal settlement, the child's continuation is arguably intended (that's what "continuable" means — outlive the spawner and report back) — the real defect there is that the settlement notice targets the parent's session and gets dropped; the durable child Session still exists, but the notice channel is severed.

So the sharper fix shape is: on dispose, drain continuable descendants (your option 2); on settle, when the parent has no Activation (this exact case), either (a) re-parent the ownership edge to the nearest continuation-managed ancestor, or (b) at minimum surface the orphan in the parent's own closing message / settlement summary so it isn't silently forgotten. (a) is the closer match to the "waiting graph" invariant; (b) is the cheap fallback.

A persistent-orphan variant worth noting: the grandchild's Session is durable, so a restart doesn't free it either — cold resume of a child whose recorded parent is gone has the same "no live owner" shape. Whatever fix lands for the runtime case should state its cold-resume stance explicitly, mirroring the route-inheritance family's lesson (there, resume stability vs liveness was the open question).

The runtime reproduction you sketched — dispose the parent mid-flight and check whether the child's Activation survives — is worth someone doing; the agentLoop.create disposer is the one capability the continuation tests don't currently exercise, which is itself a test gap worth closing.

中文摘要：已对照 b150a55 逐条验证你的结构性论证——acquireOwnership 早退（:1162-1174）、notifySettlement 丢弃（:1462+）、agent/disposed 只清 scope（:385-386）、liveLineage 在消失的中间层处断裂（:881-891），全部成立；预设确实混合了 continuable（:191/:198）与 one-shot（:210/:219），可达性真实。家族关联：这是 #3911（pwsh 结算不杀树、孤儿孙进程）的 Activation 树同构——结算/销毁边界只清理自身、不清理子树。两个设计问题的回答：① 不应拒绝（工具描述推荐 run_in_background:false，拒绝会破坏合法组合）；② 应该 drain——但区分 dispose（应 drain，否则无人再能触达）与 settle（continuation 是有意语义，真缺陷是 notice 通道断裂）；修复形态 = dispose 时 drain + settle 时无 Activation 则重挂载到最近的 continuation 祖先或至少在关闭消息中显式呈现孤儿。冷恢复变体：child Session 持久 → 重启也不释放，恢复时同样无主。运行时复现（dispose 父代理检查 child Activation 是否存活）值得做——agentLoop.create 的 disposer 正是 continuation 测试未覆盖的能力缺口。

[Jstn-1g]

I reproduced the runtime failure against current master (b150a551b8), then built a reference patch.

The failing composition is concrete: create an exact non-continuation parent through ctx.agents.create(), start a held continuable child, and dispose the parent. On the base revision the parent has no Activation, the child does, and parent disposal removes the parent while the child's Activation remains live.

Reference implementation:

• commit: Jstn-1g@681d803
• branch: https://github.com/Jstn-1g/deepseek-harness/tree/reference/discussion-4239-parent-scope-drain

The patch keeps mixed one-shot/continuable composition valid. Before the first continuable materialization below an exact non-continuation parent, the manager installs one WeakSet-guarded cleanup effect in that parent Agent's own scope. Scope cleanup then reuses the exact-root drain machinery:

1. publish the descendant admission cutoff synchronously;
2. wait admitted materializations through publication or rollback;
3. cancel the selected forest top-down;
4. release handles child-first;
5. only then allow parent scope disposal and registry removal to finish.

The public drainContinuableDescendants() exact-live authorization filter is unchanged. Cleanup failures reach Cordis scope logging while lifecycle release continues, matching Cordis disposal semantics. Report delivery remains compatible: a report may still be accepted while host disposal is waiting for the parent's own quiescence; once Agent-scope cleanup publishes the drain cutoff, reports from that forest fail with DRAINING.

This intentionally fixes disposal only. Normal settlement, reparenting, notice routing after settlement, and cold-start/durable orphan recovery are not changed.

Verification:

• 130 focused continuation + report tests pass;
• affected continuation.ts: 100% statements, branches, functions, and lines;
• full lint/build and incremental repository typecheck pass;
• doc-sync: 28/28 gates; English/Chinese pair records are current;
• independent skeptical review found no remaining defect.

中文摘要：已在 b150a551b8 上运行时复现。参考修复在非继续执行 parent 的 Agent 作用域中安装一次清理 effect；dispose 时先关闭后代准入，等待正在物化的 child 完成发布或回滚，再自顶向下取消、按 child-first 顺序释放，最后才让 parent 离开注册表。它不拒绝 one-shot/continuable 混合组合，也不改变正常结算、重设 parent 或持久化孤儿恢复语义。130 项聚焦测试与受影响文件 100% 覆盖均通过。

[nokkies]

This thread did exactly what I hoped filing it as a question would do — thank you both.

@argszero: the #3911 cross-link is the observation that elevates this from a bug to a class. "The settle/dispose boundary cleans up what it owns directly, not the subtree beneath it" is a better statement of the root shape than anything in my report, and it predicts where else to look. Your design answer also matches what the preset ships: refusing mixed composition would break the documented run_in_background: false path, so the drain has to move to disposal.

@Jstn-1g: reviewed and adopted. Your reproduction closed the exact gap I declared — I stopped at agentLoop.create() discarding the disposer and would not assert a leak I had only reasoned about; going through the registry was the move I missed. On the patch itself, I did not take the verification claims on faith, and they held:

• Cherry-picked onto my fork's master (continuation.ts was upstream-identical): clean apply, 665 subagent tests pass, typecheck and doc gates clean — your i18n pair updates were appreciated, the bilingual gate passed untouched.
• My own mutation check: neutralizing both installParentDrain sites fails five of your tests, one of them verbatim the scenario this discussion describes ("drains a continuable descendant before its intermediate one-shot parent leaves the registry"). Non-vacuous coverage, independently confirmed.

Two design choices worth calling out as right, having tried to break them: installing the effect in the parent Agent's OWN scope means disposal ordering comes from Cordis rather than from a listener race — the drain is sequenced before scope teardown completes by construction, not by hoping agent/disposed fires early enough. And marking the WeakSet inside the effect callback ties "installed" to the effect actually being registered, so a scope that refuses the effect never records a phantom install.

The disposal-only scope is the correct cut. Settlement-path notice routing and durable orphan recovery are separable, and #3911's process-tree analogue stays its own fix.

Adopted downstream after that verification. For the maintainers: the reference branch applies cleanly to b150a551b8 and its tests are the reproduction this thread was missing — this is landable as-is.