[FEATURE] Desktop sidebar: option to show forks as top-level sessions instead of nested under the parent

Status Open
Maintainer reply None cached
Activity 6 comments · opened Oct 7, 2026

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

  1. I'm working in a project session and fork it to explore a side question.
  2. The fork turns into its own line of work, and I keep using it for days.
  3. 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.
  4. 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.

View original on GitHub ↗

6 Comments

stoilsedyankovchaos · 5 days ago

Same here (Windows 11, since the ~Oct 6 update). Two more problems beyond the nesting itself:

  1. Forks deeper than ~33 levels are not shown at all, even with the thread expanded. In a 63-session chain, forks 34–36 disappeared from the sidebar while the thread stayed under "Today" because of their activity. Archiving older forks made them reappear.
  2. Nesting depends on the Last activity filter. Forks show flat when the original chat is older than the filter window, and nested when it's inside it. So the same chats change shape over time.

+1 for an on/off toggle.
+1 for side bar as a mod.

aperium · 13 hours ago

+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_sessions refuses 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:

  1. Allow filing a nested session into a custom group independently, while keeping the parent link (as a badge or a "started by" field), so the relationship stays visible.
  2. A per-spawn option to start the new session top-level (detached), so the relationship is kept in metadata only.
  3. If detach stays the way to do this, document whether it's reversible and what it changes (messaging, the startedBy relationship, listing).

Windows, Code tab, desktop app.

MamboJoel · 13 hours ago

+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:

  1. No way to flatten. I need an option to show forks as top-level sessions, sorted by last activity, exactly as before the October 6 update. This is the main request: the fork lineage is technical history, not how I organise my work.
  1. Children are not sorted by recency. Even if nesting stays, the sessions under a parent should follow the section's "Sort by: recency" setting. Today they seem to follow the fork tree order, so my most recent session can appear in the middle of the list, below sessions that are weeks old.
  1. Depth is flattened to one level. I have a chain of ten sessions, each one forked from the previous one, yet all of them are shown at the same indentation directly under the root. So the display is neither a flat list nor a real tree: grandchildren are not shown under their actual parent, and the order gives no hint of the lineage either.

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.

MamboJoel · 12 hours ago

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.

cabarius · 12 hours ago

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.

SiegfriedGlaser · 7 hours ago

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": true to the session's metadata file (on Windows %APPDATA%\Claude\claude-code-sessions\<account>\<org>\local_<id>.json, next to the spawnedFrom field 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:

I want to bulk-detach all nested sessions in the Claude Desktop Code tab sidebar, the same thing "Detach to top level" does for a single session. Please: 1. Find the session metadata folder of Claude Desktop on this machine (Windows: %APPDATA%\Claude\claude-code-sessions, macOS probably ~/Library/Application Support/Claude/claude-code-sessions). Read only, change nothing yet. 2. Ask me to detach one nested session via right-click, then compare its file with a still nested one. Only continue if detaching just added "lineageDetached": true and nested sessions carry spawnedFrom. Otherwise stop and tell me what you found. 3. Write a script that refuses to run while Claude Desktop is running, backs up the whole folder first, adds the field exactly the way the app does to every session with spawnedFrom and without lineageDetached, and only writes a file if the parsed result equals the original plus that one field. Give it a preview mode, run the preview and show me what would change. 4. Since the app has to be closed for the real run, give me the exact command to run in a separate terminal window (not the app's built-in terminal), and tell me how to restore the backup.
[!WARNING] Unofficial and at your own risk.
[!IMPORTANT] Still, please add a setting for a flat sidebar, nobody should need a workaround like this.