[BUG] Lossy project directory path encoding makes decoding impossible

What's Wrong?

Claude Code encodes project directory paths in ~/.claude/projects/ by replacing both forward slashes (/) and spaces with hyphens (-). This creates an unrecoverable ambiguity that makes it impossible to decode the original path back.

This breaks external tools that analyze Claude Code data (like ccusage) and makes project migration difficult.

What Should Happen?

Project directory paths should use a reversible encoding scheme that allows tools to decode the original path. For example:

• URL encoding (%20 for spaces, keep - for /)
• Different separators for different characters (e.g., _ for spaces, - for /)

Error Messages/Logs

No runtime errors - this is a design issue with the path encoding scheme.

Current behavior example:

# Real project paths:
/Users/foo/Projects/Open Source/checkmate
/Users/foo/Projects/Open-Source/checkmate

# Both encoded identically (lossy!):
~/.claude/projects/-Users-foo-Projects-Open-Source-checkmate/

Steps to Reproduce

1. Create a project in a directory with spaces in the path:

``bash
cd ~/Projects/Open\ Source/test-project
claude
``

1. Check the created directory in ~/.claude/projects/:

``bash
ls ~/.claude/projects/ | grep Open-Source
``

1. Observe: -Users-{user}-Projects-Open-Source-test-project

1. Critical issue: You cannot tell if the original path was:

• ~/Projects/Open Source/test-project (space)
• ~/Projects/Open-Source/test-project (dash)

Impact on external tools:

Tools like ccusage cannot properly decode project names, especially where final directories contain dashes.

Is this a regression?

No, this never worked

Claude Code Version

2.0.11 (Claude Code)

Platform

Anthropic API

Suggested solutions:

1. URL Encoding (Recommended):

``
/Users/foo/Open Source/bar → -Users-foo-Open%20Source-bar
``

• Standard, reversible
• Handles all special characters
• Easy to decode

1. Different Separators:

``
/Users/foo/Open Source/bar → -Users-foo-Open_Source-bar
``

• Simple but needs to handle underscores in original paths

Related issues:

• #1726 - Claude CLI fails to escape file paths with spaces
• #4507 - Git Bash path resolution fails with spaces
• #5648 - Hook execution fails with spaces in path
• #4242 - Directories starting with dash/hyphen

Impact:

• External tools cannot decode project names correctly
• Dash-prefixed directories can be confused with CLI flags
• No way to programmatically reconstruct original paths