Session discovery: conversations become unreachable, plus ghost and duplicate project entries
Session discovery: conversations become unreachable, plus ghost and duplicate project entries
Claude Code: 2.1.286 (native, Windows)
Desktop app: 2.16120.0.0
OS: Windows 11 Home 10.0.26100
Shell: PowerShell 5.1 / Git Bash
Summary
A user with ~10 active conversations reached a state where they believed every
conversation had been lost. No data was actually lost — all .jsonl transcripts
were intact on disk — but four independent behaviours combined to make the
sessions undiscoverable from both the CLI and the desktop app sidebar.
Reporting them together because the interaction is the actual failure.
---
1. An unknown subcommand is silently treated as a prompt
claude rc is not a subcommand (not in claude --help). Instead of erroring,
it starts a brand-new conversation whose first user message is the literal
string rc.
The user ran claude rc from their project directory expecting to resume.
They got an empty new session, concluded their conversations were gone, and
two 0-byte transcripts were created in the process.
Expected: a single bare token that matches no known subcommand should at
least warn — rc is not a command; starting a new conversation with "rc" as — before consuming it as a prompt.
your prompt. Did you mean --resume?
Note: the user had earlier been shown text reading *"Run claude rc from a
project directory instead"*. I could not verify whether Claude Code emits that
string or whether it came from elsewhere, so treat that part as unconfirmed. If
it is ours, it points at a non-existent subcommand.
---
2. Launching inside the session-storage folder creates a recursive project entry
Starting Claude Code with the working directory set to~/.claude/projects/<project-slug>/ creates a nested project entry:
~/.claude/projects/C--Users-<user>--claude-projects-C--Users-<user>-projects-myproject/
That is the storage directory encoded as if it were a user project. It appears
in the sidebar as a separate project group containing one empty conversation.
Expected: ~/.claude/projects/ (and ~/.claude/ generally) should be
excluded from project-slug creation, or at minimum warned about.
---
3. Zero-byte transcripts persist as ghost sessions in the sidebar
Sessions that never exchange a message leave behind a 0-byte .jsonl. These
still render in the desktop app sidebar under auto-generated names
(<hostname>-quiet-cerf, <hostname>-shimmying-neumann), indistinguishable
from real conversations.
With 3 of 11 sessions empty, roughly a quarter of the sidebar was noise.
Expected: don't list conversations with no messages, or clean them up.
---
4. One logical conversation forks across two cwds after compaction
Two transcripts share an identical start timestamp
(2026-09-27T22:01:34.706Z) and an identical compaction summary, but differentcwd:
| id (short) | cwd | size | last activity |
|---|---|---|---|
| dd598162 | ~ | 9.7 MB | 2026-10-01 13:48 |
| 9d6e494a | ~/projects/myproject | 9.2 MB | 2026-10-01 07:57 |
They diverged from that point and accumulated different content. Becauseclaude --resume scopes by cwd, the 9.7 MB branch — the one still alive — is
invisible from the project directory where the user actually works. Worse, the
user's home directory can never be trusted persistently ("home-directory trust
is never saved"), so that branch is awkward to reach at all.
Expected: resuming a compacted conversation should not silently re-key it to
a different project. If it must, the sidebar should indicate the two are
related.
---
5. Sidebar project groups are ambiguous
Two distinct project roots both render as myproject in the sidebar, with
no full path, tooltip, or disambiguator. The screenshot shows two separate
groups with the identical label and different contents.
Expected: disambiguate same-basename projects by path.
---
Impact
The user's own prior diagnosis of an unrelated issue had been written to disk
seven hours earlier and could not be found by either the user or an assistant
working in the same account — each conversation is only discoverable from the
directory it happens to be keyed to, and nothing surfaces the set.
Workaround used
Copying the transcripts into the target project's storage directory makes them
appear in claude --resume from that directory, and resuming by explicit id
(claude --resume <uuid>) works. Neither is discoverable without reading~/.claude/projects/ by hand.
Suggestion
A built-in way to list and search conversations across all projects — something
like claude sessions — would make most of the above recoverable by the user
instead of requiring manual inspection of the transcript store.