Desktop: drag-to-reorder sessions intermittently fails since Split feature shipped

Update: found the root cause and fixed it locally.

Turns out it wasn't just drag to reorder. "Move to group" and "New group" from the context menu also did nothing. Signing out and back in didn't help, neither did restarting the app.

The problem was stale local state in ~/Library/Application Support/Claude/claude_desktop_config.json. There was an old preferences.epitaxyPrefs["dframe-group-scopes"] entry whose group assignments pointed only at sessions that had been deleted. As long as that entry was there, every group action in the sidebar silently no-op'd.

What fixed it for me:

1. Quit the app fully (it rewrites this file on exit, so edit while it's closed)
2. Back up claude_desktop_config.json
3. Delete the dframe-group-scopes block
4. Relaunch

Grouping and reordering worked again right away.

For the actual fix it would probably be enough to garbage collect group scopes that only reference deleted sessions (or validate them on load), and show an error instead of failing silently when the scope lookup fails.

macOS (Apple Silicon), app version 1.26832.0

Correction to my earlier comment. The root cause I posted there (a stale dframe-group-scopes block in claude_desktop_config.json) was wrong. Here is what I measured today, same version, 1.26832.0.

Deleting that block does not fix anything, and it does not even persist. With the app fully quit I removed it from both places it lives:

• localStorage key LSS-persisted.dframe-group-scopes (in Local Storage/leveldb)
• preferences.epitaxyPrefs["dframe-group-scopes"] in claude_desktop_config.json

Then relaunched. Two to three seconds after launch both were rewritten, byte identical to before, including group assignments pointing at sessions that were deleted days ago.

So I tried the opposite. With the app quit I seeded a valid scope for an account where grouping is dead, into both stores, in the app's own wrapper format. Twelve seconds after relaunch both stores were back to holding only the one pre-existing scope. The seeded scope was gone. The app does a full replace of dframe-group-scopes on launch, not a merge, so nothing written locally survives.

What that says about the actual bug:

This install has four accounts. Exactly one of them has a group scope, and that is the only account where sidebar grouping and drag-to-reorder work at all. On the other three, "New group" and "Move to group" appear to do nothing and drag-to-reorder does nothing. On one of those accounts creating a group did appear to work once, in the moment. That group no longer exists and no scope was ever written for that account, so the create was accepted by the UI and then silently discarded.

Nothing is logged when this happens. claude.ai-web.log grew by 0 bytes across a failed drag, a failed "New group" and a failed "Move to group".

A more useful framing than my earlier one: group creation is accepted by the UI but never persisted for accounts that do not already have a scope, and the launch-time replace discards anything written locally. Surfacing an error when the scope write fails, instead of failing silently, would have made this obvious from the start.

macOS, Apple Silicon, app 1.26832.0.

Correcting my previous comment, and this time with a workaround that works.

I said group creation is accepted by the UI and never persisted. That is wrong. Creating a new group works fine and persists across restarts, with the dragged session recorded in its assignments.

The real defect is narrower. preferences.epitaxyPrefs["dframe-group-scopes"] is keyed by scope. The sidebar can render groups belonging to a scope other than the currently active one. Those rows look completely normal, but their group IDs are not present in the active scope, so a drop onto them resolves to nothing and is discarded without an error. Same for "Move to group" onto one of them.

The result is a sidebar showing a mix of live groups (active scope, work correctly) and inert ones (other scope, silently swallow everything), with nothing visually distinguishing the two. That is what makes it look like "drag is broken" rather than "these particular groups are not in the active scope".

Workaround for anyone hitting this: create a new group and use that. Dragging into a newly created group works normally. Groups that predate the problem may belong to a stale scope and will never accept anything, so rebuild your grouping rather than trying to fix them.

Suggested fix: filter the sidebar to groups matching the active scope key, and fail loudly instead of silently when a drop resolves to a group ID outside it.

Two smaller notes from digging into this:

• The file is rewritten from the app's in-memory state a couple of seconds after launch, so editing dframe-group-scopes by hand while the app is closed has no effect. Anything hand written there is discarded on the next start. That is why my earlier suggestion to delete the block does nothing, and worth knowing for anyone else attempting a manual cleanup.
• Nothing is logged on a failed drop. claude.ai-web.log grew by 0 bytes across a failed drag, a failed "New group" and a failed "Move to group".

macOS, Apple Silicon, app 1.26832.0.