{{ message }}
feat(core): add experimental subagent context forking - #47576
Open
rekram1-node wants to merge 4 commits into
Open
feat(core): add experimental subagent context forking#47576rekram1-node wants to merge 4 commits into
rekram1-node wants to merge 4 commits into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Issue for this PR
No linked issue.
Type of change
What does this PR do?
Subagents currently start with fresh history. Setting
experimental.subagent_fork: trueregisters an optionalforkparameter that copies parent history before the assistant message spawning the child. The internal fork method accepts an optionalparentIDto record ownership using the existing creation and fork events. Forks inherit the source session's defaults; the subagent tool then sets its title, agent, and model through existing session methods before prompting. Public event schemas are unchanged. The only public schema addition is the config flag.With the flag absent or false, the registered tool uses the original input schema, description, and fresh-session behavior. It contains no fork parameter or prompting to enable the experiment. Config updates reload the registered schema through the existing config observer.
When enabled, passing both
forkandsessionIDreturns an error. Omittingforkor passingfalsekeeps fresh-session behavior. Forked children receive a short instruction to use inherited history as context and perform their assigned task. The parameter description and child instruction are intentionally brief.How did you verify your code works?
session-createandtool-subagent. Fork replay covers absent ownership, ownership by the source, and a separate owner, while preserving the source history and defaults. Coverage includes registration and model-visible schemas for missing/false/true config values, unchanged default wording and execution, conflicting arguments, inherited tool calls/results in the child's model request, history boundaries, continuation, and fresh sessions.config/entry-observer,session-compaction,session-instructions,session-runner-message, and config normalization. 18 schema tests passed across config, events, and event manifests.integration.ts:62,68usesSchema.Any. Those lines and the failing test are unchanged from the base.Screenshots / recordings
Not a UI change.
Checklist