Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] Sidebar session-list sort preference is not persisted — reverts on every relaunch [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#48242•Fetched 2026-04-15 06:29:11
View on GitHub
Comments
1
Participants
2
Timeline
2
Reactions
0
Author
Asher-Asher-
Participants
Asher-Asher-github-actions[bot]github-actions[bot]
Timeline (top)
commented ×1labeled ×1

Root Cause

That is definitive. The preference is not being written to any client-side store. Two possible root causes:

Fix Action

Fix / Workaround

  • Tokens cost money. Every workaround for a broken client is billed against my API usage. Every re-navigated session because the sort reverted is tokens I'm spending to recover from your bug, not to do my work.
  • Subscription cost. I'm paying for a product that ships regressions without the preferences needed to opt out of them. Interface changes are pushed without toggles. Workflow changes are pushed without migration paths. Lag is pushed and treated as polish, not as a defect.
  • Trust cost. If a five-line localStorage persistence bug ships and then sits, I have zero confidence that the higher-risk surfaces (session data integrity, sync, permissions, tool approvals) are being held to any higher bar. The cheap, visible, trivially-testable defect is the canary.
  • Feedback loop cost. Prior reports of similar-class defects have not visibly produced fixes, changelog entries, or acknowledgments. Silent triage is indistinguishable from no triage.
RAW_BUFFERClick to expand / collapse

[BUG] Sidebar session-list sort preference is not persisted — reverts on every relaunch

Filing to: https://github.com/anthropics/claude-code/issues/new?template=bug_report.yml Suggested labels: bug, platform:macos, area:desktop Related (not a duplicate): #46810 (that's a feature request for manual reordering; this is a regression/defect report that the existing sort option does not persist).

Preflight Checklist

  • Searched existing issues — no open bug report for sidebar session sort persistence on the desktop app.
  • Single bug report.
  • Using the current release of Claude for Desktop (com.anthropic.claudefordesktop, /Applications/Claude.app).

What's Wrong?

The sidebar's session-list sort option does not persist. Every relaunch (and in some cases a reload) reverts the sort order back to the default. I have to re-select my preferred sort every single time I open the app. This is not a new-user paper-cut — it is billed work-time friction compounded over weeks and it is absolutely unacceptable in a paid product.

This report is blunt on purpose. Read the "Evidence" section before triaging this as "minor polish." It is a five-line fix and it has been shipping broken.

What Should Happen?

The user's selected sort order is persisted (either locally on disk, or server-side against the user account) and is the order shown on next launch / reload. Same as literally every other desktop app with a sortable list that has shipped in the last twenty years.

Evidence — this is a confirmed persistence defect, not speculation

I inspected every location where a macOS Electron app of this shape could reasonably store a user preference. The preference is not being written anywhere on disk.

LocationResult
~/Library/Preferences/com.anthropic.claudefordesktop.plistNo sort-related key.
~/Library/Application Support/Claude/config.jsonNo sort-related key.
~/Library/Application Support/Claude/Local Storage/leveldb/*.{log,ldb}strings | grep -i sort → zero matches.
~/Library/Application Support/Claude/IndexedDB/https_claude.ai_0.indexeddb.leveldb/*.{log,ldb}strings | grep -i sort → zero matches.

That is definitive. The preference is not being written to any client-side store. Two possible root causes:

  1. Pure client bug — the dropdown is bound to ephemeral React state. No persistence layer was ever wired up. Every reload reverts to the useState initial value. If this is the cause, it is a five-line fix (useEffect + localStorage.setItem / getItem, or whatever your preferences module exposes).
  2. Server-side save is failing silently — the UI calls a user-preferences endpoint that is swallowing errors, erroring on auth refresh, or not deployed. Reload fetches server defaults.

Either way, this shipped in a paid desktop client. The diagnosis is pre-done for you. Fix it.

Steps to Reproduce

  1. Launch Claude for Desktop on macOS.
  2. In the sidebar, change the session-list sort option to anything other than the default.
  3. Quit the app (⌘Q).
  4. Relaunch the app.
  5. Observed: sort order has reverted to the default.
  6. Expected: sort order is the one selected in step 2.

Reproduces 100% of the time.

Environment

  • macOS
  • App: Claude for Desktop (Electron), bundle ID com.anthropic.claudefordesktop
  • App path: /Applications/Claude.app
  • Account: paid subscriber

Why this report is aggressive

Because this defect, and the pattern it sits inside, is costing me real money and real time:

  • Tokens cost money. Every workaround for a broken client is billed against my API usage. Every re-navigated session because the sort reverted is tokens I'm spending to recover from your bug, not to do my work.
  • Subscription cost. I'm paying for a product that ships regressions without the preferences needed to opt out of them. Interface changes are pushed without toggles. Workflow changes are pushed without migration paths. Lag is pushed and treated as polish, not as a defect.
  • Trust cost. If a five-line localStorage persistence bug ships and then sits, I have zero confidence that the higher-risk surfaces (session data integrity, sync, permissions, tool approvals) are being held to any higher bar. The cheap, visible, trivially-testable defect is the canary.
  • Feedback loop cost. Prior reports of similar-class defects have not visibly produced fixes, changelog entries, or acknowledgments. Silent triage is indistinguishable from no triage.

What I expect from this issue

  1. Acknowledgment that the ticket was received and triaged, with a tracking status I can check.
  2. A fix — the evidence above localizes the defect to one of two code paths. Land it in the next release.
  3. Stop shipping default-behavior changes without a preference to revert them. If a new behavior is worth shipping, it is worth making opt-out-able during the transition window. This is basic product discipline.
  4. Publish an accessible changelog for the desktop app. Users should not have to diff bundles to find out what changed between releases.
  5. Treat responsiveness regressions as bugs. Lag in a paid desktop client is a defect, not a polish item to be pushed behind unrelated feature work.

This is not a nice-to-have report. A paying subscriber should not have to decompile storage layers to diagnose whether a basic UI toggle is persisted. The fact that the diagnosis was this easy is itself the indictment.

Fix it.

— Asher

extent analysis

TL;DR

The most likely fix for the sidebar session-list sort preference not persisting is to implement a persistence layer using localStorage or a similar mechanism to store the user's selected sort order.

Guidance

  • The issue is likely caused by the dropdown being bound to ephemeral React state without a persistence layer, causing the sort order to revert to the default on every relaunch.
  • To verify, check if the useState initial value is being used as the default sort order, and if the useEffect hook is not being used to persist the user's selected sort order.
  • Implement a persistence layer using localStorage or a similar mechanism to store the user's selected sort order, such as using localStorage.setItem and localStorage.getItem to store and retrieve the sort order.
  • Alternatively, investigate if the server-side save is failing silently and fix the issue with the user-preferences endpoint.

Example

import { useState, useEffect } from 'react';

function SessionList() {
  const [sortOrder, setSortOrder] = useState('default');

  useEffect(() => {
    const storedSortOrder = localStorage.getItem('sortOrder');
    if (storedSortOrder) {
      setSortOrder(storedSortOrder);
    }
  }, []);

  const handleSortOrderChange = (newSortOrder) => {
    setSortOrder(newSortOrder);
    localStorage.setItem('sortOrder', newSortOrder);
  };

  // ...
}

Notes

The provided code snippet is a basic example and may need to be adapted to the specific use case. Additionally, the issue may be caused by a server-side problem, in which case the fix would involve investigating and resolving the issue with the user-preferences endpoint.

Recommendation

Apply a workaround by implementing a persistence layer using localStorage or a similar mechanism to store the user's selected sort order, as this is a relatively simple fix that can be implemented quickly.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#mixed precision#training loop#device allocation#model download

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] Sidebar session-list sort preference is not persisted — reverts on every relaunch [1 comments, 2 participants]