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
[FEATURE]: Allow renaming/moving a project folder while persisting session history (replacement for stale-closed #25625) #44256
This is a replacement for #25625, which was auto-closed by the stale bot after 60 days of inactivity with an invitation to open a new issue. The underlying problem is still live: #23248 (sessions becoming orphaned when the project directory is renamed) remains open, and its companion request #23249 was closed by the same bot.
Renaming or moving a project folder currently orphans all sessions of that project: history becomes unreachable from the UI because session identity is tied to the old path.
Proposal
Support renaming/moving a project folder while persisting session history, proactively rather than via manual recovery:
On startup (or when a configured worktree path is missing), detect that a previously known project path no longer exists.
Offer to re-link the orphaned sessions to the relocated folder (e.g. match by git remote URL and/or content heuristics), instead of silently dropping them out of the session list.
Keep the historical path as metadata so past sessions remain attributable even if re-linking is declined.
#23249 proposed an interactive migration dialog for already-orphaned sessions; this request is about preventing the orphaning in the first place by handling renames/moves as first-class events. Both can coexist: prevention for known moves, recovery for missed ones.
Why not a duplicate
#23248 describes the symptom; this proposes the proactive fix. The distinction was already made on #25625 before its closure.
Environment
App: OpenCode Desktop 1.18.21
OS: Microsoft Windows 11 Education, 25H2, build 26200.8875
+1 — hit exactly this today (folder rename, not a move) and confirmed the history is never actually lost: every session is still in opencode.db, just orphaned because session.directory/session.path hold the old absolute path and nothing updates them. I'm working on a relink-on-detect approach plus proper project removal (details in my comment on #23248), and will link the PR here when it's up. One extra data point for whoever implements it: paths inside event.data payloads are stored JSON-escaped at two different depths depending on payload type, so the migration needs to be encoding-aware or it will silently miss most rows.
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.
I’d like to work on this for V2. Proposal: add a “Project location” field (with Browse) to the project settings page. Saving updates the project’s canonical directory and relocates its idle sessions and worktrees under the old root through the existing session.moved event, preserving subfolders. Does this approach work for you?
Fully updated OpenCode 2.0.32 TUI. Have had a session open for a week or two, getting lots of work done. I was working on a portable codebase and wanted to test that it would still work if I broke the absolute path. Good news is that it did. Bad news is that OpenCode itself broke. All shell tools has disappeared, so work is blocked now.
Example:
The session was originally at
/folder/path/foo
In the OS, I renamed
/folder/path/foo
to
/folder/path/bar
Inside the OpenCode session, I ran "/cd" to change the working directory to
/folder/path/bar
After that, the session no longer had access to shell commands, despite things like a custom MCP tool in the directory's ".opencode" subfolder still working.
I'm on an immutable Fedora-based distro that uses symlinked "/home". At first, I thought that was the cause. But after undoing my name changes and cwd, the shell tools still seem broken. I restarted the TUI, forked the session, resumed from a new session tab, and nothing seemed to work.
Thanks for opening this as a replacement for #25625!
The request: when a project folder is renamed or moved, OpenCode should notice the old path is missing, offer to re-link the project and its sessions to the new location (for example by matching the git remote), and keep the old path as metadata. Then history isn't orphaned. Maintainers will consider it.
This also affects OpenCode 2.x: v2 reports of the same problem have been closed as duplicates of this issue, so this is the place to follow and add to it. You're on Desktop 1.18.21. v1 only receives critical fixes, so any work on this would land in v2. In v2, a session whose folder is missing can already be moved to another directory one session at a time, but renames aren't detected automatically yet.
Activity
github-actions commentedon Aug 22, 2026
This issue might be a duplicate of existing issues. Please check:
Please review these issues and consider whether your request is already covered or can be tracked there.
neohiro commentedon Aug 26, 2026
+1 — hit exactly this today (folder rename, not a move) and confirmed the history is never actually lost: every session is still in
opencode.db, just orphaned becausesession.directory/session.pathhold the old absolute path and nothing updates them. I'm working on a relink-on-detect approach plus proper project removal (details in my comment on #23248), and will link the PR here when it's up. One extra data point for whoever implements it: paths insideevent.datapayloads are stored JSON-escaped at two different depths depending on payload type, so the migration needs to be encoding-aware or it will silently miss most rows.neohiro commentedon 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.
CriToX42 commentedon Oct 8, 2026
I’d like to work on this for V2. Proposal: add a “Project location” field (with Browse) to the project settings page. Saving updates the project’s canonical directory and relocates its idle sessions and worktrees under the old root through the existing session.moved event, preserving subfolders. Does this approach work for you?
wm-207 commentedon Oct 18, 2026
So, this bug just bit me today.
Fully updated OpenCode 2.0.32 TUI. Have had a session open for a week or two, getting lots of work done. I was working on a portable codebase and wanted to test that it would still work if I broke the absolute path. Good news is that it did. Bad news is that OpenCode itself broke. All shell tools has disappeared, so work is blocked now.
Example:
The session was originally at
/folder/path/foo
In the OS, I renamed
/folder/path/foo
to
/folder/path/bar
Inside the OpenCode session, I ran "/cd" to change the working directory to
/folder/path/bar
After that, the session no longer had access to shell commands, despite things like a custom MCP tool in the directory's ".opencode" subfolder still working.
I'm on an immutable Fedora-based distro that uses symlinked "/home". At first, I thought that was the cause. But after undoing my name changes and cwd, the shell tools still seem broken. I restarted the TUI, forked the session, resumed from a new session tab, and nothing seemed to work.
+1 for a potential fix.
opencodejr commentedon Oct 28, 2026
Thanks for opening this as a replacement for #25625!
The request: when a project folder is renamed or moved, OpenCode should notice the old path is missing, offer to re-link the project and its sessions to the new location (for example by matching the git remote), and keep the old path as metadata. Then history isn't orphaned. Maintainers will consider it.
This also affects OpenCode 2.x: v2 reports of the same problem have been closed as duplicates of this issue, so this is the place to follow and add to it. You're on Desktop 1.18.21. v1 only receives critical fixes, so any work on this would land in v2. In v2, a session whose folder is missing can already be moved to another directory one session at a time, but renames aren't detected automatically yet.
Related issues: