Area
apps/web, packages/client-runtime
Version
0.0.46-nightly.20261003.2632 (also reproduced the same sort-key shape in 0.0.45 stable)
Steps to reproduce
- Have several threads in one project.
- Send a follow-up message in an older thread (or let a run complete on it), so its
updatedAt / latestUserMessageAt / latestRun.completedAt advance to "now".
- Look at the left Threads inbox (the flat list, not a project page).
Expected
The recently-active thread surfaces near the top — consistent with sidebarThreadSortOrder: "updated_at" ("Last user message"), and consistent with the thread-list API, which already returns newest-updatedAt first.
Actual
The inbox stays in createdAt descending order no matter how much activity happens. Concrete case from my workspace: a thread created Oct 5 with a new user message and a completed run today at 08:45 sits at position 10 of 18 (exactly its creation rank) instead of near the top. Refreshing / hard-refreshing changes nothing.
Root cause (verified against the running client)
The flat inbox path never feeds activity timestamps into its sort keys, even though the client thread objects carry fresh ones (confirmed via a React-fiber dump of a rendered row: latestRun.requestedAt/completedAt, latestUserMessageAt, updatedAt are all current):
sortActiveThreadsByOrderKey (packages/client-runtime/src/state/threadSort.ts) falls back to activeThreadAnchorTimestampMs = max(createdAt, unsettledAt) when activeOrderKey is null (the common case) — updatedAt / latestUserMessageAt / latestRun never participate.sortInboxThreadsByReturn (packages/client-runtime/src/state/threadInbox.ts) = max(createdAt, unsettledAt, latestRun.requestedAt, latestRun.completedAt, observedReturnAt) — likewise no updatedAt / latestUserMessageAt. (0.0.45's equivalent has the same shape.)
Compounding it: the web flat inbox exposes no thread-sort control at all — Settings has "Project order" only, and the "Sidebar options → Sort threads" popover only mounts in the project-grouped sidebar variant, which the web main view does not render. So users can neither fix nor work around the ordering.
Verification note
I locally patched both maxima to also include updatedAt, latestUserMessageAt, and latestRun bounds and confirmed the live list re-sorts correctly (the stale thread above jumped from #10 to #3). Happy to open a PR, but flagging: sortActiveThreadsByOrderKey's docstring currently documents static order ("activity leaves both groups in place"), so this may be an intended-behavior decision rather than a plain bug — filing as an issue per CONTRIBUTING and leaving the call to maintainers.
Area
apps/web, packages/client-runtime
Version
0.0.46-nightly.20261003.2632 (also reproduced the same sort-key shape in 0.0.45 stable)
Steps to reproduce
updatedAt/latestUserMessageAt/latestRun.completedAtadvance to "now".Expected
The recently-active thread surfaces near the top — consistent with
sidebarThreadSortOrder: "updated_at"("Last user message"), and consistent with the thread-list API, which already returns newest-updatedAtfirst.Actual
The inbox stays in
createdAtdescending order no matter how much activity happens. Concrete case from my workspace: a thread created Oct 5 with a new user message and a completed run today at 08:45 sits at position 10 of 18 (exactly its creation rank) instead of near the top. Refreshing / hard-refreshing changes nothing.Root cause (verified against the running client)
The flat inbox path never feeds activity timestamps into its sort keys, even though the client thread objects carry fresh ones (confirmed via a React-fiber dump of a rendered row:
latestRun.requestedAt/completedAt,latestUserMessageAt,updatedAtare all current):sortActiveThreadsByOrderKey(packages/client-runtime/src/state/threadSort.ts) falls back toactiveThreadAnchorTimestampMs=max(createdAt, unsettledAt)whenactiveOrderKeyis null (the common case) —updatedAt/latestUserMessageAt/latestRunnever participate.sortInboxThreadsByReturn(packages/client-runtime/src/state/threadInbox.ts) =max(createdAt, unsettledAt, latestRun.requestedAt, latestRun.completedAt, observedReturnAt)— likewise noupdatedAt/latestUserMessageAt. (0.0.45's equivalent has the same shape.)Compounding it: the web flat inbox exposes no thread-sort control at all — Settings has "Project order" only, and the "Sidebar options → Sort threads" popover only mounts in the project-grouped sidebar variant, which the web main view does not render. So users can neither fix nor work around the ordering.
Verification note
I locally patched both maxima to also include
updatedAt,latestUserMessageAt, andlatestRunbounds and confirmed the live list re-sorts correctly (the stale thread above jumped from #10 to #3). Happy to open a PR, but flagging:sortActiveThreadsByOrderKey's docstring currently documents static order ("activity leaves both groups in place"), so this may be an intended-behavior decision rather than a plain bug — filing as an issue per CONTRIBUTING and leaving the call to maintainers.