Skip to content

[Bug]: Parent agent is not notified when a delegated child waits for an approval #22925

Open

Description

@pedrozimmermannsoares

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

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

  1. 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).
  2. 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".
  3. 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.

Activity

  1. juliusmarminge commented on Oct 22, 2026

    @juliusmarminge
    Member

    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

    Parent remains idle while the delegated child needs approval

  2. juliusmarminge commented on Oct 22, 2026

    @juliusmarminge
    Member

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions