Desktop app: projects and slash commands vanish from sidebar despite ~/.claude.json being intact

[mghassanj]

Claude Code desktop app: projects and commands appear to disappear from UI despite being present in config

Summary

On the Claude Code desktop app (macOS), a project I work in daily repeatedly appears to "disappear" from the sidebar — along with slash commands I created in that project. Investigation shows the underlying data in ~/.claude.json is intact and even growing; the issue is strictly in the app's UI layer. This has now happened twice to the same project.

Environment

• OS: macOS (Darwin 25.3.0)
• Claude Code desktop app (Electron-based)
• Claude Code CLI alongside it
• Project path: /Users/mghassan/alsaif-automation
• Also actively using 3 git worktrees under .claude/worktrees/
• Running inside Cowork sandbox (coworkd present in logs)

What I observed

The "alsaif-automation" project — where I actively work and commit daily — vanished from the desktop app's project sidebar, as did custom slash commands I had defined during that project's sessions. When I opened the folder again manually, it reappeared, but without the session/command history I expected.

Evidence that data is intact

~/.claude.json is being rewritten frequently (5 times today), and I compared the 5 backups in ~/.claude/backups/:

Backup time	# projects	alsaif-automation present
06:15	11	yes
10:38	11	yes
11:24	11	yes
11:49	13	yes
13:41	13	yes
current	14	yes

The project list is growing, not shrinking, and the project in question is present in every snapshot. The issue is therefore not data loss in ~/.claude.json.

Hypothesis

• The app's sidebar appears to derive its list from Electron IndexedDB / LocalStorage state rather than (or in addition to) ~/.claude.json, and this state can get out of sync after updates/crashes/restarts.
• Worktree projects register as separate entries (3 of mine do), crowding the parent project out of the visible list.
• Project-level slash commands created through the app UI do NOT appear to be written to <project>/.claude/commands/ on disk (that folder doesn't exist for my affected project), so if they're only in Electron state, they're lost on any UI state reset.

Impact

• Lost visibility into active projects in the sidebar
• Custom slash commands I rely on appear unrecoverable
• Confusing — made me briefly think my code had been deleted
• Also causes duplicate project entries when the same repo is opened via two different paths (e.g. /Users/mghassan/Alsaif automations/alsaif-automation-app vs /Users/mghassan/alsaif-automation) — both are tracked as separate projects

Asks

1. Persist project-level slash commands to <project>/.claude/commands/*.md on disk so they survive UI state resets.
2. Make the sidebar render from ~/.claude.json authoritatively (or keep IndexedDB state a cache of it, not a separate source of truth).
3. Distinguish worktree entries visually from parent projects so they don't push the parent out of view.
4. Normalize project paths (case, trailing slashes, symlinks) so the same repo opened two ways doesn't register twice.

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Claude Desktop (macOS): Cowork and Claude Code tabs disappeared after working previously #49428
2. [BUG] Projects search returns ‘No projects match your search’ even though the project exists on web #50228
3. Desktop app: slash command autocomplete missing user-created commands #44060

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[0xbrainkid]

This fits the same class of control-plane/UI-state divergence we have been seeing all week: the underlying source-of-truth data is still present and updating, but the Desktop UI loses the ability to surface it coherently, so from the user's perspective the project and commands have "disappeared."

The evidence that ~/.claude.json still contains the project — and that backups keep preserving it — is the key point. This is not data loss. It is index/render loss.

That matters because the product behaves as if the project vanished even though the state is still there. Users then re-open folders manually, which can create the impression of a fresh project entry and sever continuity with the commands/session history they expected.

The likely failure modes are:

1. sidebar project index cache not rehydrating correctly from ~/.claude.json
2. worktree/cowork sandbox paths confusing the UI's notion of the canonical project root
3. slash command discovery being tied to the visible sidebar project object instead of the persisted project record

This is closely related to the broader pattern of hidden state surviving while visible state resets: task UI not rendering on resume, duplicated/vanishing sidebar entries, model/session identity mismatch, and plugin manifests drifting out of sync. Same family, different surface.

A robust fix would re-build the sidebar project index and command registry directly from persisted state on startup/focus, rather than trusting an in-memory cache that can go stale or lose the canonical project mapping.

[mghassanj]

Closing as a duplicate — this report is effectively covered by two existing open issues:

• Projects disappearing from the sidebar / search: [BUG] Projects search returns ‘No projects match your search’ even though the project exists on web #50228 — I've added my ~/.claude.json backup-comparison evidence as a comment there.
• User-created slash commands not showing in the desktop app: Desktop app: slash command autocomplete missing user-created commands #44060 — my finding that project-level commands are also affected (and not persisted to <project>/.claude/commands/ on disk) belongs there; I was blocked from commenting on that issue directly but the detail is preserved in this thread for anyone following up.

Thanks!

[github-actions]

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.