[Regression] Desktop app: session time-range filter only appears when Group by is set to State

Confirming this also is happening on Windows under the same Claude Code Desktop version

Confirming this on macOS as well, with an additional grouping mode: the time-range/recency filter is also absent under Group by = Project (you tested Custom groups).

My filter popover with Group by = Project shows only:

• Status (Active)
• Environment (All)
• Group by (Project)
• Sort by (Recency)

No "Last activity" / time-range row anywhere in the menu. Sort by → Recency is still present and selected, but that only reorders — it doesn't cut the list down to recent sessions, so it's not a substitute for the missing filter.

So across the groupings reported so far, the time-range filter appears only under Group by = State, and is hidden under both Project and Custom groups — consistent with the filter being coupled to the grouping mode rather than removed outright. Same build (1.22209.0).

Confirmed. MacOS Sequoia, Claude ver. 1.22209.0

Also seeing this on macOS, Claude version 1.24012.1. Sorting by Recency really isn't a substitute. Very old "Active" sessions stay mixed in without a date label, so it's annoying to keep sessions organized

Confirming on macOS. Claude Desktop 1.22209.3, macOS 26.3.1 (25D771280a), Code tab.

Same regression: after the recent app update the Last activity filter (1d/3d/7d/30d/All) vanished from the Sessions sidebar. It only reappears when Group by = State; with any other grouping the row is gone entirely, so it looks like the feature was removed. With a large session history this makes finding recent sessions very hard.

+1 for restoring the Last activity filter across all Group by modes

Root cause, plus evidence this is a removal rather than a feature that never existed. Windows 11, Claude Desktop 1.24012.9.0 (package installed 2026-07-25) — still reproduces.

Where it's gated

In the renderer bundle (resources/ion-dist/assets/v1/shared-17-*.js) two separate things are keyed off the current Group by value:

// 1. whether the menu row renders at all
const R = "state" === groupBy;
R && <Submenu label="Last activity" options={[1d, 3d, 7d, 30d, All]} ... />

// 2. the value that actually filters the rows
activityDays: "state" === groupBy ? stateActivityDays : 0   // 0 = no cutoff

So even if the row were shown under the other groupings, the cutoff would still be 0. Both the control and the filter behind it are coupled to Group by = State. It's a plain string comparison rather than a feature flag, so there is nothing user-side to toggle.

This is the same expression for every other mode, which matches the reports across this issue and #78829: Project, Date, Custom groups and None all resolve to 0.

Evidence this is a regression

The preference used to have its own grouping-independent storage key, and my profile still contains it, orphaned:

%APPDATA%\Claude\Local Storage\leveldb
  →  LSS-code-sessions-activity-days-filter = {"value":7}

Grepping every JS bundle in the current build for that key and its neighbours:

code-sessions-activity-days-filter  ->  NOT referenced anywhere in 1.24012.9.0
code-sessions-state-activity-days   ->  shared-2-*.js
code-sessions-show-empty-projects   ->  shared-2-*.js

An earlier build persisted a general activity-days-filter value. The current build reads only the State-scoped state-activity-days key and never looks at the old one. The old setting is still sitting in user profiles with its last value, unreachable from any UI.

Group by = State is not a usable workaround

Worth flagging since it is the obvious suggestion: in code mode the State renderer buckets sessions into flat state-working / state-done / … lists with no project headers. So the single grouping that exposes the filter is also the one that discards project separation — which is exactly what people on Group by = Project are trying to keep. There is currently no combination that gives both.