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

[squatto]

Preflight Checklist

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

What's Wrong?

In Claude Desktop (macOS), running /clear resets the current session in-place rather than creating a new session. The current session is renamed to "General coding session" in the sidebar and its message content is replaced with "No messages yet" — making the entire session history inaccessible through the UI.

In the terminal CLI, /clear correctly creates a new context window while preserving the original session as a separate, accessible entry in the session list. The desktop app does not match this behavior.

The raw .jsonl transcript file survives on disk at ~/.claude/projects/<project>/<uuid>.jsonl, but because the desktop app's session cache entry is reset rather than a new one being created, the transcript is permanently orphaned — there is no UI path to access it.

What Should Happen?

/clear in Claude Desktop should behave the same as in the terminal CLI: start a fresh context window (new session entry in the sidebar) while preserving the original session — including its title and full conversation history — as a separate, accessible entry.

Error Messages/Logs

Steps to Reproduce

1. Open Claude Desktop (macOS) and start a session with at least a few messages in it
2. Run /clear in the chat input
3. Sidebar: the session is renamed to "General coding session"
4. Main panel: "No messages yet" — all prior messages are gone
5. Navigate away and back; restart the app — the history does not return
6. Confirm the .jsonl transcript still exists on disk at ~/.claude/projects/.../<original-uuid>.jsonl — data is intact but inaccessible

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

Claude 1.15200.0 (250bae) 2026-06-23T05:40:53.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Screenshots

Before running /clear

After running /clear

Related Issues

• [BUG] /clear does not preserve previous session for /resume, contradicting in-app description #59534 — same /clear session-preservation failure in CLI (closed stale); my bug is the desktop-app manifestation
• [BUG] /clear inherits previous session name instead of resetting it, causing duplicate-named sessions in /resume #61172 — open CLI issue for the name-inheritance half of the same problem

[github-actions]

Found 2 possible duplicate issues:

1. [BUG] /clear does not preserve previous session for /resume, contradicting in-app description #59534
2. [BUG] /clear inherits previous session name instead of resetting it, causing duplicate-named sessions in /resume #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

[squatto]

These are not duplicates:

• [BUG] /clear does not preserve previous session for /resume, contradicting in-app description #59534 — similar /clear session-preservation failure in CLI (closed stale); my bug is the desktop-app manifestation and is more extensive
• [BUG] /clear inherits previous session name instead of resetting it, causing duplicate-named sessions in /resume #61172 — open CLI issue for the name-inheritance half of the same problem; my bug is on the desktop app and is more extensive

[BasedGPT]

/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 ⭐ :)

[jmadren]

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.

[BasedGPT]

Hey jmadren,

One Desktop metadata record is standing in for five transcript files, so /clear leaves the earlier conversation history on disk while removing it from the session list.

The defect is the in-place cliSessionId reuse: /clear starts a new .jsonl transcript, but the app-side local_*.json record does not get a new entry. I built BasedGPT/claude-code-session-recovery for this orphaned file-layer case. From the toolkit checkout, run:

python tools/diagnose.py

Follow the exact command it prints. On macOS, compare the affected local_*.json under ~/Library/Application Support/Claude/claude-code-sessions/ against the .jsonl files under ~/.claude/projects/; do not copy or rewrite anything until the diagnosis identifies the surviving transcript.

If the diagnosis finds the original transcript, review the printed dry-run repair with Desktop fully quit before applying it. Keep the whole project directory intact until each transcript created by /clear is accounted for.

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