Proposal: Preserve current-turn context when forking subagents

[dazhanzheng]

Would it make sense for subagent_fork to inherit the parent's committed context at delegation time, including the current turn?

I have an unofficial local implementation and targeted verification. I am posting for design feedback in accordance with the current contribution policy, which directs external feedback to Discussions and does not currently accept external PRs.

Motivation

completedTurnPrefix() captures history only through the last turn/end. Consequently, a fork made during a long turn omits the current user request, the reasoning already recorded during that turn, and its completed tool results. A first-turn fork has no inherited conversation history.

For example, a parent receives a requirement, inspects files over several steps, and then delegates a focused review. The child still needs a specific assignment, but the parent must also restate the current-turn findings that motivated it.

The loop records the assembled assistant message before executing its tools. At a model-initiated fork, that response's reasoning is therefore already available. The unresolved problem is closing inherited execution consistently: the fork call itself, and possibly other calls in the same batch, do not yet have results.

Proposed implementation

The local implementation keeps the existing ownership split:

1. Session.snapshotForFork() returns immutable SessionForkSeed data: snapshot events plus the exact parent-prefix inheritedEventCount.
2. Session reuses the tail-scanning logic already used for crash recovery. It adds child-only TOOL_EXECUTION_NOT_INHERITED results for unanswered inherited calls, then closes the inherited step/turn with a distinct forked reason. These results explicitly leave execution with the parent and tell the child not to retry those calls.
3. The fork provider selects the snapshot. The existing one-shot driver and continuation manager retain responsibility for child creation, execution, and disposal. The agent loop requires no fork-specific changes.
4. Creators distinguish actual inherited history from the child-only closing records. Result collection excludes the complete seed; the existing ownEvents() inbox reconstruction excludes unread parent input. Continuable children resume their own persisted snapshot without re-forking newer parent history.

The snapshot retains assembled, logged messages; unassembled stream chunks stay log-only. Parent execution continues unchanged, and later updates still travel through send_message. The ordinary user-facing SessionStore.fork() operation keeps its explicit stable-boundary policy.

This introduces a Session API and a turn-ending reason, so it deserves review as a behavior/API change rather than only a provider implementation detail. It also retains more context in the child; provider-side prefix-cache reuse remains conditional.

Verification so far

The implementation was developed against 0.1.2-alpha.4, commit 4e84901e6471b79ec0338099867ebb4606d12bb5. I checked that the same completed-turn clipping remains in master at d347e703908d0406b7a7ef80e3a0e594d86b2215; I have not rebased the implementation onto that newer commit.

• Session and real tool-pipeline tests cover current-turn reasoning and tool results, unanswered calls in a batch, immutable parent history, continued parent execution, nested forks, compaction replacements, and cold resume.
• A targeted real DeepSeek SDK scenario gives the parent one fact in the current user request and another in a file it reads and deletes before delegation. The fork prompt contains neither answer. The child writes the expected proof file from inherited context, and the parent subsequently writes its own completion file. The test compares the complete final workspace.
• Keyless TypeScript SDK replay and a Python packaged-runtime smoke verify the child request/log and fork-specific closing records. Related Web regressions replay successfully; these cover existing UI/tool-schema behavior, not a new live-fork UI.
• Build, type checks, lint, and documentation checks pass locally. The implementation has not been published as a PR.

Would retaining committed current-turn context fit the intended semantics of subagent_fork, or would maintainers prefer this behavior behind a separate provider or explicit policy? If the direction is useful, I would be happy to share the implementation through the contribution route you prefer.

---

中文概要：建议让 subagent_fork 继承委派时当前轮次已经记录的消息、thinking 和工具结果。Session 层负责构造快照，并仅在子会话中闭合未完成调用，父 Agent 继续执行，Agent Loop 不增加 fork 特判。本地已有非官方实现及真实模型、SDK 回放验证，想先请维护者评估这种语义是否适合默认 fork，或更适合作为独立提供方／显式策略。

[lemonaide152]

A fork during a long turn drops the current user request, the reasoning already recorded, and the completed tool results, because history stops at the last turn/end. For one private temporary note of that omitted slice to the child, that agent can create the bridge itself at https://meld.mergeinc.workers.dev. Say what it is for and what it is not for, and send the URL privately. It stays open 36 hours until the first reply. Each later reply resets 24 hours. The conversation stays on that same link. It is free, and there is no billing. It does not change subagent_fork, and it will not inherit the parent transcript inside the harness.