fix(cli): run subagents under the parent session's tool permissions

[lakshya-dhariwal]

Description

Fixes #13289.

When the main agent spawns a subagent, executeSubAgent replaced the whole TOOL_PERMISSIONS state with { tool: "*", permission: "allow" } for the duration of the run, discarding every user-configured exclude/ask policy (Bash, Write, Edit, etc.).

This change removes the allow-all override (and the matching restore), so a subagent runs under the parent session's policies: allow flows through, exclude stays blocked by policy. It also plumbs the TUI's onToolPermissionRequest callback through executeStreamedToolCalls -> executeToolCall -> ToolRunContext -> executeSubAgent, so ask-tier tool calls inside a subagent surface the same approval dialog as top-level tool calls (the TODO that was left in executor.ts).

Headless behavior is unchanged: ask tools are not offered to the model in headless mode, same as the main agent.

One edge case to flag: if one batch spawns several subagents in parallel and two hit an ask prompt at the same time, the dialog shows one request at a time. Rare in practice; happy to add explicit queueing if you want it.

AI Code Review

• Team members only: AI review runs automatically when PR is opened or marked ready for review
• Team members can also trigger a review by commenting @continue-review

Checklist

• I've read the contributing guide
• The relevant docs, if any, have been updated or created
• The relevant tests, if any, have been updated or created

Screen recording or screenshot

Not a UI change; behavior is covered by the tests below.

Tests

• New src/subagent/executor.test.ts: the session's permission state is untouched during and after a subagent run, and onToolPermissionRequest is forwarded to the subagent's stream callbacks.
• Extended src/tools/subagent.test.ts: run forwards the callback from the tool run context.
• Verified with vitest run src/permissions src/stream src/tools (238 tests passing), tsc --noEmit, and eslint on the touched files.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[lakshya-dhariwal]

I have read the CLA Document and I hereby sign the CLA

[lakshya-dhariwal]

Heads up on jetbrains-tests: it fails during environment setup with "tar: Child returned status 1 / tar: Error is not recoverable" while unpacking, before any tests actually run. Same failure on two runs in a row, so it looks like an infra flake rather than something in this diff, which only touches extensions/cli. Could a maintainer re-run the job when you get a chance?

[lakshya-dhariwal]

Thanks for the review. I pushed changes for all three points:

1. Fail closed: an "ask" tool call with no onToolPermissionRequest callback (headless runs, or any caller that doesn't register one) is now denied as a policy denial. It never reaches execution. Tests cover Bash set to ask with no callback, including a run whose own policy says ask while the live state allows everything.
2. Policy snapshot: when a subagent is spawned, the parent's policy is deep-copied and frozen once. The subagent's stream checks tool calls, and the tool list it is offered, against that snapshot instead of the live TOOL_PERMISSIONS state. One gap: I couldn't find a declared tool allowlist on the subagent config in this codebase, so the snapshot is the parent policy only, not parent intersected with an allowlist. If an allowlist exists somewhere I missed, point me to it and I'll add the intersection.
3. Nested spawn: a subagent that spawns a subagent reuses the snapshot of the run that spawned it. A test checks that the grandchild gets the original ask policy even when the live state is allow-all.

The changes are in src/stream, src/tools and src/subagent, with tests in the existing executor and subagent test files plus a new streamChatResponse.permissions.test.ts.

[lakshya-dhariwal]

CI note: the CLI lint and test jobs pass on all OS and Node versions. The remaining failures look like infra: jetbrains-tests (tar unpack error before tests run), vscode-get-test-file-matrix, and the macOS and Windows VSIX builds (cancelled after 10m). Could a maintainer re-run those jobs when you get a chance?