Repository navigation
[Bug]: Lineage moves a delegated subagent that is waiting on its own worker to Previous agents as Completed #18587
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/web
Steps to reproduce
I have not run a fresh minimal reproduction. This is the observed workflow, followed by verification against stored state and source functions
- In a root thread, start an app-owned delegated task with a Claude subagent acting as supervisor
- The supervisor starts its own app-owned delegated task with a Codex worker
- The supervisor ends its first turn and waits while the worker continues running
- Open Lineage in the root thread and hover the supervisor row
At this point, the supervisor task is still running, but its child thread has exactly one run whose status is completed, with latestRunId set and no active run
Expected behavior
- The supervisor remains in active Lineage while its delegated task waits on the worker
- Lineage continues counting it as running
- Its hover status and elapsed time agree with the root timeline card
- Genuine follow-up runs remain visible, preserving the intended behavior of fix(server): track resumed subagent follow-ups as separate tasks #17696
Actual behavior
- The root timeline card shows the supervisor Running at 10m 51s and later 11m 04s
- Root Lineage places the same supervisor under Previous agents and shows no running count
- Its hover card shows Completed at a frozen 2m 09s, matching the duration of its first turn
- The supervisor’s own thread correctly shows Waiting on subagent, with its worker Running and Lineage · 1 running
Source-function verification points to two changes in #17696:
- In threadRelationships.ts, the edge now prefers the child thread’s latest run status whenever
latestRunIdexists. The completed first turn overrides the still-running task, causing the Previous agents placement and missing count - In currentSubagent, follow-up detection compares the run’s request time with the task’s start time. The initial run was requested 3 ms after task creation, so it is treated as newer work despite there being no follow-up. Its completed status and timestamps replace the running task’s values
The client already receives pending background work indicating a running subagent. The composer honors that signal, while these Lineage paths ignore it
Both functions preserve Running when evaluated using the code immediately before #17696. The affected files were unchanged on main at 58d2532 when checked
Related: #16603 concerns premature server completion. Here the server correctly holds completion. #16902 describes a similar nested symptom, but its underlying cause was not established
Note
I've seen many instances where waiting or background work causes a wrong status, state, etc.
One of which being subagents that stopped working based on the supervisor, but they still show as active, sometimes even stuck in a command "visually that is", and ending it with the button does nothing
Investigation: 6.1 Sol | Independent review: Opus 5.5
Impact
Minor bug or occasional failure
Version or commit
v0.0.46-nightly.20261011.2994 (d07a07f), affected files unchanged on main @ 58d2532 when checked
Environment
Windows x64, T3 Code desktop, server 0.0.46-nightly.20261011.2994. Supervisor: Claude Opus 5.5 High. Worker: GPT-6.1-Sol High Fast through Codex. Separate desktop build and provider CLI versions not recorded
Logs or stack traces
Stored state and source-function results, not application error logs
Captured 2026-10-12T08:22:06Z from the local database opened read-only
Supervisor task:
Origin: app_owned
Status: running
Result: null
CompletedAt: null
Workflow metadata: none
Supervisor child thread:
Run count: 1
Latest run status: completed
Activity run status: null
First run requested 3 ms after task creation
No follow-up run
Nested worker task and run: running
Delegated task progress: waiting_for_children
Derived pending background work: one subagent
Background work holds completion: true
Timeline card status: running
Before #17696 (fa9f936):
Lineage edge: running
Hover: running
Installed release source (d07a07f):
Lineage edge: completed
Group: Previous agents
Hover: completed
Hover elapsed at clock T: 129356 ms
Hover elapsed at T + 60 seconds: 129356 ms
Timeline elapsed increase over those 60 seconds: 60000 ms
Verification limits:
Source functions used timestamp conversion adapters
Thread shell reconstructed consistently with ProjectionStore
No fresh live reproduction or React/browser replay
No upstream test suite run or installed bundle inspectionScreenshots, recordings, or supporting files
Workaround
No verified fix. For monitoring, open the supervisor’s own thread, which still shows Waiting on subagent and its running worker
Activity
juliusmarminge commentedon Oct 12, 2026
Note
Grok responding on behalf of Julius.
Confirmed on main: this is a regression from #17696.
buildThreadRelationshipGraph(threadRelationships.ts) uses the child thread'sstatuswheneverlatestRunIdis set. The supervisor's finished first turn (completed) overrides the delegated task that is stillrunning, so the row falls under Previous agents and drops out of the running count.currentSubagent(ThreadRelationshipsControl.tsx) counts any run requested after the task'sstartedAtas "newer". The initial run is requested a few ms after the task is created, so it counts as a follow-up, and its completed status and frozen timestamps replace the task's values.Before #17696, both paths showed Running. Neither open PR covers this: #18149 handles workflow coordinators, and #16609 handles Claude-native background subagents in the adapter. Here the server holds completion correctly (unlike #16603). The bug is only in the client derivation.
Until it's fixed, open the supervisor's own thread to see its real status. The separate "stuck active after stop" note belongs in its own issue with a repro.
fix(web): show a supervisor waiting on its worker as running in Lineage
fix(web): show a supervisor waiting on its worker as running in Lineage
seankoji commentedon Oct 19, 2026
Also seeing this on macOS with the installed desktop build
0.1.1-nightly.20261018.3335, observed on 19 October 2026.The parent is a Codex thread and the app-owned delegated task runs Claude Opus 5.5.
The task and thread APIs show the conflicting states:
This is the same visible mismatch between the waiting bar and Lineage described here, now with a Codex parent and several completed child turns. The expected behavior is for Lineage to retain the active task while the waiting bar still counts it.
These are screenshots and live API observations from an ongoing task, not a fresh minimal reproduction or a new source-level diagnosis. The version above comes from the local app bundle; a separate server version was not checked.
t3-code commentedon Oct 21, 2026
closing as addressed by #18603, merged into main: Lineage preserves an active delegated task's status, progress and elapsed time while its supervisor waits on a worker, instead of replacing them with the child thread's completed turn.
thanks for reporting this. if you still face it on a build containing this fix, please ask us to reopen this issue or open a new issue linking back here, with your version, os and reproduction steps.
closed at the request of @UtkarshUsername.