Feature request: FleetView (`claude agents`) should show the repo/project per session row
Problem
When running claude agents (FleetView), the interactive list groups sessions by status (Needs input / Working / Completed). Each row shows the session name + status summary + age, and the header shows a single cwd. But when you have many concurrent sessions spread across different repos/projects, there's no way to tell which project a given row belongs to without opening it.
Proposed Solution
Surface the repo/project per row in the interactive FleetView — e.g. a short repo label (basename of the session's cwd) shown as a column or prefix on each row.
Nice-to-haves:
- Optional grouping/sorting by repo.
- Color-code rows by repo.
Why This Matters
The data already exists — claude agents --json exposes cwd for every session — it's just not surfaced in the interactive UI. With background agents running across several repos at once, the status grouping alone isn't enough to orient yourself.
Current Workaround
A small wrapper over claude agents --json that prints a repo column per row. It works for a static overview but can't replace the navigable FleetView (you can't enter/manage a session from it).
Related
Related to #68104 (repo-scoped filtering), but distinct: that issue is about which sessions are shown; this is about displaying the repo on each row so you can tell them apart.
Environment
Claude Code v2.1.181, macOS (arm64), native install.
Showing cached comments. Read the full discussion on GitHub ↗
4 Comments
+1. This is the exact gap I hit. One refinement on the proposed label: basename-of-
cwdalone doesn't disambiguate the most confusing case, which is multiple worktrees of the same repo running at once. Those all share the repo basename (and sit under<repo>/.claude/worktrees/<name>), so a basename column would still render them identically, precisely when I can't tell sessions apart today.Suggestion: when a session's
cwdis a worktree, show the worktree/leaf segment (or branch name) alongside or instead of the repo basename, e.g.my-app:feat-xrather than justmy-app. For non-worktree sessions the plain repo basename is fine. The data is already inclaude agents --json(cwd), so this is presentation-only. Color-coding and optional group-by-repo (your nice-to-haves) would compound this nicely.Concrete symptom of this gap: I've started running
pwdas the first command in nearly every session just to confirm which directory/worktree it's attached to, because the FleetView row doesn't tell me. Surfacing the repo/worktree per row would remove that ritual entirely.cc @bogini @ashwin-ant (given the related
--cwdfilter work) in case the per-row display fits alongside it.The worktree disambiguation case that nickponomar flagged is the crux of this. basename-of-cwd breaks the moment you have two worktrees of the same repo, which is exactly the workflow where FleetView is most useful.
A few things that might help the implementation decision:
The
claude agents --jsonoutput already has cwd per session. From there you have a few rendering options:The two-column approach is the most scannable in practice. You get the repo at a glance and the worktree name tells you what the session is doing. The color-by-repo-root layer makes it fast to group before you read.
One thing worth noting: I've been running a separate poller process that reads ~/.claude/jobs/*/state.json and writes a minimal status file per session (cwd, name, status, last-activity) as a stopgap until FleetView renders this natively. The data is definitely there - it's purely a display problem.
This is the core visibility gap that motivated a lot of external tooling in this space. Once you are running sessions across more than two or three repos simultaneously, the session list becomes unreadable without a project label -- you are matching session IDs against terminal tabs or guessing from the task headline.
Two things that would help beyond the repo path: (1) the project root per session row, and (2) whether the session is actively writing to the filesystem or just idle. Right now both require you to open the session or read the JSONL yourself.
I am building an out-of-process observer for this (Claudeverse -- disclosing upfront since it is adjacent to this request). The project-per-row problem was the first one users asked about. Happy to share what data is readable from the outside if that helps the Anthropic-side implementation.