subharness 0.0.3 → 0.0.4

package/sdk/distribution.md

@@ -40,6 +40,58 @@ Authentication uses npm trusted publishing through GitHub Actions OIDC, without
 
 To release, choose a new stable tag on `main` that includes this workflow, enter the release notes, leave the GitHub pre-release option unchecked, and publish the GitHub release. The corresponding Actions run reports whether npm publication succeeded. No separate version-bump commit or release-candidate channel is required.
 
+### Maintainer commands
+
+An agent asked to publish to npm uses this GitHub release path. It needs authenticated `gh` access with permission to create releases in `vercel-labs/subharness`; local npm login and npm two-factor prompts are not part of normal automated publishing. Intended changes must already be merged into `main` with their checks passing. Uncommitted work and commits on other branches are not included.
+
+Inspect live state before selecting the version and source commit:
+
+```sh
+git fetch origin main --tags
+gh release list --repo vercel-labs/subharness
+gh run list --repo vercel-labs/subharness --workflow release.yml --limit 10
+npm view subharness versions dist-tags --json --registry=https://registry.npmjs.org/
+git log -5 --oneline origin/main
+```
+
+Use the requested stable version, or settle the version with the maintainer if the request does not specify one. Do not infer it from `package.json`. Verify that it is greater than the latest published version and has no existing npm version, GitHub release, or remote tag. Wait for any in-progress release before creating another. Inspect remote tags with `git ls-remote --tags origin`. Resolve a tag conflict before continuing: `--target` does not move an existing tag.
+
+After selecting the version and reviewing release notes, create the release at the exact verified `main` commit. In this example, replace `X.Y.Z` with the selected version and prepare `.context/release-notes.md` with the release notes:
+
+```sh
+release_version='X.Y.Z'
+release_commit=$(git rev-parse origin/main)
+gh release create "v$release_version" \
+  --repo vercel-labs/subharness \
+  --target "$release_commit" \
+  --title "v$release_version" \
+  --notes-file .context/release-notes.md \
+  --latest
+gh run list --repo vercel-labs/subharness --workflow release.yml \
+  --event release --commit "$release_commit" \
+  --json databaseId,headBranch,headSha,status,conclusion,url
+```
+
+Select the run for the new release tag and commit, then run `gh run watch RUN_ID --repo vercel-labs/subharness --exit-status`, replacing `RUN_ID` with its database ID. Inspect the run with `gh run view RUN_ID --repo vercel-labs/subharness --log` if necessary. The job must succeed through **Publish package**, including all behavioral tests and clean-consumer checks. The workflow limits tests to two concurrent files to avoid exhausting subprocess test deadlines on hosted runners; preserve that limit when updating release checks.
+
+`gh run watch` does not support fine-grained personal access tokens. If it is unavailable for the current authentication, poll `gh run view RUN_ID --repo vercel-labs/subharness --json status,conclusion,url` until `status` is `completed` and require `conclusion` to be `success`. Authentication must also allow reading Actions runs.
+
+Confirm public availability after the job succeeds:
+
+```sh
+npm view "subharness@$release_version" version dist.shasum dist.integrity \
+  --json --prefer-online --registry=https://registry.npmjs.org/
+npm view subharness dist-tags --json --prefer-online --registry=https://registry.npmjs.org/
+```
+
+The requested version must exist, `latest` must point to it, and its `dist.shasum` must match the tarball checksum in the publish log. npm can accept a publish while still processing the package; metadata and tarball downloads can become available at different times. Wait for propagation and verify that the public tarball downloads successfully before reporting completion. Report the GitHub release, successful Actions run, and npm version links.
+
+### Failed releases and retries
+
+Inspect the failed step and registry state before retrying. A failure before **Publish package** does not publish anything. For a transient failure on an unchanged commit, rerun the failed job only after confirming that publication did not succeed or remain in processing. A rerun uses the original release commit; it does not pick up a later fix on `main`.
+
+When a correction requires a new commit, merge and verify it before publishing another release. Never silently delete or move an existing release/tag. Replacing a failed release/tag requires explicit maintainer authorization and confirmation that the npm version was never accepted for publication. Otherwise, use a new stable version. An accepted npm version is immutable, including while it is processing: do not republish it or recreate its tag to attempt another upload. A delayed registry response alone is not evidence that publication failed.
+
 ## License
 
 The current source checkout and packages built from it are distributed under the Apache License, Version 2.0. The already-published `subharness@0.0.1` registry release remains under the MIT license. The root [LICENSE](../LICENSE) contains the complete Apache License text and is included in packages built from this source.

package/sdk/evals.md

@@ -80,7 +80,7 @@ interface EvalManifest {
     effort?: string;
     // Optional permission fields from the matching native harness constructor.
   }>;
-  cases?: Array<"auth-smoke" | "concurrent-progress" | "cli-skill" | "cli-background">;
+  cases?: Array<"auth-smoke" | "concurrent-progress" | "cli-skill" | "cli-background" | "cli-approval">;
   limits?: {
     startupMs?: number;
     caseMs?: number;
@@ -94,11 +94,11 @@ There are one to three targets with unique IDs matching `[a-z][a-z0-9-]{0,47}`.
 
 `access.cwd` is an absolute existing project directory used only to resolve access, never as the model's execution directory. Expected IDs are nonempty strings. Planning may validate directory/file metadata but never reads a credential source, starts a native executable (including `--version`), evaluates repository agent modules, or makes a network request.
 
-Cases default to `["auth-smoke"]`. An explicitly supplied list is nonempty, unique, contains only the four supported case IDs, and includes `auth-smoke`. Cells are the full target-by-case product, executed in target order and then the fixed order auth-smoke, concurrent-progress, cli-skill, cli-background. Cell IDs are `<target-id>/<case-id>`. Every cell has a fresh caller session and one attempt. Cases after an unsuccessful auth-smoke for that target are `not_run` with reason `auth-prerequisite`; no extra smoke is silently submitted.
+Cases default to `["auth-smoke"]`. An explicitly supplied list is nonempty, unique, contains only the five supported case IDs, and includes `auth-smoke`. Cells are the full target-by-case product, executed in target order and then the fixed order auth-smoke, concurrent-progress, cli-skill, cli-background, cli-approval. Cell IDs are `<target-id>/<case-id>`. Every cell has a fresh caller session and one attempt. Cases after an unsuccessful auth-smoke for that target are `not_run` with reason `auth-prerequisite`; no extra smoke is silently submitted.
 
 Limits are positive safe integers. Defaults and accepted ranges in milliseconds are: startupMs 30000 (1000–60000), caseMs 120000 (10000–300000), cleanupMs 10000 (5000–30000), and runMs 900000 (30000–1800000). The run budget must fit at least one startup + case + cleanup allowance. Reserve that full allowance before admitting each cell. The case deadline starts after native startup, separately from the startup deadline. Remaining cells become `not_run/run-budget` when insufficient budget remains.
 
-Fixed limits are one caller at a time, one requested caller turn per cell, one deterministic fake child at most, no retries/resume/replay, one invocation of each fixed helper action, helper lifetime at most 30000 ms, fixture output at most 4096 bytes, safe event evidence at most 65536 bytes per cell, and eight evaluated CLI invocations at most. A bounded final result is reserved separately from the event allowance. Overflow stops the affected cell and cannot erase its final classification. Up to twelve requested caller turns is not a guarantee of twelve provider requests or a hard spending cap: native tool loops and internal auxiliary requests are not fully exposed.
+Fixed limits are one caller at a time, one requested caller turn per cell, one deterministic fake child at most, no retries/resume/replay, one invocation of each fixed helper action, helper lifetime at most 30000 ms, fixture output at most 4096 bytes, safe event evidence at most 65536 bytes per cell, and eight evaluated CLI invocations at most. A bounded final result is reserved separately from the event allowance. Overflow stops the affected cell and cannot erase its final classification. Up to fifteen requested caller turns is not a guarantee of fifteen provider requests or a hard spending cap: native tool loops and internal auxiliary requests are not fully exposed.
 
 Planning exits 0. Invalid input, missing build inputs, and a mismatched live plan digest exit 2 without native startup. A run exits 0 only when every required case assertion passes, otherwise 1. Operator cancellation exits 130 after bounded cleanup. Optional unobservable native dimensions are visible coverage gaps rather than part of a concurrent-progress pass denominator.
 
@@ -169,3 +169,9 @@ Native background acknowledgement, notification and idle reactivation are explic
 The event writer accepts only known event kinds, bounded identifiers, booleans, numeric timestamps, exit statuses, validated session/task/response IDs, and known fixture values or verifier digests. It records monotonic local ordering and wall time. It excludes tokens and token hashes, full JWT claims, environments, private endpoint secrets, raw CLI response/error text, raw protocol/native settings/stderr, free-form model transcripts, reasoning, and exception messages/stacks before persistence or console output. CLI responses may be passed transiently to the caller but only validated fields enter reports.
 
 Each cell's cost is `{ amountUsd: null, source: "unobserved" }` in live mode and `{ amountUsd: null, source: "synthetic-no-billing" }` in fake mode. No actual total is invented from unknown cells. One smoke is a compatibility observation for that exact configuration, not a statistically supported model ranking.
+
+## Structured approval case
+
+`cli-approval` measures whether the selected caller harness/model follows the forced Subharness skill to inspect and answer a child's native permission requests. It uses the built CLI, a real local coordinator, and one deterministic child with two sequential requests in the same original turn. Request identifiers and offered choice values are generated per fixture; the caller must read the actual schemas. One harmless fixture operation is authorized once and a second is explicitly outside the caller's assignment and must be denied. Session or persistent grants are not authorized for either operation.
+
+Mechanical assertions cover both structured answers, correct request/task correlation, schema-valid choices, exactly one authorized effect and zero denied effects, one child session/turn, no retry/resume/replay or policy changes, terminal observation, bounded CLI use, and complete cleanup. The case may use up to eight built CLI invocations. Its single live caller submission uses the manifest's explicit permissions and strict project OIDC route. Child requests and effects are synthetic: passing establishes caller behavior and CLI/coordinator integration, not that a real native child generated those requests. Each `cli-approval` cell records `childExecution: "synthetic"` independently of the caller's `synthetic` flag. Native adapter emission and continuation are verified separately with deterministic external-protocol tests for Codex, Claude and fx. Reports retain only bounded structured evidence, never raw command output or model transcripts.

package/sdk/fx.md

@@ -59,7 +59,7 @@ Declared custom tools are exposed through an authenticated MCP HTTP endpoint bou
 
 Native fx 0.0.9 has a verified crash when receiving image-bearing MCP tool results through this ACP/HTTP route. The adapter forwards valid image blocks, but this native release's live image-tool execution is not supported reliably and can fail with `HARNESS_FAILED`. Adding a text label to the image result does not avoid the crash. Text and JSON tools remain supported. Native fx image attachments use a separate path; subharness's CLI currently accepts text prompts only.
 
-Native permissions remain authoritative. fx ACP does not expose scoped allow rules equivalent to the Claude adapter's delegation rules. The optional `permissionMode` selects and verifies the native process mode as defined in [Native Permissions](permissions.md). Omission preserves native settings. The library does not infer approval from a permission request. Any unresolved native approval or interactive-input request fails with `INPUT_REQUIRED`. Declared subagents use the session launcher and require native permission to execute it and reach the local coordinator. Declaring tools or children does not override a native approval requirement.
+Native permissions remain authoritative. fx ACP does not expose scoped allow rules equivalent to the Claude adapter's delegation rules. The optional `permissionMode` selects and verifies the native process mode as defined in [Native Permissions](permissions.md). Omission preserves native settings. The library does not infer approval from a permission request. Supported ACP permission requests expose the native choices through the [structured approval flow](approvals.md); an explicit answer resumes the same operation. Unsupported interactive input and startup-time requests fail with `INPUT_REQUIRED`. Declared subagents use the session launcher and require native permission to execute it and reach the local coordinator. Declaring tools or children does not override a native approval requirement.
 
 ## Session lifecycle
 

package/sdk/index.md

@@ -9,6 +9,7 @@ The CLI runs generic Codex, Claude Code, and fx agents without definition files.
 - [Discovery](config.md): repository/global definitions and personal worktree settings.
 - [Personal access](access-config.md): subscription discovery, explicit API keys, and project OIDC.
 - [Native permissions](permissions.md): session permission options, native limits, and background delegation.
+- [Permission requests](approvals.md): request-specific schemas, structured answers, and approval lifecycle.
 - [Harnesses](harnesses.md): selection, capabilities, and fallback boundaries.
 - [CLI](cli/index.md): commands and response waiting.
 - [Output](cli/output.md): compact text and typed JSONL records.

package/sdk/message-delivery.md

@@ -12,7 +12,7 @@
 
 Queue dispatch follows task completion, not the return of a CLI command or every native turn. If A returns a response while a reviewer is running, A remains active and B waits. Once descendants and result processing finish, the parent's complete response releases B. The library uses native completion and task relationships, not text classification.
 
-A complete response asking a question finishes a task when no descendant work remains. B can then start. The coordinator decides whether its answer should be queued or applied to the current task with another delivery mode. A native approval/input request is different: it has not completed a turn. In v1, input the library cannot answer under native policy fails with `INPUT_REQUIRED`; it is never automatically approved.
+A complete response asking a question finishes a task when no descendant work remains. B can then start. The coordinator decides whether its answer should be queued or applied to the current task with another delivery mode. A native approval/input request is different: it has not completed a turn. Supported native permission requests keep that original turn pending through the [structured approval flow](approvals.md); queued tasks retain their order until it finishes. Unsupported input fails with `INPUT_REQUIRED`. No request is automatically approved.
 
 Execution failure pauses pending work. New queued sends remain admissible while dispatch is paused. Their immediate `started` records include `paused: true` and `blockedByTaskId` naming the failed active task, so the caller can inspect it with `subharness status <failed-task-id> --full` and release the queue with `subharness cancel <failed-task-id>`. These fields capture queue state at admission and are omitted when the queue is not paused. A successful explicit native recovery must finish the failed task before pending tasks proceed. Unsupported recovery leaves work paused. Queued command observers may remain waiting until their task starts or is explicitly cancelled. Cancellation must be confirmed before it releases the queue; an unconfirmed stop keeps dispatch paused.
 

package/sdk/permissions.md

@@ -1,6 +1,6 @@
 # Native Permissions
 
-Harness constructors accept optional native permission settings directly alongside model options. These settings configure the native session without modifying persistent native settings or creating a Subharness sandbox. The library never answers a later native approval request with a synthetic allow response. The installed harness evaluates the selected policy, and the external execution environment enforces its remaining restrictions.
+Harness constructors accept optional native permission settings directly alongside model options. These settings configure the native session without modifying persistent native settings or creating a Subharness sandbox. Later supported native tool approvals are surfaced to the caller through the [structured approval flow](approvals.md); an explicit valid caller decision is required before authorization. The installed harness evaluates the selected policy, and the external execution environment enforces its remaining restrictions.
 
 Omitted settings preserve native configuration. Explicit settings remain fixed for session follow-ups. A child uses its own definition and native configuration; it does not inherit the parent's explicit permission options. Invalid definitions fail before execution. Unsupported or observably rejected explicit settings fail without fallback to another harness or permission policy.
 
@@ -33,7 +33,7 @@ claudeCode({
 
 `ClaudeCodeOptions` and `ClaudeCodeConfig` expose `permissionMode?: "default" | "acceptEdits" | "bypassPermissions" | "plan" | "dontAsk" | "auto"`, `allowedTools?: readonly string[]`, and `disallowedTools?: readonly string[]`. Rule arrays contain nonempty strings and are copied into immutable configuration. Unknown modes, non-string rules, and fields belonging to another harness are invalid definitions. An empty rule list adds no rules.
 
-The adapter passes these settings to the native Agent SDK. Explicit allowed rules are combined with the existing rules for declared custom tools and exact child-launcher operations. Disallowed rules remain authoritative under native permission evaluation. Selecting `bypassPermissions` also supplies the native SDK's required explicit bypass enablement. The library does not synthesize an allow response in its unresolved approval callback.
+The adapter passes these settings to the native Agent SDK. Explicit allowed rules are combined with the existing rules for declared custom tools and exact child-launcher operations. Disallowed rules remain authoritative under native permission evaluation. Selecting `bypassPermissions` also supplies the native SDK's required explicit bypass enablement. Unresolved callbacks use the structured approval flow; the library never chooses an allow decision automatically.
 
 Native permission mode and rule evaluation depend on the installed SDK, executable, and managed settings. Observable rejection or a reported different explicit mode is an error. A native initialization event that reports the active mode must agree with the explicit request. Startup success does not claim that every native rule or future command was verified. Diagnostics identify rejected options without exposing rule contents or tool arguments.
 
@@ -54,9 +54,9 @@ fx({
 
 ## Readiness and failures
 
-`check` uses the same permission configuration as execution. Its success establishes startup readiness and only the native settings observable during startup. It does not execute a shell or child launcher, prove arbitrary tool access, or claim unobservable native policy values. Native approval requests that remain unresolved fail with `INPUT_REQUIRED`; the library does not offer an interactive approval-answer command.
+`check` uses the same permission configuration as execution. Its success establishes startup readiness and only the native settings observable during startup. It does not execute a shell or child launcher, prove arbitrary tool access, or claim unobservable native policy values. Startup-time interactive requests still fail with `INPUT_REQUIRED`. During execution, supported permission requests surface through the [structured approval flow](approvals.md), without changing native configuration.
 
-A caller reports the affected harness and operation, then changes the explicit configuration or resolves the native restriction before starting a new attempt. Retrying unchanged permission failures, broadening policy automatically, or silently selecting another harness is not a recovery strategy.
+For a surfaced permission request, the caller inspects the action and responds to its schema, then observes the original task. For an unsupported interaction or hard native denial, the caller reports the affected harness and operation and resolves that restriction before starting a new attempt. Retrying unchanged permission failures, broadening policy automatically, or silently selecting another harness is not a recovery strategy.
 
 ## Background delegation
 

package/sdk/pr-integration.md

@@ -22,7 +22,7 @@ After every mutation, the integrator reads GitHub state again. Merge success req
 
 The report identifies merged, already merged, blocked, and unattempted entries, their reviewed heads, resulting merge commits when known, and exact blockers. It includes the observed final destination-branch SHA and command outcomes. The integrator writes a nonsecret progress journal only when the assignment names its path. It never exports credentials, dumps the environment, or claims local integration tests ran merely because hosted checks passed.
 
-The caller supplies the existing native GitHub authentication and any explicitly authorized native network profile. Model billing continues to use the caller's selected access configuration. Permission failures are reported without bypasses or silent changes of execution route. Native approval requests that require host interaction can produce `INPUT_REQUIRED`, as specified in the [adapter contract](adapter-contract.md).
+The caller supplies the existing native GitHub authentication and any explicitly authorized native network profile. Model billing continues to use the caller's selected access configuration. Permission failures are reported without bypasses or silent changes of execution route. Supported native permission requests use the [structured approval flow](approvals.md). A permission response does not expand the integrator's assigned merge authority. Unsupported host interactions can still produce `INPUT_REQUIRED`, as specified in the [adapter contract](adapter-contract.md).
 
 The allowlist is an instruction-level delegation contract, not a GitHub token scope or a new runtime security boundary. The agent retains native tools; neither the model's instructions nor an API-domain allowlist mechanically limits a credential to those PRs. Native sandbox policy, credential scopes, and GitHub protections remain the enforcement boundaries.
 

package/sdk/sessions.md

@@ -10,6 +10,7 @@ Each `run` creates a new session; `send` creates follow-up tasks or steers the a
 | --- | --- |
 | `queued` | Admitted but not yet dispatched |
 | `running` | Native startup or generation is active |
+| `awaiting_approval` | A native operation is waiting for a structured permission answer |
 | `waiting` | Between native turns while delegated work or result processing remains |
 | `completed` | Native response and descendant completion boundary are satisfied |
 | `failed` | Execution or cancellation failed; queue dispatch is paused |
@@ -24,8 +25,10 @@ Every complete response receives a response identifier and returns control to it
 
 ## Lifetime and recovery
 
-The on-demand coordinator retains task records and native session workers beyond individual command exits. Task IDs resolve from other working directories using that coordinator. Records remain available for its lifetime; they are not silently evicted.
+The on-demand coordinator retains task records and native session workers beyond individual command exits. Task IDs resolve from other working directories using that coordinator. Task records remain available for its lifetime; they are not silently evicted. Settled permission-request records have a separate bounded retention policy defined in [Responding to Native Permission Requests](approvals.md).
 
 Restarting the coordinator does not restore queues or automatically replay tasks. Native harness history can exist separately, but this version does not reconstruct library sessions from it. Unavailable identifiers return an error. `resume` is limited to supported native recovery of a retained failed task; it does not imply recovery after coordinator loss.
 
 Cancellation, interrupt propagation, and queue behavior are defined in [Message Delivery](message-delivery.md). The detailed ownership and bounds are defined in the [runtime contract](v1-runtime.md).
+
+Supported native permission requests follow [Responding to Native Permission Requests](approvals.md). Observing an approval returns control without completing or restarting the task.

package/sdk/v1-runtime.md

@@ -38,9 +38,9 @@ Closing a response-reading command does not cancel work. The coordinator retains
 
 ## Task states and responses
 
-The coordinator supplies the terminal dashboard with a read-only snapshot of current session work followed by retained finished tasks, including failed active tasks that pause a queue. Each task appears at most once, and retained history is available to newly opened dashboards for the coordinator’s lifetime. The private snapshot includes an explicit finished-history and grouped-context capability markers so the CLI can reject older incompatible coordinators. It carries only session/task identity, selected harness, bounded prompt title, task state, canonical checkout/repository paths, and timestamps needed by the display; it excludes environment variables, credentials, definitions, transcripts, and native diagnostics. Reading it does not acknowledge responses or change task execution. Workers report the actual selected harness to the coordinator after native startup succeeds. Task timing records the first dispatch, latest failure, and terminal completion or confirmed-stop time without resetting on native continuations. Finished rows retain a fixed elapsed duration; recovery clears terminal timing for the resumed task. Snapshot observation adds no public SDK execution method or persistent history. The display contract is defined in [CLI](cli/index.md#live-dashboard).
+The coordinator supplies the terminal dashboard with a read-only snapshot of current session work followed by retained finished tasks, including failed active tasks that pause a queue. Each task appears at most once, and retained history is available to newly opened dashboards for the coordinator’s lifetime. The private snapshot includes an explicit finished-history and grouped-context capability markers so the CLI can reject older incompatible coordinators. It carries only session/task identity, selected harness, bounded prompt title, task state, canonical checkout/repository paths, and timestamps needed by the display; it excludes environment variables, credentials, definitions, transcripts, and native diagnostics. Reading it does not acknowledge responses or change task execution. Workers report the actual selected harness to the coordinator after native startup succeeds. Task timing records the first dispatch, latest failure, and terminal completion or confirmed-stop time without resetting on native continuations. Finished rows retain a fixed elapsed duration; recovery clears terminal timing for the resumed task. Snapshot observation adds no public SDK execution method or persistent history. The inspector uses a separate authenticated, read-only session-history projection for retained work requests, stable admission ordinals, queue state and direct child sessions. Full prompt/response content is fetched only for the expanded request through the task-detail projection. It omits already-cached prompt and response text on refresh and never acknowledges delegated outcomes or changes execution. The private transport is defined in [Dashboard inspection](cli/dashboard-inspection.md); presentation is defined in [CLI](cli/index.md#live-dashboard).
 
-Task states are `queued`, `running`, `waiting`, `completed`, `failed`, `cancelled`, and `interrupted`. `waiting` means the library task remains active between native turns while delegated work or child-result processing is pending. A native permission request is not a completed response. Terminal outcomes are `completed`, `failed`, `cancelled`, and `interrupted`.
+Task states are `queued`, `running`, `waiting`, `awaiting_approval`, `completed`, `failed`, `cancelled`, and `interrupted`. `waiting` means the library task remains active between native turns while delegated work or child-result processing is pending. A native permission request is not a completed response. Terminal outcomes are `completed`, `failed`, `cancelled`, and `interrupted`.
 
 Each complete native response has an opaque response identifier, text, and the task state at that response. `wait` without `--after` returns the first retained response in order, including one that arrived before the command started, or awaits it. Omission does not select the latest response or begin observation at the current time. `wait --after <response-id>` returns the next retained response after that cursor. If no selected response remains and the task is terminal, it returns the terminal outcome. Unknown response identifiers, including identifiers from another task, are errors. Multiple observers can independently read the same response.
 
@@ -60,7 +60,7 @@ New follow-up tasks in a child session belong to the currently invoking parent t
 
 ## Permissions and bounds
 
-Adapters preserve native permission restrictions. Declaring subagents authorizes their invocation: Claude Code receives session-only native allow rules for the exact launcher and documented delegation operations, combined with permissions for declared custom tools. These delegation rules do not themselves change native modes, managed policy, or sandbox boundaries. Explicit constructor options separately select session-native permissions under [Native Permissions](permissions.md); persistent user/project settings are unchanged. This version does not provide an interactive permission-answer CLI: a native approval or input request that still cannot be handled under that policy fails the task with `INPUT_REQUIRED` and actionable guidance. The permission callback never automatically approves the request. The caller can configure its harness and explicitly recover where supported.
+Adapters preserve native permission restrictions. Declaring subagents authorizes their invocation: Claude Code receives session-only native allow rules for the exact launcher and documented delegation operations, combined with permissions for declared custom tools. These delegation rules do not themselves change native modes, managed policy, or sandbox boundaries. Explicit constructor options separately select session-native permissions under [Native Permissions](permissions.md); persistent user/project settings are unchanged. Supported native approval requests remain open and surface through the [structured approval flow](approvals.md). The caller answers the request-specific schema with `respond`, then observes the original task. The permission callback never automatically approves the request. Unsupported input and startup-time interactions still fail with `INPUT_REQUIRED`. Hard native denials remain subject to the selected native policy.
 
 Ordinary text/JSON tool results and complete responses are limited to 1 MiB. Rich tool results have the image and aggregate limits defined in [custom tools](tools.md). Oversized results produce explicit errors rather than silent truncation. `status` includes at most 4,000 characters of the latest response and marks truncation; `status --full` retrieves the complete latest response, while `wait` observes the first response or a subsequent response selected by a cursor. Delegation depth is limited to 8, and each session admits at most 100 pending tasks. Exceeding a bound fails admission without dropping existing work. No automatic task-duration deadline is imposed.