Feature request: drag-to-reorder session groups + folder-linked groups (shared context, progress roll-up, concurrent-write gating)
Feature request: reorderable session groups + folder-aware groups (shared context, rolled-up logs, write-gating)
1. Let us drag/reorder groups in the sidebar
Newly created groups are pinned to the bottom of the list with no way to move them. If I create a group for the project I'm actively working on, it ends up below older, less-used groups. Please allow drag-and-drop reordering of groups (and ideally sessions within/between groups).
2. Assign folders to groups
Today we link a folder to a session at creation time. It would be more powerful to link a folder to a group, so the group becomes the unit of project organization:
- New sessions started inside the group inherit the folder automatically.
- The group could point at existing context (CLAUDE.md, memory, notes) that applies to all sessions/files in that group's chats, instead of each session rediscovering it.
3. Group/folder-level session log ("Progress" roll-up)
When working on 3 features across 3 parallel sessions in the same project, there's no shared record of overall progress. A group-level log that updates as its member sessions do work — "what changed across all sessions in this folder" — would make multi-session projects much easier to track and resume.
4. Folder-level write gating for concurrent sessions
The biggest pain point: multiple related sessions overwrite the same files at the same time — especially shared logs and memory/status docs. Some form of coordination at the folder/group level would help, e.g.:
- advisory locks or a write queue for files under the group's folder,
- conflict detection ("another session in this group modified SESSION_STATUS.md since you read it") instead of silent last-write-wins,
- or routing log/memory updates through a group-level triage step that merges rather than clobbers.
Environment
- Claude Code desktop app on Windows 11
- Heavy multi-session workflow: several concurrent sessions per project sharing one working folder and shared status/memory markdown files
3 Comments
+1 on folder-linked groups specifically — binding a sidebar group to a working directory so sessions started in that group inherit the project folder (and existing sessions in the group map to that path) would make the sidebar groups actually project-aware.
The folder-linked group idea solves a real coordination problem. Right now when I am running 3-4 parallel sessions on the same project, each session has to rediscover CLAUDE.md and project context independently on startup. A group that carries the project folder reference -- and by extension the shared context, notes, and settings -- would cut the per-session cold-start overhead substantially.
The progress roll-up piece is the other half of this. When a group of sessions is all working on features for the same release, having a group-level log that shows "session A completed task X, session B completed task Y, session C is blocked on Z" removes the need to manually check each pane. The orchestration overhead right now is almost entirely manual: switching panes, reading status, deciding what to hand off next.
On the concurrent-write gating point: this is the one I would prioritize if only one of these three ships first. Silent writes from two parallel sessions to the same file are the failure mode that is hardest to recover from. Even a lightweight "session B is currently editing src/config.rs -- do you want to wait or proceed?" warning would prevent most of the merge conflicts that currently come from running agents in parallel without worktrees.
One addition: it would be useful to be able to set a default model per group, so long-running background sessions in a group default to Sonnet and the active foreground session defaults to Opus. Right now that is a per-session setting with no group inheritance.
+1 to both halves, with a concrete case for the folder-linked part.
I work on one repo across 7 git worktrees (main checkout + 6 feature worktrees, each on its own branch). Session pinning can't express that, because a pin is per-session and carries no notion of where the session lives. The result is that the sidebar has no stable per-project structure — the thing I actually want to organize by is the folder, and that's exactly what #2 proposes.
The data for folder-linked groups already exists on disk. Worth noting since it lowers the cost of implementing #2:
~/.claude/jobs/<job-id>/state.jsonalready records the working directory:``
json
``{ "sessionId": "…", "cwd": "/Users/me/project-worktree-3" }
~/.claude/jobs/pins.jsonis a flat global array with nocwd(or project/group) key at all.So the association is already captured per session — the pin store just doesn't use it. Grouping by folder wouldn't require collecting anything new.
What this costs in practice: to work out which worktrees had unfinished work worth resuming, I ended up parsing ~96 session transcripts out of
~/.claude/projects/with a script — readingcwd+gitBranchoff each one and grouping them myself. That grouping is precisely what folder-linked groups would give me for free, and re-deriving it by hand doesn't survive to the next session. Note also that sessions started in a worktree whose CLI was launched from the parent checkout land under the parent's project dir, so even the on-diskprojects/layout doesn't cleanly separate worktrees.On #1 (reordering): same experience as reported — new groups pin to the bottom, so the group for whatever I'm actively working on sits below stale ones, and there's no way to move it.
Possibly consolidatable: #69343 and #73550 cover the drag-to-reorder half; #79098 (groups sort oldest-first with no reverse) is the same ordering problem from another angle.