A delegated child waiting on a permission approval never wakes its parent #26294

What happened

Two delegate_task children (Claude, claude-opus-5-5, spawned with bypassPermissions) each sat for about 2 hours on a command permission request. The parent got no completion and no notice. task_status showed pendingApproval with a request id, but t3_pending_request read on that id returned "not found", and t3_thread_organize settle on the child refused with "is waiting on an approval or question". The only way out was task_cancel.

Why (read on upstream/main d0b81ce; the reactor and settle checks are unchanged on 0c80751)

• DelegatedTaskQuestionReactor.ts wakes the parent only for user_input requests (it filters on request.kind !== "user_input"). A permission request gets no wake message.
• t3_pending_request covers questions only by design: "approvals are not listed … this cannot approve a permission request" (toolkits/thread/tools.ts:126). readQuestion looks only for kind === "user_input", so an approval id comes back as "The pending user-input request was not found."
• pendingApproval on the delegate result does surface it ("Oldest pending approval … Ends a wait. Grants no approval rights.", contracts/orchestratorMcp.ts:208), but only to a parent that happens to poll or wait.
• Settle refuses while any non-user_input request is pending (Orchestrator.ts ~3060).

So a child blocked on an approval is invisible unless the parent polls, and once found it can't be answered from MCP or settled.

It also leaks. After task_cancel, the approval on the cancelled child is still pending, so settle keeps refusing ("waiting on an approval or question"). No agent tool can answer a permission request, so the child thread keeps its provider session and MCP processes until a human clicks through it in the UI. (Interrupting a run does cancel its pending requests with "The run was interrupted." via settleInterruptedRun; the cancel path evidently didn't reach that here. We didn't trace why.)

Ask (any one helps; we'd take them in this order)

1. Wake the parent on a pending approval, the same way the question reactor does for questions: a notification saying which child, which request kind, and that a human must approve it in the UI.
2. Make t3_pending_request read on an approval id say what it is ("this is a permission approval; agents can't answer it") instead of "not found".
3. Put the approval text in that wake. It already exists: t3_thread_read activity on a third stalled child showed the approval_request text ("Dangerous rm operation on working directory or its ancestor: /scratch/..."). A parent that gets told which child and why can tell the user what to approve.
4. Make task_cancel cancel the child's pending approvals, like a run interrupt does, so a cancelled child can settle.

Agents answering approvals is reasonably out of scope; we're asking for visibility, not approval rights.

Why a bypassPermissions child asked at all: Claude Code's own safety check refuses to rm a directory that contains the shell's current working directory, and it asks even under bypassPermissions. The child had cd'd into the directory it then removed. That check is correct; the T3 gap is only that nobody hears about it.