sub-agent-sandboxing

Sub-Agent Sandboxing

Sub-Agent Sandboxing protects the main workflow from delegated tasks that spiral, retry indefinitely, or make changes in the wrong environment. It complements file-scope controls by adding runtime guardrails around how a sub-agent is allowed to execute.

Why This is Copilot-Exclusive

This pattern depends on Copilot CLI's delegated-agent workflow: separate task() execution lanes, background lifecycle management, approval checkpoints, and the ability to route risky work into a different checkout or environment before merging it back.

When to Use

• A delegated task could loop on the same tool call or retry path
• The agent may need multiple execution environments as risk increases
• Generated output must be validated before it can touch the main working tree
• A failing sub-agent should cool down without blocking the entire orchestrator

When NOT to Use

Instead of sub-agent-sandboxing	Use
You only need a narrow writable path	scope-guard
You are designing tasks and contracts before execution starts	agentic-engineering
The task is read-only research	normal delegation or fleet-parallel

Read-Only Reviewer Constraint

Reviewer sub-agents must not modify the working tree.

When a reviewer edits files during review:

• Uncommitted reviewer changes can be orphaned in the worktree
• A subsequent merge or rebase may silently include reviewer edits as if they were author changes
• The boundary between "authored work" and "review annotations" collapses

Enforce read-only mode in review briefs:

You are a reviewer. Your job is to evaluate the work, not change it.
Do not edit, create, or delete any files.
Return your findings as a report — do not apply fixes inline.

Orchestrator checks after a review pass:

# Confirm the reviewer left no staged or unstaged changes
git diff --name-only       # no output expected
git diff --cached --name-only  # no output expected