Describe the feature or problem you'd like to solve
Extension-registered tools (from .github/extensions/ or user-scoped extensions) are only available to the top-level agent (depth 0) and first-level sub-agents (depth 1) via onPreToolUse. Nested sub-agents (depth 2+) cannot access these tools, forcing workarounds like injecting bash/curl instructions via onPreToolUse prompt modification.
Proposed solution
Allow extension tools to propagate to all sub-agent depths automatically (or via an opt-in flag like propagate: true in the tool definition). When a sub-agent is spawned via the task tool, it should inherit the parent session's extension tools so they can be called natively — just like built-in tools (grep, bash, view) are available at every depth.
This would:
- Eliminate brittle workarounds (prompt injection with CLI/curl fallback instructions)
- Enable consistent tool behavior regardless of agent depth
- Allow users to provide real-time guidance to sub-agents via custom interaction tools or via the existing ask_user tool which is currently not propagated to sub-agents
- Reduce token waste from sub-agents "looking around" when the user could simply answer a question or point them in the right direction
Example prompts or workflows
-
Semantic search: A vector search extension tool provides semantic code search. Sub-agents spawned to analyze search results can't call the tool themselves for follow-up queries — they fall back to grep, degrading result quality.
-
Approval gates: A request_approval tool requires human sign-off before destructive actions. If a sub-agent spawns another sub-agent that attempts a destructive action, the approval tool is unreachable.
-
Context injection: A get_project_context tool returns project-specific conventions and constraints. Sub-agents can't access it, so they operate without critical project knowledge.
-
Multi-step research: An explore sub-agent spawns a task sub-agent to run a test. The task sub-agent needs to call a custom notification tool to report progress — but it can't because extension tools don't propagate.
Additional context
The current workaround is to intercept task tool calls via onPreToolUse, parse the sub-agent's prompt from toolArgs, and append instructions telling the sub-agent to use bash/curl to replicate the tool's behavior. This is:
- Fragile — relies on prompt injection that models may ignore or misinterpret
- Token-expensive — the injected instructions consume context in every sub-agent
- Lossy — bash/curl fallbacks can't replicate rich tool schemas, validation, or structured return values
- Depth-limited — even this workaround only works for depth 1→2; deeper nesting requires each level to re-inject instructions
A native solution (tool propagation flag or session-level tool inheritance) would be significantly more robust and would unlock composable multi-agent workflows where extension tools "just work" at any depth.
Describe the feature or problem you'd like to solve
Extension-registered tools (from
.github/extensions/or user-scoped extensions) are only available to the top-level agent (depth 0) and first-level sub-agents (depth 1) viaonPreToolUse. Nested sub-agents (depth 2+) cannot access these tools, forcing workarounds like injecting bash/curl instructions viaonPreToolUseprompt modification.Proposed solution
Allow extension tools to propagate to all sub-agent depths automatically (or via an opt-in flag like
propagate: truein the tool definition). When a sub-agent is spawned via thetasktool, it should inherit the parent session's extension tools so they can be called natively — just like built-in tools (grep, bash, view) are available at every depth.This would:
Example prompts or workflows
Semantic search: A vector search extension tool provides semantic code search. Sub-agents spawned to analyze search results can't call the tool themselves for follow-up queries — they fall back to grep, degrading result quality.
Approval gates: A
request_approvaltool requires human sign-off before destructive actions. If a sub-agent spawns another sub-agent that attempts a destructive action, the approval tool is unreachable.Context injection: A
get_project_contexttool returns project-specific conventions and constraints. Sub-agents can't access it, so they operate without critical project knowledge.Multi-step research: An
exploresub-agent spawns atasksub-agent to run a test. The task sub-agent needs to call a custom notification tool to report progress — but it can't because extension tools don't propagate.Additional context
The current workaround is to intercept
tasktool calls viaonPreToolUse, parse the sub-agent's prompt fromtoolArgs, and append instructions telling the sub-agent to use bash/curl to replicate the tool's behavior. This is:A native solution (tool propagation flag or session-level tool inheritance) would be significantly more robust and would unlock composable multi-agent workflows where extension tools "just work" at any depth.