Repository navigation
Bug: Project path incorrectly reconstructed when username contains underscores — causes "Failed to send prompt" #465
Description
Activity
Follow-up investigation — bug is broader than the username case
After further testing I found the root cause affects any project whose path contains a dash, not just usernames with underscores. The problem is that opcode converts every
-in the Claude project directory name back to/, while Claude CLI originally encoded both/path separators and-dashes in directory names as-.Full encoding ambiguity
Claude CLI creates project directory names by replacing
/with-(and also_with-).
Example:/home/michal_mikes/projects/teamio-acnas → -home-michal-mikes-projects-teamio-acnasOpcode reverses this naively (
-→/), producing:-home-michal-mikes-projects-teamio-acnas → /home/michal/mikes/projects/teamio/acnas ❌Correct path:
/home/michal_mikes/projects/teamio-acnas✅On a system with 22 Claude projects, all 22 had wrong paths after reconstruction. Every project with a dash in its name is broken (
teamio-acnas,alma-career-api-docs,advertplatform-advert-model, …).Why the localStorage workaround doesn't hold
Opcode rebuilds project paths from directory names every time it starts (the
list_projectscommand runs on startup). Any manual fix to the localStorage SQLite DB is overwritten within seconds.The session files already have the answer
Each project directory under
~/.claude/projects/<encoded-name>/contains.jsonlsession files. Every session line that has acwdfield contains the original, correct path. The code already has a path for this — the log message"Failed to get project path from sessions for , falling back to decode"confirms it tries session files first. However, newer Claude session files begin withlast-promptorpermission-modeentries (nocwd), so the lookup fails and the broken decode is used as fallback.Fix suggestion: when reading a session file to extract
cwd, scan beyond the first line until a line with a non-emptycwdis found (or scan all lines in the file), rather than giving up after the first line.Minimal reproducible case (no special username needed)
- Use any project whose directory name contains a dash, e.g.
/home/user/my-project - Claude encodes it as
-home-user-my-project - Opcode decodes it as
/home/user/my/project— path does not exist → "Failed to send prompt"
This means the bug affects a large share of Linux/macOS users, not just those with underscores in their username.
- Use any project whose directory name contains a dash, e.g.
Yes same here, new install of opcode on Mac OS and the Recents show all my projects replacing - with / and it takes the last word after the hyphen/slash as the project name so not very good.
Bug Description
When a system username contains an underscore (e.g.
michal_mikes), opcode reconstructs project paths incorrectly, causing "Failed to send prompt" on every prompt submission in the Projects view.Root Cause
Claude CLI encodes project paths into directory names under
~/.claude/projects/by replacing both/and_with-. For example:When opcode reads this directory name and reconstructs the original path, it only performs the reverse of
/→-, yielding:The underscore in the username is lost, producing a path that does not exist on disk. Claude CLI then fails to start because the working directory is invalid, and opcode surfaces this as "Failed to send prompt".
The correct path should be
/home/michal_mikes/projects✅Steps to Reproduce
john_doe)Result: "Failed to send prompt" error immediately.
Workaround
Manually fix the corrupted
projectPathvalues in opcode's localStorage SQLite database:Values are UTF-16LE encoded JSON. Replace occurrences of
/home/john/doe/with/home/john_doe/in theprojectPathfields.Expected Behavior
The path reconstruction from the Claude project directory name should either:
cwdfield directly from the session.jsonlfiles inside the project directory (which contain the correct original path), or/from_(e.g. encode only/as-and leave_as-is, or use a different separator)Environment
Related Issues