[BUG] Claude Desktop (macOS): Unpinned conversations persistently reappear in Pinned sidebar — survives unpin, restart, and cache wipe; profile instructions also stale vs. web

Resolved 💬 4 comments Opened May 11, 2026 by Jason017 Closed May 14, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

[BUG] Claude Desktop (macOS): Unpinned conversations persistently reappear in Pinned sidebar — survives unpin, restart, and cache wipe; profile instructions also stale vs. web

Environment

  • macOS version: macOS Sonoma 14.6.1
  • Claude Desktop version: Claude 1.6608.2 (ebf1a1) 2026-05-08T23:17:27.000Z
  • Plan: Pro

Summary

Three conversations that were previously pinned cannot be permanently unpinned in Claude Desktop. They reappear in the Pinned sidebar section every time a new project is pinned. The issue persists across app restarts, web-side unpin, and local cache deletion — suggesting the pin state is stored in a location that none of the standard user-accessible cleanup methods can reach.

Steps to Reproduce

  1. Pin several conversations and projects in Claude Desktop
  2. Unpin the conversations (keep projects pinned)
  3. Pin any new project
  4. Result: The previously unpinned conversations reappear in the Pinned section
  5. Restart Claude Desktop → they persist
  6. Unpin them again → pin another project → they reappear again

Diagnostic Steps Taken

1. Verified server-side state via web

  • Opened claude.ai in browser with the same account
  • The 3 conversations showed as pinned on web — confirming server-side pin state was still set
  • Manually unpinned all 3 on web
  • Confirmed they were unpinned on web

Result: Desktop app still showed them as pinned after restart.

2. Cleared Electron local storage

Quit Claude Desktop, then ran:

rm -rf ~/Library/Application\ Support/Claude/Local\ Storage
rm -rf ~/Library/Application\ Support/Claude/IndexedDB

Relaunched the app.

Result:

  • App did NOT require re-login (session token likely stored in Keychain)
  • The 3 conversations still appeared in the Pinned section
  • This rules out Local Storage and IndexedDB as the persistence layer for pin state

3. Current state

  • Web (claude.ai): 3 conversations are unpinned ✅
  • Desktop app: 3 conversations still pinned ❌ — even after cache wipe + restart

4. Profile instructions also desynchronized

Discovered that the "Instructions for Claude" in Desktop app Settings shows a significantly older version than what is currently saved on claude.ai web. This confirms the desync is not limited to pin state — the Desktop app appears to be reading from a stale local cache for multiple types of user data (pins, profile preferences, possibly more).

Analysis

| Attempted fix | Pin state cleared? |
|---|---|
| Unpin in Desktop app | ❌ Reappears on next project pin |
| Restart Desktop app | ❌ Persists |
| Unpin on claude.ai web | ❌ Desktop ignores web state |
| Delete Local Storage + IndexedDB | ❌ Persists |

This means:

  1. Desktop app's unpin action does not propagate to whatever storage layer it reads from
  2. Pin state is not stored in Local Storage or IndexedDB
  3. Desktop app does not read pin state from the server (web unpin has no effect)
  4. The pin state is persisted in an unknown local location that survives targeted cache deletion

Expected Behavior

  • Unpin action should be permanent
  • Pin state should sync bidirectionally between desktop app and claude.ai web

Actual Behavior

  • Unpin is effectively a no-op on desktop — the state is silently restored
  • Desktop and web pin states are completely desynchronized

Not Yet Attempted

  • Full wipe of ~/Library/Application Support/Claude/ and ~/Library/Caches/Claude/ (would require re-login and full state reset — documenting this before attempting)
  • Reinstall of Claude Desktop

Related Issues

  • #50377 — Pinned projects become undismissable zombies after deletion (same persistence layer issue)
  • #50749 — Sidebar state derived from Electron IndexedDB can get out of sync
  • #47522 / #50856 — Sidebar empty on desktop while web works fine (desktop/server state desync pattern)

What Should Happen?

  1. Unpin action in Desktop app should permanently remove

conversations from the Pinned section

  1. Pin/unpin state should sync bidirectionally between

Desktop app and claude.ai web

  1. Profile instructions (and other user settings) should

reflect the latest server-side version, not a stale
local cache

  1. Clearing local cache (Local Storage, IndexedDB) should

force the app to re-fetch current state from server
on next launch

Error Messages/Logs

Steps to Reproduce

Pin bug:

  1. Pin several conversations and projects in Claude Desktop
  2. Unpin the conversations
  3. Pin any new project
  4. Previously unpinned conversations reappear in Pinned section
  5. Restart app → still there
  6. Repeat unpin → pin new project → they reappear again

Additional diagnostics performed:

  1. Checked claude.ai web — same 3 conversations showed as

pinned (confirming server state was never updated by
desktop unpin)

  1. Unpinned all 3 on web → restarted desktop → still pinned

on desktop

  1. Quit app, deleted ~/Library/Application Support/Claude/Local Storage

and ~/Library/Application Support/Claude/IndexedDB, relaunched
→ app did NOT require re-login → conversations still pinned
→ rules out Local Storage and IndexedDB as persistence layer

Profile instructions desync:

  1. Opened Settings > General > "Instructions for Claude" in

Desktop app — shows an outdated version

  1. Opened same setting on claude.ai web — shows the current

(much newer) version

  1. Desktop app is reading stale user profile data

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

1.6608.2

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗