## 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\:

~~~json
{
  "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\,&#32;retain&#32;[Start from Main](<https://present-sketch-tp94.here.now/chapters/tan-2-start-from-main>)&#32;and&#32;[Interrupt\,&#32;cancel\,&#32;or kill](<https://present-sketch-tp94.here.now/chapters/tan-8-interrupt-cancel-or-kill>)\.&#32;Their historical observations are not rerun by this chapter\.

**Paper checkpoint\:**&#32;locate the Tan helper call\,&#32;then the helper’s merge order\.&#32;Explain how an explicit helper override could differ from the ordinary Tan call without inventing a CLI or slash\-command option\.&#32;**Worked answer\:**&#32;the helper API accepts overrides after its defaults\;&#32;the supplied Tan call does not provide them\.

**Failure boundary\:**&#32;neither a conversation fork\,&#32;a settings snapshot\,&#32;nor shared storage proves identical live permissions\,&#32;loaded safeguards\,&#32;remote authority\,&#32;or cross\-process enforcement\.

**Source anchors\:**&#32;`packages/coding-agent/src/task/executor.ts`&#32;—&#32;`createSubagentSettings`\,&#32;`runSubprocess`\,&#32;`createMCPProxyTools`\;&#32;`packages/coding-agent/src/modes/controllers/tan-command-controller.ts`&#32;—&#32;`TanCommandController.start`\;&#32;`packages/coding-agent/src/sdk.ts`&#32;—&#32;`CreateAgentSessionOptions`\,&#32;`createAgentSessionScoped`\;&#32;`packages/coding-agent/src/extensibility/extensions/wrapper.ts`&#32;— execute\-time approval inputs\.