You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Bug: Project path incorrectly reconstructed when username contains underscores — causes "Failed to send prompt" #465
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:
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
Use a Linux/macOS system where the username contains an underscore (e.g. john_doe)
Open opcode and navigate to the Projects tab
Select any project
Type any prompt and press Enter
Result: "Failed to send prompt" error immediately.
Workaround
Manually fix the corrupted projectPath values in opcode's localStorage SQLite database:
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:
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_projects command 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 .jsonl session files. Every session line that has a cwd field 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 with last-prompt or permission-mode entries (no cwd), 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-empty cwd is 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.
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.
Activity
mikesmichal commentedon May 12, 2026
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:
Opcode reverses this naively (
-→/), producing: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)
/home/user/my-project-home-user-my-project/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.
amityweb commentedon Jun 25, 2026
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.