[BUG] `/clear` in Claude Desktop resets current session in-place instead of creating a new session

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/59534
2. https://github.com/anthropics/claude-code/issues/61172

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

These are not duplicates:

• #59534 — similar /clear session-preservation failure in CLI (closed stale); my bug is the desktop-app manifestation and is more extensive
• #61172 — open CLI issue for the name-inheritance half of the same problem; my bug is on the desktop app and is more extensive

/clear leaves the original transcript file on disk but resets the metadata file that points to it. That is why the sidebar row becomes "General coding session" and opens with "No messages yet" even though the conversation history is still under ~/.claude/projects/<project-slug>/.

I built BasedGPT/claude-code-session-recovery for this orphaned-session case. Run python tools/diagnose.py first; it maps the metadata files against the transcript files and prints the exact repair command when the original transcript survives. Check the original UUID under ~/.claude/projects/ before changing anything, save the diagnosis output, and quit Desktop fully before applying the printed metadata repair.

The upstream behaviour still needs fixing so /clear creates a new session-list entry, but the on-disk check separates that product bug from a genuinely missing transcript.

Hope this helps, if my tools are able to help you, would appreciate a ⭐ :)

Just ran into this. I had Claude diagnose it, and here's what it came up with:

/clear orphans conversations from the desktop app's session history sidebar

Summary

In the Claude desktop app, the session history sidebar keeps one entry per window, not one per conversation. That entry stores a single cliSessionId pointing at the current transcript. Running /clear starts a new transcript on disk but overwrites cliSessionId in place rather than creating a new history entry.

The result: every conversation you /clear away becomes unreachable from the sidebar, even though its transcript is fully intact on disk. There is no in-app way to list or reopen it.

In my case the sidebar showed 1 entry for a directory that had 5 transcripts on disk.

Environment

| | |
|---|---|
| Claude desktop app | 1.30096.1 |
| Claude Code CLI | 2.1.231 (session process reported 2.1.229) |
| macOS | 26.6.1 (arm64) |

Reproduction

1. Open a project directory in the Claude desktop app.
2. Have a conversation.
3. Run /clear.
4. Have another conversation.
5. Open the session history sidebar.

Expected: both conversations listed, each reopenable.

Actual: one entry, labelled with the generic "General coding session" placeholder. The pre-/clear conversation is absent and cannot be reopened from anywhere in the app.

Mechanism

There are three separate session stores, and the app-side one does not track a /clear:

| # | Path | Contents |
|---|---|---|
| 1 | ~/.claude/projects/<encoded-cwd>/<uuid>.jsonl | The real transcripts. One per /clear. What claude --resume reads. |
| 2 | ~/.claude/sessions/<pid>.json | Live process registry, running sessions only. Carries an entrypoint field (claude-desktop / claude-vscode) and a messaging socket path. |
| 3 | ~/Library/Application Support/Claude/claude-code-sessions/<a>/<b>/local_<uuid>.json | The app-side records backing the sidebar and the list_sessions MCP tool. |

Store 3 is the problem. A record looks like this:

{
  "sessionId":    "local_a7e30419-344b-4d57-87a2-e0db4b557391",
  "cliSessionId": "d2bfb906-f919-4fac-aede-a1715c301766",
  "cwd":          "/Users/jay/Migration",
  "createdAt":    1786727715071,
  "lastActivityAt": 1786741689874
}

createdAt is 12:15. The referenced cliSessionId belongs to a session that started at 15:53. In the intervening three and a half hours the same window produced two other transcripts:

e66b295f-ae5b-49dd-969d-90d17e328a20   15:45   693 messages   1.4 MB
88299136-2419-41a8-b6ff-7bcd859406bc   15:50    25 messages

Neither has a local_ record of its own. Each was the value of cliSessionId in local_a7e30419 at some point and was overwritten by the next /clear.

Across the whole machine: 5 local_*.json records total, against 5 transcripts in this one project directory alone.

The + button does this correctly — /clear does not

The app already writes one record per conversation on another path. Starting a session with the + button next to a folder was tested against a snapshot of both stores:

| Action | App record | Transcript | Title |
|---|---|---|---|
| + button | local_3f64a5e1 created | 02af8d8b created | "Sidebar plus button testing" — auto-titled |
| /clear | none created | created | never titled |

Both stores went 5 → 6, paired 1:1. The window's existing record was left untouched and still points at its own transcript.

So the correct behaviour already exists and is reachable; /clear simply doesn't take that path.

Two details worth noting for anyone reproducing this:

• The record is written on first activity, not on click. Clicking + and stopping there creates nothing. Send a message before checking.
• Auto-titling appears tied to minting a fresh record — the + session was titled from its first message, while a record that has been reused across /clear for four hours still has no title field at all. (Correlation from two samples, not confirmed from source.)

Knock-on effects

• list_sessions inherits the gap. The session-management MCP tool reads store 3, so it returns the same incomplete list. An agent asked "find my earlier session" cannot see the orphaned ones either.
• Orphaned entries are untitled. The surviving record has no title field, so the sidebar renders "General coding session" — unhelpful for picking between windows even when entries do exist.
• /resume is unavailable in-app. It's an interactive terminal dialog, so the in-app user has no fallback path at all.

Workaround

Resume from a terminal. Sessions are indexed by working directory, so the cd is required:

cd /path/to/project && claude --resume          # picker
cd /path/to/project && claude --resume <uuid>   # direct

UUIDs are the filenames in ~/.claude/projects/<encoded-cwd>/.

Suggested fix

Make /clear take the same path as +. That path already creates a new local_ record, points it at a fresh transcript, leaves the prior record intact, and auto-titles it on first activity — which is exactly the desired behaviour.

Two things that would help alongside it:

• Backfill from disk. Reconciling the sidebar against ~/.claude/projects/<encoded-cwd>/ would surface the conversations already orphaned on users' machines, not just prevent new ones.
• Title reused records too, if the fix above leaves any path that reuses a record. A folder full of "General coding session" entries is hard to navigate even once everything appears.