Project path is not updated after moving project directory (opens old deleted path)

[afsharmn]

Description

I previously opened a project in OpenCode located at:

C:\first_address

Later, I moved the entire project to:

D:\second\address

The original folder (C:\first_address) was removed/deleted.

After reopening OpenCode and selecting the project from the new location (D:\second\address), OpenCode still tries to open the old path (C:\first_address) instead of using the new one.

It looks like OpenCode may be keeping a cached workspace/project reference and not refreshing the project location.

Steps to Reproduce

1. Open a project in OpenCode from:
   C:\first_address

2. Close OpenCode.

3. Move the project folder to:
   D:\second\address

4. Delete or remove the original folder.

5. Open OpenCode again.

6. Open/select the project from the new location.

Plugins

No response

OpenCode version

No response

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• OpenCode Desktop on macOS keeps opening old project folder after project was moved #31074: OpenCode Desktop on macOS keeps opening old project folder after project was moved (same root cause, macOS)
• Bug: Stale Project Path Persists After Full Workspace Reset (Windows) #31888: Bug: Stale Project Path Persists After Full Workspace Reset (Windows) (same issue, Windows, with more detail and troubleshooting steps)
• [Critical] Desktop App Crashes Continuously - 503 Service Unavailable & Path Confusion After Moving Project #33359: Desktop App Crashes Continuously - 503 Service Unavailable & Path Confusion After Moving Project (related path confusion after moving project)

If your issue matches one of these, consider adding a comment there with any new details rather than opening a separate report.

[gnu-lorien]

I have the same problem and can't figure out how to force it to update.

[wangminle]

Root Cause Analysis

I encountered the same issue and dug into the local database (~/.local/share/opencode/opencode.db). The problem is that when a project directory is moved, several database fields are not updated to reflect the new path:

What gets updated correctly

• project_directory table — a new row is inserted mapping the new directory to the existing project ID ✅

What stays stale (the bug)

Table	Field	Problem
project	worktree	Still points to the old (now non-existent) path
session	directory	All existing sessions keep the old path
session	path	Some sessions also have this field set to the old path

Consequence

When opening opencode in the new directory:

• The project is found via project_directory (which correctly has the new path)
• But session history is filtered by session.directory, which still has the old path
• So the IDE/TUI shows either no sessions or still references the old project path

Reproduction

1. Open a project at path A, create several sessions
2. Close opencode
3. Move the project folder to path B (path A no longer exists)
4. Open opencode at path B
5. project_directory gets a new row for path B, but project.worktree and all session.directory values still point to path A

Manual fix that worked for me

-- Update project worktree
UPDATE project SET worktree = '<new_path>' WHERE id = '<project_id>';

-- Update all sessions
UPDATE session SET directory = '<new_path>' WHERE directory = '<old_path>';
UPDATE session SET path = '<new_path>' WHERE path = '<old_path>';

After this, all session history is correctly visible in the new directory.

Suggested fixes

Either of these would resolve the issue:

1. Auto-update on open: When opencode opens a directory and finds it matches a project_directory entry but the project.worktree is stale (path doesn't exist on disk), automatically update project.worktree and all related session.directory / session.path fields to the new path.

2. Allow manual rebinding: Provide a command (e.g., opencode project rebind <new_path>) that lets users rebind a project to a new directory, updating all related tables at once.

Option 1 would be ideal since it's transparent to the user — they just open the new folder and everything works.

[SamSpiri]

UPDATE project_directory SET directory = '<new_path>' WHERE directory = '<old_path>';
also needed

[benizzio-opencode]

Also confirmed on OpenCode Desktop 1.18.18 on Linux while replacing an old checkout with another clone at a new path.

The new path was inserted into project_directory, but project.worktree remained the old path. Because both clones had the same Git remote, the new path was also stored in project.sandboxes under the same project ID. Selecting the new path therefore normalized back to the old canonical worktree. This overlaps with the shared-remote collision tracked in #42315.

In our case we wanted to completely purge the old OpenCode project and did not need its session history. The tested workaround was:

1. Quit Desktop and back up ~/.local/share/opencode/opencode.db plus the relevant files under ~/.config/ai.opencode.desktop/.
2. Run the deletion with PRAGMA foreign_keys=ON so deleting the stale shared project row also removed its old sessions and directory mappings.
3. Remove the old path from the nested server, globalSync.project, notification, layout/session, and window-tab state in the Desktop .dat files; remove the old path's hashed workspace .dat file.
4. Leave the new path as the first/last Desktop project and restart.

Desktop then recreated the project with the new path as project.worktree, an empty sandboxes list, and no old-path references. The database passed integrity_check and foreign_key_check afterward.

This is deliberately more destructive than the SQL rebinding workaround already posted above. If session history must be preserved, updating project.worktree, session.directory, session.path, and project_directory is preferable. The additional detail from our reproduction is that Desktop's persisted .dat state may also need cleanup; changing only the visible project list or only the database can leave the other layer stale.

[neohiro]

Same situation on my end after an Explorer rename (Windows 11): sessions invisible under the new folder, and Delete on the leftover empty project fails because the backend still resolves the old worktree. What finally made it recoverable was updating three layers, not just the DB row:

1. session.directory / session.path
2. the directory strings embedded inside event.data payloads (they resurrect stale state otherwise)
3. Desktop's own registry (opencode.global.dat → server.projects.local[], plus base64(path)-keyed maps)

Until all three move together, the UI keeps showing a dead entry that can't be deleted. I've started work on relink + delete-cascade support (see my note on #23248) and will link the PR here — if you'd rather see this fixed purely server-side (auto-relink on startup) instead of adding Desktop UI for it, say so and I'll aim there.

[neohiro]

PR is up: #45133 - it covers the relink/migration half of this (rename+move, all stored encodings) plus groundwork docs for the delete-cascade and Desktop registry cleanup. Feedback welcome.