You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Parent agent is not notified when a delegated child waits for an approval #22925
I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.
Area
apps/server
Context
#15082 was closed on 2026-10-21 with this note: "One part is still open: parent-agent notification for approvals and sign-in requests. If that part still matters to you, please open a new issue for that part only." This is that part. PR #20928 ("notify parents when delegated children need approval") is open and appears to address it.
Steps to reproduce
On 0.1.2-nightly.20261021.3473 (macOS, desktop app), a Claude parent thread (claude-opus-5-5, full access) launches an async child with delegate_task on a second Claude provider instance (claude-opus-5-5, runtimeMode: full-access).
The child runs a Bash command that edits a file through a heredoc (python3 - <<'PY' ... PY). The CLI raises a command approval for it. The child's system/init event reports permissionMode: "bypassPermissions".
The parent's turn has ended. Nothing wakes it.
Expected behavior
The parent agent receives a notice that the child is blocked on an approval, with a link to the child thread, so it can tell the user or stop and relaunch the child.
Actual behavior
The parent agent gets no notice. The user saw the "Subagent needs approval" banner and had to tell the parent agent about it in chat.
task_status reports status: running, workState: working, pendingApproval: null, while t3_thread_read on the child reports pendingRequestCount: 1.
The parent agent cannot approve or decline. Its only option is t3_thread_interrupt followed by t3_thread_send with new instructions.
After the interrupt, the old approval stays pending and the banner stays on screen while the new run works normally (see [Bug]: Command approvals stay pending after a delegated task is cancelled #21935). The user then reported the same banner two more times, and the parent had to inspect the child to tell a stale request from a new one.
Impact
Major degradation or frequent failure
Workaround
The parent tells every Claude child to edit files only with Edit/Write, to write scripts to a file before running them, and to avoid heredocs and rm -rf with variables. Codex children in the same session did not raise approvals.
Reproduced the missing parent notice on current main 8acbefe, using the real web dev server on Linux and Claude Opus 5.5 on two provider instances. The full-access heredoc completed without prompting here. With an approval-required child, the command approval remained pending and the banner appeared, while the parent stayed completed with no new message or run.
Existing #20928 covers the notification path; preserving that implementation rather than opening a competing PR.
Updated the existing fix #20928 at 152bad3669, preserving its history. The missing-notice regression fails on the baseline; 83 focused tests and the server typecheck pass on the fix. Ten final-head server runtime scenarios pass using synthetic provider events and real orchestration/SQLite. Real-provider after-fix and device acceptance remain unverified. The PR is labeled bugfix and remains unmerged.
Activity
juliusmarminge commentedon Oct 22, 2026
Reproduced the missing parent notice on current main 8acbefe, using the real web dev server on Linux and Claude Opus 5.5 on two provider instances. The full-access heredoc completed without prompting here. With an approval-required child, the command approval remained pending and the banner appeared, while the parent stayed completed with no new message or run.
Existing #20928 covers the notification path; preserving that implementation rather than opening a competing PR.
Runtime transcript
juliusmarminge commentedon Oct 22, 2026
Updated the existing fix #20928 at 152bad3669, preserving its history. The missing-notice regression fails on the baseline; 83 focused tests and the server typecheck pass on the fix. Ten final-head server runtime scenarios pass using synthetic provider events and real orchestration/SQLite. Real-provider after-fix and device acceptance remain unverified. The PR is labeled
bugfixand remains unmerged.