[FEATURE] Desktop sidebar: option to show forks as top-level sessions instead of nested under the parent
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
Since the latest desktop app update (around Oct 6, 2026), forked sessions in the Code tab sidebar are shown nested under the session they were forked from.
I fork often, and many forks become independent topics. With nesting:
- a fork I'm actively using stays buried under an old parent session instead of appearing at the top of the list;
- "Sort by recency" no longer reflects what I worked on last, because nested forks are ordered inside their parent;
- inside a project group the list becomes a deep tree, which is harder to scan than the previous flat list.
My sidebar is set to Group by: project + Sort by: recency. That combination used to give exactly what I need: projects as groups, most recently active sessions at the top of each group.
Proposed Solution
Add a sidebar view option, for example "Nest forks under parent: on/off" in the filter menu, next to Group by and Sort by.
With it off, forks behave like any other session: they appear as top-level items in their project group and are sorted by last activity, like before the update.
Alternative Solutions
- Group by "none": removes the project grouping, which I want to keep, and forks still aren't top-level.
- Starting a new session instead of forking: loses the fork's context, so I have to paste it in manually.
Priority
Medium - Would be very helpful
Feature Category
Configuration and settings
Use Case Example
- I'm working in a project session and fork it to explore a side question.
- The fork turns into its own line of work, and I keep using it for days.
- Today it stays nested under the original session, which I no longer use, so I have to expand the parent to find it, and it doesn't rise to the top of the project group when I use it.
- With the option off, the fork would sit at the top of the project group like any other recently active session.
Additional Context
Environment: Claude desktop app, Code tab, Windows 11. Sidebar set to Group by: project, Sort by: recency.
Related: #95195 and #89471 ask for a parent/child tree. This request is the opposite preference, so an on/off option would serve both.
6 Comments
Same here (Windows 11, since the ~Oct 6 update). Two more problems beyond the nesting itself:
+1 for an on/off toggle.
+1 for side bar as a mod.
+1, with a related case that isn't only forks: sessions started by another session (e.g. task suggestions a coordinating "dispatcher" session spawns, which the user then launches) are also nested under their spawner, and
move_sessionsrefuses to file a nested session into a custom group on its own: "nested sessions move with their parent".In a multi-agent setup that makes custom groups unusable for organisation. One long-running dispatcher spawns 20–30 sessions across unrelated workstreams (customer service, photography, infra), and they can only live together under the dispatcher.
Suggestions, any of which would help:
detachstays the way to do this, document whether it's reversible and what it changes (messaging, thestartedByrelationship, listing).Windows, Code tab, desktop app.
+1, same problem on Windows 11 (desktop app 2.37337.1), and in my case it makes the sidebar unusable. I start each new task by forking the previous session to keep its context, so my sessions form long fork chains. In one of my custom groups, 145 of my 251 active sessions are forks of another active session, and almost all of them now sit under one single root session from September 25, simply because the session it was forked from no longer exists.
Three distinct problems:
Restarting the app and the computer changes nothing, and re-applying the group's view settings (group by none, sort by recency) has no effect. A "Nest forks under parent" toggle in the filter menu, off by default for existing users, would solve all three points.
Answering the question above about what "Detach to top level" actually does, since it is the only workaround today. I checked the session metadata file before and after detaching one fork: the only change is a new field, "lineageDetached": true. The "forkedFromSessionId" link is kept, and the session's custom sidebar group is not changed. After detaching, the session simply shows at the top level of its own group again, sorted by last activity like before the update.
So detaching is harmless and loses nothing, but it has to be done one session at a time from the right-click menu, which is not realistic with hundreds of forks. Two small things would already help a lot while the "Nest forks under parent" toggle is considered: allow "Detach to top level" on a multi-selection, or add a "Detach all forks in this group" action on the group header.
This change to collate sessions by fork structure has disrupted my multi-session workflow and made it completely unusable.
I run five or more sessions with different prompts and rotate among them in 1 to 2 side by side tabs. The old behavior was perfect where I could group sessions in my own categories.
Then I wake up and find that my sessions have scattered to the wind and there is no visual feedback indicating how the sessions are sorted into auto-generated bins. Because I'm an experienced programmer I could guess that they grouped by fork but this is far from intuitive for less experienced users.
Imagine this happening in Finder or File Manager where files in each directory gets binned into auto-generated buckets.
Please add a separate popup for group by like the finder does, and let group by fork be one of these Group By: (Date, Fork, Tag, none) and default to none.
Workaround for bulk detaching (worked for me on Windows, Claude Desktop 2.37337.1)
As found earlier in this thread, "Detach to top level" only adds
"lineageDetached": trueto the session's metadata file (on Windows%APPDATA%\Claude\claude-code-sessions\<account>\<org>\local_<id>.json, next to thespawnedFromfield that causes the nesting). This applies to forks as well as sessions started from chips. Doing that for all nested sessions at once, with the app closed, flattened 64 sessions for me, and my custom sidebar groups were kept.Since this edits undocumented app files and I could only test one setup, I'm not posting a script that assumes my file format. Instead, here is a prompt for Claude Code (CLI or a Desktop session) that verifies the format on your own machine first: