[Bug]: A delegated task waiting on an approval is invisible to its parent agent and the user #17536

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. In a thread whose agent has the T3 MCP tools, have it call delegate_task with a Codex target and runtimeMode: "approval-required". A Supervised parent that delegates with the default inherited mode reproduces it too.
2. Give the child a task that runs a shell command, for example a code review that runs git diff.
3. Leave the child thread closed and wait.

Expected behavior

When a delegated child stops to wait for an approval, someone finds out:

• the parent agent: task_status reports that the task is waiting on the user, and an async parent is woken the same way it is for completion;
• the user: the same attention signal a top-level thread gets when it needs an approval (sidebar or inbox status, toast, desktop notification), pointing at the child thread.

Actual behavior

The child waits indefinitely and nothing tells anyone:

• task_status keeps returning workState: "working", status: "running". readTask loads the child's runs, messages, transfers, subagents and provider threads but not its runtime requests (apps/server/src/mcp/OrchestratorMcpService.ts, readTask), and delegatedTaskProgress (apps/server/src/orchestration-v2/SubagentProjection.ts) never looks at pending requests. workState has no value for this (packages/contracts/src/orchestratorMcp.ts).
• An async parent is only woken when the child reaches a terminal state (finalizeAppOwnedSubagent and delegatedCompletionWakeDetail in Orchestrator.ts). A mode: "wait" parent waits out its timeout, because TASK_WAKE_EVENTS does not include runtime-request.updated and waitForTask only returns on terminal states.
• The parent cannot see the approval itself. t3_pending_request_list leaves approval requests out, which is right, since an agent should not approve its child's permission prompts. But nothing else surfaces them.
• The user gets nothing. ThreadNotificationCoordinator skips every thread with relationshipToParent === "subagent" (a test, "keeps subagents silent", covers this), the sidebar hides subagent threads, and the relay awareness feed returns null for them. The parent row keeps showing Working.
• Codex's command approval handler awaits the decision with no timeout (CodexAdapterV2.ts, item/commandExecution/requestApproval), so the child stays parked until someone happens to open the child thread.

Native provider subagents already avoid this: approvalOwnerCodexTurn in CodexAdapterV2.ts asks their approvals on the parent thread "because native subagent threads are hidden from the sidebar" (#13703, #13726), OpenCode does the same, and #17329 fixed the same class of stall for Muse workflow subagents. Children started by delegate_task have no equivalent.

#14416 is related but separate: it documents that approval-required is not a read-only mode, which should stop agents from choosing it by mistake. A child can still legitimately need an approval (a Supervised parent, an explicit request for a supervised child, or a provider that falls back to Supervised in RuntimePolicy.ts), and when it does, this issue still applies.

Impact

Major degradation or frequent failure

Version or commit

Nightly; source references are from main @ 29980a3

Environment

macOS, T3 Code Nightly desktop. Parent: Claude Opus 5.5 (Claude provider). Child: Codex, GPT-6.1-Sol.

Workaround

Open the child thread from the parent's subagent card and answer the approval, or cancel the task. Avoid approval-required for unattended children.