Moving or renaming a project folder makes its session history disappear, with no recovery path移动或重命名项目文件夹会导致其会话历史记录消失，无法恢复这些数据

[2838362]

正文（Body）

## Summary / 摘要

Moving (or renaming) a project folder makes that workspace's session history silently disappear from the Web GUI sidebar. The data is NOT lost — session logs still exist on disk under `~/.dsh/sessions/`, and `session.list` still returns them — but the workspace shows an empty `sessionIds` list and there is no built-in way to re-link the sessions to the new path. The only workaround is hand-editing `~/.dsh/storages/workspace.json` (risky) or moving the folder back.

Also observed: path strings stored in `workspace.json` appear to be mojibake (GBK bytes inside a UTF-8 file, e.g. `V:\涓偂鐩戞帶鎻愮ずdemo1` instead of `V:\个股监控提示demo1`), while session-header `cwd` values are proper UTF-8. This string mismatch may also break the membership check. Needs maintainer confirmation.

## Environment / 环境

- dsh: 0.1.0-rc.6 (`dsh --version`)
- Node: v24.13.0
- OS: Windows 11 (build 26200), 简体中文系统

## Steps to reproduce / 复现步骤

1. Start `dsh web` in a project folder, e.g. `V:\ProjectA`, and have a conversation (creates real history).
2. Stop the server, then **move/rename** the folder, e.g. to `V:\Other\ProjectA`.
3. Restart `dsh web` and open the Web GUI.
4. Observed: the `ProjectA` workspace still exists in the sidebar, but shows **zero sessions**. The conversations are gone from the UI.

Additional detail: `session.list` API still returns those sessions (with `cwd` pointing to the old path), and the JSONL logs are intact under `~/.dsh/sessions/<encoded-cwd>/<session-id>/`.

## Root cause / 根因分析（代码层面）

- The workspace entity's `sessionIds` getter filters by a path index: `record.sessionIds.filter(id => host.sessionPath(id) === record.path)` (`dsh-workspace/lib/index.js`).
- That index is built at startup by validating each session header's `cwd` via `realpath` + `isDirectory`; sessions whose folder no longer exists are excluded (and end up in `invalidSessionPaths`).
- The full disk rescan (`bootstrap`) runs **only once**, when the workspace domain is first initialized (`if (!this.state.initialized)`). It never re-runs afterwards.
- `attachSession` is only invoked when a **new** session is created; there is no API/UI to attach an existing (cold) session back to a workspace, nor to re-point a workspace/session to a new path.
- Net effect: a moved folder = permanently orphaned history, until someone hand-edits `workspace.json`.

## Suggested fix / 建议方案

- **A (recommended, moderate scope):** add a "rescan disk sessions" entry point (re-runnable version of the bootstrap logic, fixing sessions that exist on disk with a valid `cwd` but were never registered — e.g. they currently show up under "ungrouped"), plus a "re-link / repair workspace path" API + UI where the user picks the new folder location, and the stored session-header `cwd` (and workspace `path`) are rewritten accordingly.
- **B (bigger change):** make session→workspace identity relocatable instead of binding to an absolute path.
- Please also verify the encoding inconsistency in `workspace.json` path fields mentioned above.

## Workaround I used / 临时自救

- Backed up `~/.dsh/storages/workspace.json`, then hand-added the orphaned session id to its workspace's `sessionIds` array (validated with `JSON.parse`). Takes effect on next boot.
- Moving the folder back to the original path also restores visibility.

Thanks for this great tool — happy to provide more details, logs, or test a patch.

[sylvesterkaczmarek]

Your diagnosis matches the current API: there's no exposed workspace path-update/relink operation. Moving the folder back is the safest recovery for now; editing workspace.json is only an internal workaround.