[Feature request] Sort the completed background-job list by last activity, not creation time

Type: Feature request
Area: Background jobs / job list
Version: claude-code 2.1.220

What happens now

The completed section of the background-job list is ordered by when each job was
created. Jobs don't stay finished, though — you resume them, and a job you
worked on this morning can have been created weeks ago. It stays pinned near the
bottom of the list, below jobs you haven't touched since.

The effect is that the jobs I'm actually working with are the hardest ones to
find, and they get harder to find the longer I keep using them.

What I'd expect

Completed jobs sorted most-recently-active first, keyed on updatedAt.

Why this should be cheap

The timestamp already exists. Each job's state.json under ~/.claude/jobs/<id>/
carries createdAt, updatedAt, and firstTerminalAt. updatedAt is already
written on every state transition. This looks like a change of sort key, not new
plumbing.

Scale of the difference

Measured across the 64 non-running jobs on my machine:

| sorted by | positions that change vs. creation order | largest single move |
| --- | --- | --- |
| updatedAt | 60 of 64 | 54 places (#58 → #4) |
| firstTerminalAt | 12 of 65 | 1 place |

Two jobs move more than 50 places under updatedAt. This is not a marginal
reordering.

Please don't use firstTerminalAt

It looks like the obvious key for a list of finished things, and it is the wrong
one. firstTerminalAt is written once, the first time a job reaches a terminal
state, and preserved on every write after that. But jobs resume. Mine finish
fast and then stay in use for weeks:

• Median runtime from createdAt to firstTerminalAt is 4 minutes (p90: 28

minutes). So firstTerminalAt lands a few minutes after createdAt, and
ordering by it reproduces creation order almost exactly — hence the 12-of-65
above. It doesn't fix anything.

• One job first went idle after 2 minutes, then accumulated **208 timeline

entries across 5 distinct days spanning a month** — including 9 working and
9 blocked transitions after that first done. It kept doing real work.
firstTerminalAt still reports the 2-minute mark.

• Another was last active today; its firstTerminalAt says June 24.

I checked whether updatedAt is inflated by idle heartbeat rather than real
interaction. It isn't — the writes are bursty, clustered into work sessions
(26 of 30 and 171 of 207 inter-event gaps under 5 minutes, on 4–5 distinct days),
which is what genuine use looks like, not a timer.

Nice-to-have

A toggle if the default is contentious — but for a list of things you return to,
most-recently-active is the right default.