[Bug] Project transcript folders named with leading dash break CLI tools and cause silent search failures

Bug Description
Project transcript folders are named with a LEADING DASH, breaking every CLI tool — 3 months of silent false-negative searches

Claude Code version: 2.1.195 (Linux Mint, bash)

What happens

Claude Code stores per-project state under ~/.claude/projects/, naming each folder by encoding the working directory — turning / into -. Because every absolute path starts with /, every folder name therefore starts with a -:

/home/avatar/.local/bin -> -home-avatar--local-bin
A leading - is read by virtually every command-line tool (grep, ls, cat, rm, cp, find, file, sed, tar…) as an OPTION FLAG, not a path. So a perfectly reasonable command like:

grep -r "morpheus" ~/.claude/projects/-home-avatar--local-bin-COMMAND-CENTER
does not search that folder. The tool tries to parse -home-avatar-... as flags, errors to stderr, and — critically — often EXITS 0 HAVING SEARCHED NOTHING. If stderr is redirected (very common: 2>/dev/null), the user sees an empty result and a success code, indistinguishable from “searched and found nothing.” It is a silent false negative.

Why this is serious

This isn’t cosmetic. For 3 MONTHS this exact behavior caused real anguish: searching my own transcript history for past decisions kept returning “nothing found” when the content was absolutely there. I repeatedly concluded that designs/discussions had never happened, when in fact the search tool had simply never run against the dash-named folders. I nearly lost an entire agreed design thread because a search “proved” it didn’t exist — it did; the folder name had silently eaten the query every single time. Three months of distrusting my own records over a leading hyphen.

It also makes routine cleanup hazardous: rm / mv against one of these paths needs ./ or -- guarding, or it misfires.

Steps to reproduce

Run any Claude Code session in some directory (creates the dash-named folder).
cd ~/.claude/projects
grep -ri "anything" -home-avatar-... — a real folder name → tool treats the name as flags; searches nothing; may exit 0.
Compare: grep -ri "anything" ./-home-avatar-... → works fine.
Suggested fixes (any one solves it)

Prefix the encoded name so it cannot begin with -: e.g. drop the leading separator before encoding (home-avatar--local-bin), or prepend a fixed safe character/segment so the first char is never -.
Or store transcripts one level down (projects/by-path/<encoded>) so the dash-name is never itself a direct argument users reach for.
At minimum: document the hazard and the ./ / -- workaround prominently, since users WILL grep this directory.

Backwards-compat note: existing dash-named folders would need a migration step, but new installs would stop inheriting the papercut.

Environment Info

• Platform: linux
• Terminal: vte-based
• Version: 2.1.193
• Feedback ID: 524c0c6d-ff44-475e-987d-0277e7db115a