Sidebar: option to show the oldest active thread at the top

[jpsirois]

Problem
Every thread sort in T3 Code puts the newest thread first. Sidebar V2 sorts active threads by creation time, newest first. The legacy sidebarThreadSortOrder accepts updated_at or created_at, but both sort descending.

I work through my threads as a queue, oldest first. Each new thread appears above the work I already queued. To keep the order, I must drag every new thread down.

Proposal
Add a sort direction (newest first / oldest first) for the active thread list. Keep newest first as the default. The sort is in packages/client-runtime/src/state/threadSort.ts, so web and mobile get the same order.

Open questions

• Is this a separate setting, or a third option next to the sort key from Honor sidebarThreadSortOrder in Sidebar V2 as an opt-in #9233?
• With oldest first, does a new thread go to the bottom of a manually ordered list (activeOrderKey)?
• Does an un-settled thread go to the top or the bottom?

Related: #6964, #9233, #6985

[baptisteArno]

Note

🤖 Claude Opus 5.5 responding on behalf of Baptiste

+1. Now that the Working section is on by default, I think this got a lot simpler.

With Working and Snooze on, the active list only holds threads that need me, ordered by when each one came back to me. That's already a queue, read from the wrong end: the latest return goes on top. I'd like it at the bottom, so I pop from the top.

Why oldest first fits that flow:

• The thread that has waited on me the longest sits at the top. I answer it, it goes back to Working, I take the next one. No thread gets buried for hours under newer returns.
• The top of the list stops moving. Today every finished run inserts a row at the top and pushes down the one I was about to click. With oldest first, returns append at the bottom and the row I'm handling stays put. Same spirit as fix(clients): Working section keeps its order while agents finish and wake #15418, which stopped Working rows from jumping on every wake.
• The Snoozed shelf already lists the soonest wake first.

It looks like a direction on sortInboxThreadsByReturn in packages/client-runtime/src/state/threadInbox.ts, so web and mobile would get it together. The return-time key stays the same.

That also answers the open questions above when Working is on. Drag order is already off in the active list, and a thread joins at the bottom whenever it comes back to you: new, un-settled, woken from snooze, or done working.

Settled can stay newest first since it's history.

[mseibert]

+1. My reason is coverage: I want to be sure every thread that comes back to me actually gets worked on, not just the most recent ones. With newest first, a thread that returned in the morning sinks below everything that came back after it, and by evening I don't look at it anymore. Oldest first turns the active list into a queue I can work from the top, and nothing gets left behind.

Newest first as the default is fine with me. A per-user setting for the direction would be enough.

[baptisteArno]

Most likely to get merged 🤞 #26380 give it some love