[Feature Request] Relocate a Project/Workspace folder without losing its sessions / 更换项目文件夹路径

[phoenixyy]

[Feature Request] Relocate a Project/Workspace folder without losing its sessions / 更换项目文件夹路径

User problem

After creating a Project/Workspace in DSH Desktop, moving or renaming its folder outside DSH leaves the project pointing at the old location. There is no “Change folder…” / “Locate moved folder…” action. Recreating the project is not equivalent: existing sessions retain their original working directory.

This is a routine workflow when reorganizing projects, moving a checkout to another disk, or renaming a parent directory. Users should not need to edit internal storage or session logs.

Observed in the installed DSH packages at 0.1.5-rc.1 on macOS. This is a feature proposal, not a claim that a relocation implementation already exists.

Proposed experience

Project menu → Change folder… → choose the existing new folder → review old/new paths and affected sessions → confirm.

• Keep the existing project identity, display name, ordering, and session history.
• Resume existing sessions and create new sessions using the new working directory.
• When the old folder is missing, offer “Locate moved folder…” on that project instead of requiring deletion/recreation.
• If related work is active, explain what must finish or stop before retrying; do not silently interrupt it.

For a first version, the user has already moved the folder. DSH changes the association only; it does not move, copy, merge, or delete filesystem contents.

Safety and consistency requirements

• Validate/canonicalize the target directory on the host and detect another workspace already owning the destination. Never silently merge projects.
• Coordinate the relocation with session/turn admission so a new turn cannot start halfway through the change. Account for active descendants, jobs, and persistent terminals as appropriate.
• Keep workspace membership, effective session cwd, restore behavior, and runtime caches consistent. Re-evaluate workspace-dependent instructions and permissions without silently expanding authorization.
• Preserve historical events and their original paths. Do not search-and-replace old paths in transcripts or overwrite committed session generations.
• Make partial failure/crash recovery explicit and testable. A successful UI response must not leave some sessions executing in the old folder.
• Clearly distinguish a workspace relocation from merely changing a display title.

Why a supported API would help plugin authors

In the inspected implementation, workspace rename updates the title, while workspace path and the stored session-header cwd are treated as immutable. Workspace session membership is checked against the session's canonical cwd. A UI-only button therefore cannot safely perform the complete operation.

Please consider a supported relocation API owned by the workspace/session lifecycle services, exposed through the workspace controller and used by the existing project UI. The exact persistence design should follow the maintainers' preferred session-format and recovery approach; this proposal does not prescribe in-place header editing.

A community plugin could then reuse that API instead of modifying private registry records, patching session logs, or relying on symlink workarounds. Until such an API exists, any lightweight plugin should explicitly label a create/fork-based workflow as a continuation in a new project/session, not a migration of the original identity.

Suggested acceptance tests

1. Relocate an idle project after its old folder disappears; existing sessions resume against the new cwd after a restart.
2. Reject a missing/non-directory destination and a destination already owned by another project, without modifying either project.
3. Cancel the folder picker/confirmation without changes.
4. Reject or safely serialize a concurrent turn, descendant, or relocation request.
5. Exercise interrupted persistence and restart recovery without losing sessions or duplicating project ownership.
6. Preserve historical messages, IDs, ordering, and recorded paths; verify that new filesystem/shell operations and workspace-dependent context use the new directory.
7. Cover spaces, Unicode paths, symlink canonicalization, and platform-specific path behavior.

Related discussion and scope

Related: #2836, which asks for workspace rename to rename the physical folder. This proposal is different: leave Rename as a title operation, and add an explicit action to point an existing project at a folder that has already moved.

Posting in Ideas rather than opening an external PR, as requested by the current CONTRIBUTING guide. Would the maintainers support this experience and a plugin-consumable relocation API?

---

中文摘要

文件夹搬家后，希望可以在 Project 菜单 → 更换文件夹 → 选择新位置 → 确认，保留原来的 Project 和会话记录，后续会话操作使用新目录。

第一版不需要搬动磁盘文件，只更新已搬家文件夹的关联；有任务运行时提示先结束，目标路径冲突时明确拒绝。历史消息和旧路径记录不应被篡改，也不应要求用户删除并重建 Project。

希望上游提供安全的工作区/会话目录变更接口，既供内置菜单使用，也让社区插件不必直接修改内部存储。完整迁移与“新建项目后分叉会话继续工作”应在界面上明确区分。