[Bug]: A remote delegated task shows up as an active thread once its settled parent falls out of the newest 25 settled threads #30320

Activity

1. christi4nity commented on Nov 4, 2026

   

   christi4nity

   on Nov 4, 2026

   More actions

   Independently reproduced on T3 Code 0.1.6 with iOS 2.2.0 and all three environments connected. A completed remote review appeared active because its settled parent was 28th in an environment whose initial snapshot keeps only 25 settled threads. Loading the parent restored grouping. Manually settling the review cleared it. PR #28344 appears to address this failure.
2. w00dy1981 commented on Nov 5, 2026

   

   w00dy1981

   on Nov 5, 2026

   More actions

   Confirmed again on desktop after updating to 0.1.8-nightly.20261105.4234 and reopening T3 Code on 6 November 2026. Four completed tasks delegated from a Linux environment to a linked machine reappeared as standalone chats marked Done.

   We checked both environments' SQLite databases read-only, the saved delegation calls, and the installed server and client code. This matches the cause reported here.

   Database findings

   • The parent is settled, unarchived, undeleted and unpinned. It is exactly the 26th newest settled top-level thread, with 25 newer settled threads.
   • Each of the four remote tasks retains the correct delegatedFrom.environmentId and delegatedFrom.threadId. Their empty local lineage.parentThreadId is expected for remote delegation.
   • Each task has one existing database record and one retained creation event. All runs are completed. The source environment records their results as delivered.
   • The remote tasks themselves have settledOverride, settledAt, archivedAt and deletedAt all null. They were never individually settled.
   • None of the four has a command receipt or retained event after the parent's settlement on 4 November at 03:45:32.757Z. The database shows no recreation, rerun or change from settled to active associated with their return to the list.

   The event history has been pruned, so retained events alone are not a complete history. Command receipts, completed-run records, saved projections and provider logs provide the additional evidence.

   Reproduction against the installed code

   We extracted the installed listActiveShellIndex SQL and shellSubscriberThreadIds filtering functions, then ran them against the source database in read-only mode. We also executed the installed client's parent lookup condition against the resulting parent presence.

   Input	Parent in fresh snapshot	Remote task grouped beneath parent
   Actual database, with 25 newer settled threads	No	No
   Same input with one newer settled thread omitted from the replay	Yes	Yes

   No database writes were needed to reproduce the change. The installed client still requires the parent's indexed shell to satisfy ?.archivedAt === null; an absent shell fails that check even though the parent still exists and is settled.

   This explains why reopening exposes the old jobs without any new work on them. We did not automate a full desktop restart, but the installed-code replay reproduces the filtering decision with the affected database records.

   PR #28344 appears directly relevant. It remains open and unmerged. Please keep this existing-task case in mind when fixing it: these remote jobs are already completed and their parent settled before any fix is installed. A fix that only reacts to future parent-settle events may leave existing affected jobs needing manual settlement.

   Written by Codex (gpt-6.1-sol) in T3 Code on 6 November 2026. Investigation thread t3-thread://v2/2261971d-436a-4f11-aa72-1eb55a402b04/40ccd506-e5d6-49b4-baff-76fd905faf02.
3. VDrozd-Cyclis commented on Nov 6, 2026

   

   VDrozd-Cyclis

   on Nov 6, 2026

   More actions

   Same bug on stable 0.1.7: a macOS desktop (local server) linked to a Linux server, both servers on serverVersion 0.1.7. Checked read-only: the Mac's SQLite database, and the Linux server's thread list through the T3 MCP tools.

   What we saw

   • One parent thread on the Linux server ran delegate_task to the Mac 12 times between 2026-11-04 18:08 and 2026-11-05 10:08 UTC. The parent settled on 2026-11-05 at 10:10 UTC and is now the 28th newest settled top-level thread on that server.
   • All 12 tasks show on the Mac as active top-level threads. Each still has the correct delegatedFrom and an empty lineage.parentThreadId. settledOverride, settledAt and archivedAt are all null, and every run is completed.
   • 11 more tasks on the Mac belong to 6 other parents that are settled but still ranked 8th to 14th. They will surface after 11 to 17 more threads settle on the Linux server.
   • They first appeared after opening the mobile app. That fits this cause: a fresh connect gets the trimmed snapshot without the parent, while a client that loaded the parent earlier keeps nesting the tasks.

   Code
   At v0.1.7, NEWEST_SETTLED_KEPT = 25 in ShellStream.ts and the delegatedUnderParentAtom lookup in threadShell.ts match the description above. hiddenChildAncestorIds keeps an older settled parent only for children in the same environment, so a parent whose tasks run on another machine gets no exception. ShellStream.ts, threadShell.ts and RemoteDelegation.ts are identical on main today, and #28344 is still open.

   Workaround
   Settle the tasks by hand on the machine that ran them. Lowering sidebarAutoSettleAfterDays there also clears them, but it applies to every thread on that machine.

   ---

   Drafted by Claude Opus 5.5 (Claude Code) in a T3 Code triage session.
4. Gavin-Key commented on Nov 8, 2026

   

   Gavin-Key

   on Nov 8, 2026

   More actions

   I hit this too, but when my two linked machines (A and B) aren't fully connected:

   • Tasks A delegated to B show up as top-level threads in B's sidebar.
   • When they finish, B gets the "Thread completed" notification and sound. A, where I'm working, gets nothing.

   Windows 11 desktop, Claude threads.
5. Michaelihc commented on Nov 9, 2026

   

   Michaelihc

   on Nov 9, 2026

   Contributor

   More actions

   I'm also experiencing this on Windows with linked workstation and MSI environments, on 0.1.8-nightly.20261109.4399.

   After updating/reopening T3 Code, batches of old, completed MSI jobs appear as standalone sidebar threads marked Done. Read-only inspection confirmed that the affected jobs still have their delegatedFrom references, while their own settledOverride, settledAt, and archivedAt are null. The client still uses the parent-in-snapshot lookup described in this issue.

   This matches the resurfacing symptom here; we haven't independently verified the parent’s exact settled-window rank in this instance. The jobs are existing conversations, rather than newly created jobs from the update.

   Posted with the reporter's permission by Codex in T3 Code.
6. zucram commented on Nov 10, 2026

   

   zucram

   on Nov 10, 2026

   More actions

   Note

   🤖 Claude Opus 5.5 responding on behalf of zucram

   Reproduced with one difference: settling the child by hand does not hide it on iOS. That is the workaround given above. PR #28344 would not cover this case either, because our child was already settled.

   Setup: server A is Linux (0.1.9-nightly.20261110.4452) and server B is a macOS desktop running its own local server (0.1.8-nightly.20261109.4399). The two are linked both ways. The iOS app is connected to both, with "All environments" selected.

   What we checked (both SQLite databases, read-only):

   • A thread on A called t3_thread_launch on B on 2026-11-08 at 14:28 UTC. The child has delegatedFrom pointing at the parent on A, and lineage.parentThreadId is null.
   • The child finished at 15:02:35 UTC. In the same second, the lead settled the child with t3_thread_organize: settledOverride: "settled", settledAt 2026-11-08T15:02:35.895Z, unsettledAt null, and it is not archived. No person ever visited it: lastVisitedAt equals its creation time.
   • The parent was settled on A at 20:52 UTC. It is now the 36th newest settled top-level thread on A.
   • B's projection shows the child's updatedAt as 2026-11-09T15:02:39Z. There are no messages or events on the child after 2026-11-08 15:02, so we could not find what changed.

   What each client shows:

   • macOS desktop on B: the child is in the Settled shelf, which is correct.
   • iOS: the child is at the very top, above the Working section, marked Done, as if it were a finished run nobody has looked at. Two other settled children from the same parent show correctly under Settled.

   So on iOS, the fallback that puts a delegated child at the top level when its parent was trimmed from the list appears to skip the child's own settled state. Expected behavior: a child whose parent can't be found and which is itself settled should go to the Settled shelf, as on desktop.
7. hhharryyyyy commented on Nov 10, 2026

   

   hhharryyyyy

   on Nov 10, 2026

   More actions

   im also seeing old completed subagent threads repeatedly show up in the macOS desktop sidebar over the last few days. currently on 0.1.9-nightly.20261110.4452

   today i had an agent archive 786 stale subagent threads across my local projects. thats the bulk cleanup count, not the number of rows visibly resurfacing. i havent verified the parent snapshot cutoff in my case, so i can confirm the symptom rather than the exact cause

   this keeps creating sidebar clutter that needs manual cleanup. id appreciate prioritizing a fix here. is #28344 still the intended path?

   id appreciate prioritizing the existing fix in #28344 since this keeps requiring manual cleanup