Repository navigation
Desktop: moving a project directory leaves stale worktree in project table — project shows "no git" and all prompts fail with ENOENT #46330
Description
Environment
- opencode Desktop 1.18.25 (macOS, Apple Silicon)
- Data dir:
~/.local/share/opencode(server sidecar SQLiteopencode.db), Desktop state in~/Library/Application Support/ai.opencode.desktop/
What happened
I moved a project directory from:
~/Projects/scripts/java/brand-portal-system → ~/Projects/scripts/java/brand-portal/brand-portal-system
After the move, opening that project in Desktop showed no git and every prompt failed silently (no response in the UI). All other projects kept working. Server log (~/.local/share/opencode/log/opencode.log) showed repeated:
level=ERROR message="prompt_async failed" cause="Cause([Die(PlatformError: NotFound:
FileSystem.realPath (/Users/.../brand-portal-system)
(cause: Error: ENOENT: no such file or directory, lstat '/Users/.../brand-portal-system'))])"
Root cause
The move-migration path is only half-complete in opencode.db:
project.id(root-commit based, stable across moves — good) was reused.project_directoryrows and new sessions correctly pointed at the new path.- But
project.worktreestill contained the old path, and the Desktop project list resolves/opens projects via that column → it tries to open a directory that no longer exists → ENOENT, "no git", dead prompts.
Because the server DB is the source of truth, cleaning Desktop-side state (opencode.global.dat, opencode.window.*.dat, Electron caches) does not help — the stale entry is re-synced back on every launch.
Repro
- Add a git project to Desktop, use it normally.
- Quit Desktop;
mvthe project directory elsewhere. - Relaunch Desktop and open the project from the list.
Expected
project.worktree should be updated when the directory move is detected (the migration already touches project_directory/sessions), or the Desktop should resolve the project through project_directory instead of the stale worktree.
Workaround (for anyone hitting this)
Quit Desktop, then:
-- ~/.local/share/opencode/opencode.db
UPDATE project SET worktree='<new-path>' WHERE id='<project-id>';then reset the stale tabs in ~/Library/Application Support/ai.opencode.desktop/opencode.window.*.dat and clear Cache/ + Code Cache/. Relaunch — project, git detection and full session history are restored.
Activity
github-actions commentedon Aug 31, 2026
This issue might be a duplicate of existing issues. Please check:
worktreepath in project DB, causing persistent 500 errors on relaunch #41420: Renaming a project's local folder leaves staleworktreepath in project DB, causing persistent 500 errors — same root cause (staleproject.worktreeafter move/rename), same ENOENT symptom, same SQL workaroundproject.worktreeafter project folder is renamed on disk; remote clients keep reopening the dead path #35240: Server keeps staleproject.worktreeafter project folder is renamed on disk — identical DB inconsistency and error pattern, also documents that client-side cleanup doesn't help because the server re-syncs the dead pathAnyeler commentedon Aug 31, 2026
Additional detail that narrows the reproduction: closing the project in Desktop and re-opening the directory at its new path does not recover either.
As far as I can tell this is because
Project.fromDirectoryresolves the project via the stable id cached in.git/opencode. Opening the new path hits that cache, resolves to the existingprojectrow, and returns it with its staleworktree(old path) — so the freshly re-added project maps straight back to the broken row and keeps failing with the same ENOENT. There is no UI-only path to recovery; the staleworktreecolumn has to be corrected (or the row removed) in the DB.So the move-migration gap is: id resolution and
project_directory/sessions get updated/reused on a move, butproject.worktreenever does, and it's the column the Desktop uses to open the repo.Hona commentedon Sep 2, 2026
Fixed for opencode2 launch via #46713
You can try the desktop beta here: https://github.com/anomalyco/opencode-beta
seiji142 commentedon Oct 15, 2026
Same symptom on Windows (Desktop, moved folder one level deeper). Log shows the same FileSystem.realPath + ENOENT, plus one extra evidence I didn't see mentioned: opening the new folder boots two instances seconds apart (new path + stale path), so the dead reference is consulted even on fresh opens — deleting dead sessions alone loops forever.
Workaround that worked here (reversible, no data loss): create a directory junction old-path → new-path (New-Item -ItemType Junction). Every stale reference (tabs, sidebar entry, sessions) resolves again; explorer lists, prompts work. Rollback: rmdir the link. OneDrive didn't complain in my case.
Side findings: in opencode.global.dat the stale paths use four backslashes (double-nested JSON) — patterns with two match nothing; and project_directory already pointed at the new path, so the stale source is the frontend/window state, not the server DB mapping.