Subagents and inherited policies
The preceding Tan part established that a conversation fork is not a cloned runtime. Permission construction supplies a concrete reason.
Nia expects an unattended child to reproduce Main’s interactive approval mode. The initial helper does something more specific: it snapshots settings, applies child defaults, and permits explicit helper overrides afterward.
Read the helper in its actual callers
createSubagentSettings() in packages/coding-agent/src/task/executor.ts reads every key in SETTINGS_SCHEMA from the base settings. It creates an in-memory settings instance with that snapshot, then applies these defaults before spreading any explicit overrides:
tools.approvalMode: "yolo";advisor.enabled: false.
It also passes the base storage handle to the isolated settings instance. “In-memory settings overrides” therefore does not mean every shared runtime resource or storage service has been duplicated or removed.
runSubprocess() uses this helper for Task construction. TanCommandController.start() uses the same helper. Its call is createSubagentSettings(this.ctx.settings), with no explicit approval-mode override at that call site.
The initial Tan SDK construction sets hasUI: false and disables extension discovery. It passes enabled-tool names and other captured context through specific options; it does not pass Main’s live extension instances as a cloned safeguard set. Supplied MCP proxies and custom-tool discovery are separate mechanisms.
Predict a child from a small configuration
Use this fictional base configuration on paper:
{
"tools.approvalMode": "always-ask",
"tools.approval": { "bash": "deny" }
}
Prediction: after the helper’s ordinary defaults, must the child prompt for every exec-tier call? Does bash become allowed?
Source-backed worked answer: the child settings mode defaults to yolo, so tier-only exec prompting is not inherited unchanged. The per-tool policy record remains relevant: an effective bash deny still resolves to denial. A user prompt policy can likewise leave a child needing a UI it does not have, subject to the resolver’s tool-policy precedence.
This example is a source-derived calculation, not an executed child scenario. None of the 46 private cases launches Task or Tan.
Separate three meanings of inheritance
| Layer | What is established | What not to infer |
|---|---|---|
| Initial helper defaults | Snapshot values are used, then yolo and advisor-off defaults are applied. | The parent’s interactive mode was copied unchanged. |
| Explicit helper overrides | The final overrides spread can replace the helper’s default mode. | Ordinary Tan launch supplies such an override, or a new Tan flag exists. |
| Live runtime inputs | The wrapper samples its execute-time settings and autoApprove; specific shared callbacks/resources can remain live. | Every later parent setting or safeguard automatically mirrors into every child. |
The helper’s optional inherited service-tier argument is another example of an explicit input. It concerns provider service tiers, not the read/write/exec approval tiers. Likewise, the SDK can carry a live extension-root provider for certain child construction paths. Neither establishes a universal live approval-policy inheritance mechanism.
If another host later applies runtime inheritance, that is a separate transition to inspect. An initial helper result is not proof that a child remains permanently at that value, and a conversation relationship is not proof of a later synchronization. The complete packages/coding-agent/src/session/agent-session.ts implementation and host-specific live inheritance adapters are outside this selected permissions pack; no blanket statement about those transitions is warranted.
Parent approval is not an OS delegation
The helper’s source explains the unattended design in terms of the parent Task approval boundary. That does not make the child a sandbox or erase its per-tool policies. It also does not make a human /tan command identical to a model-issued Task call: they are different entry surfaces.
A “do not edit” assignment remains behavioral guidance. The child’s actual tool surface, policy record, domain rules, and host authority determine what it can do. Focusing a headlessly created Tan later is not evidence that it was reconstructed with every interactive facility.
For the original launch and lifecycle qualifications, retain Start from Main and Interrupt, cancel, or kill. Their historical observations are not rerun by this chapter.
Paper checkpoint: locate the Tan helper call, then the helper’s merge order. Explain how an explicit helper override could differ from the ordinary Tan call without inventing a CLI or slash-command option. Worked answer: the helper API accepts overrides after its defaults; the supplied Tan call does not provide them.
Failure boundary: neither a conversation fork, a settings snapshot, nor shared storage proves identical live permissions, loaded safeguards, remote authority, or cross-process enforcement.
Source anchors: packages/coding-agent/src/task/executor.ts — createSubagentSettings, runSubprocess, createMCPProxyTools; packages/coding-agent/src/modes/controllers/tan-command-controller.ts — TanCommandController.start; packages/coding-agent/src/sdk.ts — CreateAgentSessionOptions, createAgentSessionScoped; packages/coding-agent/src/extensibility/extensions/wrapper.ts — execute-time approval inputs.
Tool permissions and approvals · Source chapter: permissions/subagents-and-inherited-policies. Original evidence remains scoped to its recorded snapshot.