Skip to content

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

Closed
Closed
Project path is not updated after moving project directory (opens old deleted path)#34737
Assignees
StarpTech

Description

@afsharmn
afsharmn
opened on Jul 1, 2026

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

Activity

  1. github-actions
    assigned
    StarpTech
    on Jul 1, 2026

  2. github-actions commented on Jul 1, 2026

    @github-actions
    github-actionsBot
    on Jul 1, 2026 – with GitHub Actions
    Contributor

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

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

  3. gnu-lorien commented on Jul 6, 2026

    @gnu-lorien
    gnu-lorien
    on Jul 6, 2026

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

  4. wangminle commented on Aug 4, 2026

    @wangminle
    wangminle
    on Aug 4, 2026

    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.

  5. SamSpiri commented on Aug 15, 2026

    @SamSpiri
    SamSpiri
    on Aug 15, 2026

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

  6. benizzio-opencode commented on Aug 18, 2026

    @benizzio-opencode
    benizzio-opencode
    on Aug 18, 2026

    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.

  7. neohiro commented on Aug 26, 2026

    @neohiro
    neohiro
    on Aug 26, 2026

    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.

  8. neohiro commented on Aug 26, 2026

    @neohiro
    neohiro
    on Aug 26, 2026

    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.

  9. neohiro
    added a commit that references this issue on Aug 26, 2026

    feat(project): rename-with-relocation and cascade delete for projects

    bf6401d

  10. Hona commented on Sep 2, 2026

    @Hona
    Hona
    on Sep 2, 2026
    Member

    Fixed for opencode2 launch via #46713
    You can try the desktop beta here: https://github.com/anomalyco/opencode-beta

  11. Hona
    closed this as completedon Sep 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions