[Bug]: A task delegated to a linked environment never shows its question or approval on the parent #26527

Activity

1. kukitch commented on Oct 31, 2026

   

   kukitch

   on Oct 31, 2026

   More actions

   Reproduced on T3 Code 0.1.5 (macOS desktop and headless t3 serve on macOS), Linked environments on, link access auto.

   • Parent thread on Mac A started delegate_task with target.environmentId set to linked Mac B, mode: "async".
   • The task on Mac B asked the user a question with the question tool and blocked.
   • Nothing reached the parent: it was woken only when the task later completed, and its last delegate_task result still said hasPendingQuestion: false.
   • The child thread appears only in the parent's details panel (Lineage). It is not in the sidebar or inbox on either machine, so the user found the blocked question only by opening Lineage and clicking the child.
   • A second check: a minimal delegate_task on the linked machine that asks one question also produced no phone notification (separate from this issue; noting it in case the two share a cause).

   Expected, as the issue says: the remote child's pending question surfaces on the parent and in the inbox, and task_status/delegate_task report it.
2. EtanHey commented on Nov 2, 2026

   

   EtanHey

   on Nov 2, 2026

   Contributor

   More actions

   Still reproduces on 0.1.7-nightly.20261101.4048 (88f6113), macOS arm64.

   • The parent thread is on linked environment A. Its delegated Codex child is on environment B, and the child asked a question (AskUserQuestion).
   • The parent's timeline banner did show "Subagent needs input … Open question". But the sidebar row for the parent stayed "Waiting" and never switched to Input, so nothing in the thread list showed that a person was needed.
   • Separately, the banner's "Open question" and child-title buttons went to a blank New thread page ("Open question" banner opens an empty new thread when the child thread runs on a linked environment #27005; fixed on main by fix(clients): open a delegated child's approval on the environment it runs in #28592, not yet in a nightly).

   The fix PR here (#26344) was closed without merging, so as far as I can tell there's no open fix for the sidebar side.

   Posted from a T3 Code triage session (Claude Opus 5.5 in Claude Code).
3. Gavin-Key commented on Nov 8, 2026

   

   Gavin-Key

   on Nov 8, 2026

   More actions

   Same here with password prompts. A task I delegated to my Linux box asked for my sudo password and two NAS logins through the secret prompt. The prompts showed only in the task's own thread. My parent thread on this machine never showed that it needed me, so the task sat blocked until I opened it myself.

   Windows 11 desktop, Linux box, Claude threads.
4. pWoLiAn commented on Nov 11, 2026

   

   pWoLiAn

   on Nov 11, 2026

   More actions

   Still reproduces with a newer build and a different child provider.

   Setup

   • Parent: T3 Code desktop 0.1.9-nightly.20261111.4501, macOS arm64.
   • Linked environment: headless t3 serve 0.1.6 on Ubuntu 22.04 (linux x64). It's linked over https through an nginx TLS proxy with full-access access.
   • Child: delegate_task with target.environmentId = the linked box, mode: "async", provider pi (github-copilot/claude-opus-5.5).

   What happened

   • The child on the box asked a question with pi's ask_user tool. It shows in the child's timeline as a user_input_request item.
   • On the parent, the sidebar and banner stayed "Waiting" and never showed Input. Nothing pointed to the question.
   • The only way to see it was to open the child thread on the box. I answered it there, and the request completed at 2026-11-11T07:44:07Z.
   • On the parent, delegate_task / task_status report remoteChild set, with childThreadId: null, childRunId: null, workState: "working", hasPendingQuestion: false, pendingApproval: null. I read these after the question was answered, so they don't show the state while it was open. On the box, the child thread has parentThreadId: null.

   This matches the original report and @EtanHey's comment: the remote child's question never reaches the parent, and the parent row stays "Waiting".
5. Silthus commented on Nov 11, 2026

   

   Silthus

   on Nov 11, 2026

   Author

   More actions

   Note

   🤖 Claude Opus 5.5 responding on behalf of Michael

   Still reproduces on 0.1.9-nightly.20261111.4501, Linux, both servers linked with full-access. A task on the linked box blocked on a question for 8 hours with no signal anywhere on the parent's side. Since #26367, four separate paths skip it:

   1. The sidebar hides the task under its parent, because the parent is open (threadShell.ts#L667).
   2. The parent row drops the question, since only approvals roll up now (threadShell.ts#L118).
   3. Notifications skip threads shown under a parent (ThreadNotificationCoordinator.tsx#L236).
   4. The parent agent is never told. DelegatedTaskQuestionReactor returns when the child has no local parent (L108), and the parent's task_status reports hasPendingQuestion: false (OrchestratorMcpService.ts#L1769).

   #26367 assumes the coordinator answers child questions. That holds for local tasks, but no agent ever sees a remote task's question.

   Proposed scope, much smaller than #26344: for a task delegated across environments, roll a live question up to the parent row as Awaiting Input, the same way approvals roll up today. The user answers in the task's own thread. That's client-only: no new cross-environment contract and no answer relay. Happy to send that PR if this direction works for you.
6. Abdullah97128 commented on Nov 14, 2026

   

   Abdullah97128

   on Nov 14, 2026

   More actions

   Still reproduces on 0.1.8 (headless t3 serve, Linux) with the parent on Linux and the child on a linked macOS machine (delegate_task, target.environmentId, Claude child, full-access).

   • The child asked a question with AskUserQuestion. The parent's timeline showed "Subagent needs input … Open question", but the parent's sidebar row stayed "Waiting" under Working, so the thread list never showed that a person was needed.
   • "Open question" didn't open the child, the same as "Open question" banner opens an empty new thread when the child thread runs on a linked environment #27005. Only the child's t3-thread:// link worked.

   Our setup gates every cross-machine task on a Go/Stop question, so each of these tasks blocks until someone happens to open the parent. +1 for rolling a remote child's live question up to the parent row as Input, as proposed above.
7. cyppe commented on Nov 15, 2026

   

   cyppe

   on Nov 15, 2026

   More actions

   Still reproduces on 0.1.10-nightly.20261113.4643, with a headless server on the remote side and a full-access link.

   • Parent: desktop 0.1.10-nightly.20261113.4643, Linux x64.
   • Remote: t3 serve --host 127.0.0.1 --port 3773 from the t3-0.1.10-nightly.20261113.4643-linux-x64 release, in an Ubuntu container, reached over an SSH forward to a loopback port. Linked with t3 environment link http://127.0.0.1:<port> --pairing-code <code> --access full-access.
   • Child: delegate_task with target.environmentId set to the remote, mode: "wait", timeoutMs: 90000, Claude (claude-sonnet-5-5). The task asked one question with AskUserQuestion.
   • The wait ran the full 90 s and returned waitTimedOut: true, hasPendingQuestion: false, pendingApproval: null.

   One thing that does work from the parent, in case it helps others until this is fixed: the parent's agent can see and answer the question through the link with t3_pending_request. It needs environmentId set to the remote and threadId set to remoteChild.threadId from the delegate_task result. action: "list" returned the request id, read returned the question, and respond with {"<question id>": "B"} unblocked it. The child then completed, and task_status on the parent showed its result ("B").

   Checked by Claude Opus 5.5, in Claude Code.