harness: subagents share the parent sandbox instead of running in isolated sandboxes

[maruiz93]

What happens

When a fullsend agent spawns subagents (via Claude Code's Agent tool or workflows), all subagents run inside the parent agent's sandbox. They share the same filesystem, policy, providers, and network access. This requires widening the parent's policy to cover everything any subagent might need.

For example, an orchestrator agent that spawns three subagents to explore different repositories must grant all three subagents read access to all three repositories, plus any credentials each subagent needs — even though each subagent only operates on one repository.

What should happen

Each subagent should run in its own sandbox with:

• A scoped policy covering only what that subagent needs
• Its own set of providers, defined by the subagent's harness
• A defined input/output contract (parameters in, schema-validated result out)
• Independent filesystem isolation

The parent agent should be able to discover available subagent profiles, understand their parameters and expected output, and spawn them with specific inputs. Results should be returned as schema-validated JSON, with optional file downloads from the child sandbox before it is destroyed.

Context

ADR 0020 (composable single-responsibility agents with individual sandboxes) established that each step within a stage gets its own agent, harness, and sandbox. Today this is only implemented at the inter-stage level (triage → code → review as separate pipeline stages). Within a stage, subagents still share the parent's sandbox, violating the least-privilege principle ADR 0020 prescribes.

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 9:11 AM UTC · Completed 9:15 AM UTC
Commit: e8381e3 · View workflow run →

[fullsend-ai-triage]

Triage Summary

This issue requests per-subagent sandbox isolation as prescribed by ADR 0020. The problem statement is clear: within a stage, subagents currently share the parent agent's sandbox (filesystem, policy, providers, network), violating the least-privilege principle ADR 0020 establishes.

Prerequisite: PR #2098

Before per-subagent sandbox isolation can be implemented, the subagent invocation model itself must be corrected. PR #2098 fixes foundational issues with how subagents are defined and invoked — specifically that subagent_type is a hallucinated concept, agent definitions are not composable via subclassing, and tool access must be configured via frontmatter fields (tools/disallowedTools). Issue #3874 documents real-world evidence of the current broken model causing wasted compute.

Sandbox scoping depends on correct subagent definitions. Implementing isolation on top of a broken invocation model would compound the problem — the fix in PR #2098 should land first to establish the correct subagent definition patterns that sandbox isolation would then scope policies around.

Assessment

Once PR #2098 is merged, this issue is well-positioned for implementation. ADR 0020 provides the architectural decision, the gap between inter-stage isolation (implemented) and intra-stage isolation (not implemented) is clearly identified, and the desired behavior is specified with concrete requirements (scoped policies, per-subagent providers, input/output contracts, filesystem isolation).

Blocked by:

• fix(agents): There are no subagent "types"; they don't compose #2098

---

Labels: This issue describes a feature gap in the harness and sandbox components, relating to the per-subagent isolation architecture prescribed by ADR 0020.

[maruiz93]

Proposed design: host API server + fullsend-agent CLI

graph TB
    subgraph Host
        runner["fullsend run orchestrator.yaml"]
        api["Subagent API Server<br/>(ADR 0046 pattern)"]
        subrun["fullsend subagent run<br/>--harness explorer.yaml<br/>--param TARGET_REPO=fullsend"]

        runner -->|starts| api
        runner -->|creates| parent
        api -->|on POST /subagents/run| subrun
        subrun -->|creates + destroys| child
    end

    subgraph parent["Parent Sandbox"]
        claude["Claude Code<br/>(Agent tool disabled)"]
        cli["fullsend-agent CLI"]
        skill["Skill: use fullsend-agent"]

        claude -->|reads| skill
        claude -->|runs| cli
    end

    subgraph child["Child Sandbox"]
        claude2["Claude Code"]
        policy2["Scoped policy"]
        providers2["Scoped providers"]
    end

    cli -->|"GET /subagents<br/>POST /subagents/run"| api
    subrun -->|"schema result + files"| api
    api -->|"result via stdout"| cli

Loading

The parent agent uses a fullsend-agent CLI tool (shipped in the sandbox image) instead of Claude Code's native Agent tool. The CLI calls a host-side API server that spawns each subagent as a separate fullsend subagent run — a new CLI subcommand that creates a child sandbox, bootstraps it from the subagent's harness, runs Claude Code with the given prompt, validates the output against a schema, downloads any output files, destroys the sandbox, and returns the result.

Key design decisions:

• Subagent harnesses are standalone files in harness/, same format as regular harnesses. Most fields apply identically; fields that don't apply (post_script, runner_env, api_servers) are validated out in subagent mode.
• New params field for spawn-time parameters (e.g., TARGET_REPO) that expand into policies, host_files, and scripts via existing ${VAR} expansion.
• New output field defining the result contract — always a schema, optionally files.
• Parent declares subagent_harnesses mapping profile labels to harness paths. The API server uses this for discoverability (GET /subagents) and to restrict which harnesses can be spawned.
• Subagent providers are independent of the parent's — each subagent harness declares its own providers. Security comes from the subagent_harnesses declaration being static and auditable.

Blocking requirements

This cannot be implemented until:

• Host-side API servers for sandboxed agents #879 — Host API servers (ADR 0046): The api_servers runtime lifecycle must be implemented so the parent harness can start the subagent API server alongside the parent sandbox.
• Provider and profile definitions cannot be resolved from URL-referenced base harnesses #2672 — Portable providers: Provider-backed policy composition is needed so subagent network access is composed from provider profiles rather than per-agent policy files with embedded network rules.

[fullsend-ai-triage]

Meeting update — 2026-07-15

Relevant to this issue: The team identified that agents can circumvent disallowed tool restrictions by creating sub-agents, which inherit the parent sandbox's full tool and permission set rather than respecting per-agent tool restrictions.

• The bypass behavior was confirmed: agents creating sub-agents can access tools that are disallowed in the parent agent's configuration
• An issue will be filed with the upstream model provider (Anthropic) to report the disallowed-tools bypass behavior
• An existing tracking issue will be updated with a timeline documenting the investigation

Next steps: File the upstream issue with Anthropic, update the existing tracking issue with the investigation timeline, and provide broader team context on the bypass behavior.

Meeting notes