Surface sessions that have no tasks directory

[dgruhin-hrizn]

Fixes #18.

The bug

/api/sessions enumerates only TASKS_DIR. The comment above that loop reads:

// First, add sessions that have tasks directories

…but the second pass it implies was never written. Claude Code only creates a tasks directory once a session actually writes a todo, so any ordinary conversation that never used one is unreachable through any endpoint — no limit, filter, or sort will surface it.

On my machine that's 30 of 37 sessions invisible.

A strong hint this was always intended: fetchTasks already handles the 404 for a missing tasks directory, with a comment reading "Session has no tasks directory yet." Clicking one of these sessions already worked — there was simply no way to reach it.

The fix

Server — after the existing loop, add sessions known only from the transcripts in PROJECTS_DIR, with taskCount: 0 and hasTasks: false.

modifiedAt comes from the transcript's mtime rather than a directory's. Note the existing task-less fallback uses directory mtime, which Claude Code bumps when it removes its .lock at session end — so that timestamp reflects teardown rather than activity. I didn't repeat that here, and haven't changed the existing fallback in this PR.

Client — these render No tasks instead of a 0/0 progress bar, which otherwise reads as "nothing done yet" rather than "never had any".

Interactions, all checked

• "Active Only" is unchanged. It requires pending > 0 || inProgress > 0, and these sessions are all zero, so they were already excluded.
• Auto-archive absorbs most of them. Most are older than the 7-day threshold, so they land in the collapsed Archived disclosure rather than the main list.
• The default limit of 20 was the real risk, and it needed more than the obvious fix. Applied naively, 30 new sessions compete for those slots and the default view drops from 7 task-bearing sessions to 6 — a regression for anyone who only cares about sessions with tasks.

So the new "With Tasks" filter is applied server-side, before the limit, rather than client-side after it:

?limit=20              → 20 shown, 6 with tasks
?limit=20&withTasks=1  →  7 shown, 7 with tasks   ← exactly the old view

Filtering after limiting would quietly turn "20 most recent" into "however many of the 20 most recent happen to match". filterBySessions now refetches rather than only re-rendering, since that filter is no longer purely client-side; the client-side filter is kept as a no-op safety net so the option still behaves against an older server.

This is non-breaking by default

"With Tasks" is the default, so the out-of-the-box sidebar is byte-for-byte the view you have today — the 30 newly-reachable sessions are one click away rather than in your face. On my machine they outnumber the rest 30:7, and as a default they bury the thing you opened the app to look at.

Only the default changes. sessionFilter is written to localStorage solely by filterBySessions — i.e. only when a user picks something — so anyone who has explicitly chosen "All Sessions" keeps it. Verified both: a first run with no stored value lands on with-tasks with no implicit write, and a stored 'all' still loads as 'all'.

If you'd rather ship it the other way round, flipping the default is a one-line change.

Note on ordering

If you take #28 as well, that one keeps its short-id aliases in a separate cache specifically so this second pass — which iterates Object.entries(metadata) — doesn't manufacture phantom duplicate sessions from alias keys. They're order-independent either way.