feat: exclude subagent tool from code_execution filtering

[rabi]

Summary

• Retain subagent tool even when code_execution mode is active
• Allows subagent to be called directly without going through code_execution

Type of Change

• Feature
• Bug fix
• Refactor / Code quality
• Performance improvement
• Documentation
• Tests
• Security fix
• Build / Release
• Other (specify below)

Testing

Tested locally.

( O)> check ~/.config/goose/config.yaml and list the extensions enabled.

─── 1 tool call | execute_code ──────────────────────────
  1. developer/shell: Read the goose config file using cat to handle home directory expansion


─── 1 tool call | execute_code ──────────────────────────
  1. developer/shell: Read the first 50 lines of the config file to check for missed extensions

Based on the configuration file at `~/.config/goose/config.yaml`, the following extensions are currently enabled:

*   **developer**: Code editing and shell access
*   **skills**: Load and use skills from .claude/skills or .goose/skills directories
*   **extensionmanager**: Enable extension management tools
*   **chatrecall**: Search past conversations and load session summaries
*   **autovisualiser**: Data visualization and UI generation tools
*   **memory**: Teach goose your preferences as you go
*   **code_execution**: Execute JavaScript code in a sandboxed environment
*   **github**: github extension

The following extensions are present but **disabled**:
*   todo
*   computercontroller
*   tutorial
*   jira
*   kiteextension
*   kiwitravel

( O)> Use a subagent with google provider and gemini-3-pro-preview model to fetch last 10 PRs from vllm-project/vllm and another subagent with gcp_vertex_ai provider and claude-opus-4-5@20251101 model to fetch last 10 PRs from sgl-project/sglang and then present them together

─── subagent |  ──────────────────────────
instructions: Fetch the last 10 Pull Requests from the repository 'vllm-project/vllm' using the GitHub tool. Li...
settings:
    model: gemini-3-pro-preview
    provider: google


─── subagent |  ──────────────────────────
instructions: Fetch the last 10 Pull Requests from the repository 'sgl-project/sglang' using the GitHub tool. L...
settings:
    model: claude-opus-4-5@20251101
    provider: gcp_vertex_ai

Here are the last 10 Pull Requests for **vllm-project/vllm** and **sgl-project/sglang**.
.....

[alexhancock]

I'm not sure.

Why wouldn't we want subagent execution to go through code execution? I get that it might be harder to get granular info back about what the subagents are doing, but not impossible... and to have the top level agent be able to orchestrate subagents from code feels potentially powerful.

Thoughts?

[rabi]

I'm not sure.

Why wouldn't we want subagent execution to go through code execution? I get that it might be harder to get granular info back about what the subagents are doing, but not impossible... and to have the top level agent be able to orchestrate subagents from code feels potentially powerful.

Thoughts?

Thanks for checking the PR Alex. Here are my thoughts...

• Code‑execution mode only exposes extension tools right now; subagent is injected by Agent::list_tools, so it isn’t visible to code_execution. At present it tries hard before falling back to things like below..

import { shell } from "developer";

const vllmCmd = `goose run --no-session --provider google --model gemini-2.5-pro --text "Fetch last 10 PRs for vllm-project/vllm. Save them as a valid JSON array to 'vllm_prs.json'. Fields: title, url, author, created_at. Then run 'cat vllm_prs.json'." --quiet`;

const vllmRaw = shell({ command: vllmCmd });
record_result({ vllmRaw });

• We could expose it, but subagents are full sessions. execute_code bypasses normal tool‑request flow, so surfacing subagent activity would need lot of extra plumbing.
• One batched execute_code call could spawn multiple subagents — a fan‑out multiplier that increases complexity and is harder for users to follow.
• A subagent started with code_execution enabled will still use it for its own tool calls, so we’re probably not gaining extra sandboxing or batching by triggering it from JS.

[alexhancock]

I'm not sure.
Why wouldn't we want subagent execution to go through code execution? I get that it might be harder to get granular info back about what the subagents are doing, but not impossible... and to have the top level agent be able to orchestrate subagents from code feels potentially powerful.
Thoughts?

Thanks for checking the PR Alex. Here are my thoughts...

• Code‑execution mode only exposes extension tools right now; subagent is injected by Agent::list_tools, so it isn’t visible to code_execution. At present it tries hard before falling back to things like below..

import { shell } from "developer";

const vllmCmd = `goose run --no-session --provider google --model gemini-2.5-pro --text "Fetch last 10 PRs for vllm-project/vllm. Save them as a valid JSON array to 'vllm_prs.json'. Fields: title, url, author, created_at. Then run 'cat vllm_prs.json'." --quiet`;

const vllmRaw = shell({ command: vllmCmd });
record_result({ vllmRaw });

• We could expose it, but subagents are full sessions. execute_code bypasses normal tool‑request flow, so surfacing subagent activity would need lot of extra plumbing.
• One batched execute_code call could spawn multiple subagents — a fan‑out multiplier that increases complexity and is harder for users to follow.
• A subagent started with code_execution enabled will still use it for its own tool calls, so we’re probably not gaining extra sandboxing or batching by triggering it from JS.

It makes sense. Thanks @rabi