Feature request: move an existing session to another workspace (dsh session move)

[blueice168]

Problem

A session is bound to the workspace (cwd) it was created in, and DSH stores it per workspace:

~/.dsh/sessions/--<encoded-workspace-path>--/session-<id>/session.v4.jsonl.zstd

When a project moves to a new folder (for example switching to a dated working directory), the user has two bad options:

• keep the session where it is and change the working directory at runtime: the stored workspace and the live cwd drift apart, and resuming the session later reopens in the old folder;
• start a new session in the new folder: the whole conversation context is lost.

There is no dsh session move subcommand and no UI affordance. Moving the files by hand is unsafe: the log is zstd-compressed JSONL, the running process holds it open and keeps writing to the old path, and the GUI keeps its own session list in memory.

Proposed

1. dsh session move <session-id> --to <dir> [--copy] [--force]
   • validate the target workspace; refuse while the session has a live writer (--force copies instead of moving);
   • rewrite the recorded workspace in the event log (stream decompress, edit, recompress), then atomically rename the session directory into the target workspace bucket;
   • update the session-to-workspace index/metadata; keep a .bak until the move is verified.
2. GUI: "Move to workspace..." in the session item context menu; after the move the session stays open and its workspace label updates.
3. --copy as a non-destructive fallback.

Acceptance

• moving an idle session, then resuming it from the new workspace, opens with the new cwd and the full history;
• moving a running session is refused with a clear message; --force duplicates it and leaves the original intact;
• a move interrupted between the rename and the index update leaves either the old or the new state, never a half-written log;
• no change to the session file format version; existing sessions still load.

Alternatives considered

• change cwd at runtime only (today's workaround): session and workspace disagree, confusing on resume;
• export/import a session bundle: heavier, and loses the "same session" identity.

Relation to #10005

#10005 proposes Projects as first-class containers with a per-session cwd. This request is complementary: it is about migrating an existing session between workspace buckets, which stays needed after Projects land (sessions created before a project existed, or sessions that outlive a renamed directory).

Environment: dsh 0.2.0-rc.2, Windows 11, Web GUI.

[Carmelo-Rose]

+1 — I ran into the same gap and checked it against the 0.2.1-rc.2 sources, in case it helps triage:

• No move/re-attach command exists. workspace-controller only has insertSessionBefore (reorder inside a workspace); a session from another workspace, or from "Ungrouped", is rejected as "not accounted". The session row menu only offers pin / rename / fork / archive.
• The sidebar drag is reorder-only by design. Session drops are confined to the source group (sameGroupDrag in ui-workspace/src/client/rows/WorkspaceBrowser.tsx), so a cross-workspace drop is impossible even though rows are draggable.
• It is already on the team's radar as a deferred item. .agents/notes/proposed/architecture/2026-07-24-domain-kv-storage-and-workspace.zh.md lists "session 跨 workspace 移动" under 不做清单, trigger "产品需求出现", with the rework point "relax the attach check into a detach-then-attach orchestration". So this thread, Session cannot be re-attached to a Workspace (no API, no UI) — and unreadable logs disappear silently #10267 and [Bug] Cannot move a session between workspaces; renaming a workspace folder breaks session binding #6445 are probably the "product demand" that item is waiting for.
• The open design question is cwd. Membership is derived from the header cwd (one cwd ⇒ at most one workspace), and attachSession validates header cwd == workspace path. A move therefore has to decide whether the header cwd is rewritten. The community plugin in [Plugin] dsh-session-migrate — drag-and-drop session migration between workspaces #4845 rewrites only the header frame and keeps the event frames byte-identical, which suggests that is workable, but it depends on the private indexHeader.

What would help downstream users most: a public, versioned workspace/moveSession (or attachSession/detachSession) that owns the header rewrite safely, plus a "Move to workspace…" entry in the session menu. A drag-and-drop target on the workspace headers could then reuse the same command.

[TheStreamCode]

I hit the same gap from the "folder is gone" side on DSH Desktop 0.2.1-rc.2 (Windows 11, Web GUI) and traced it against the 0.2.1-rc.2 source (687f282e). A few findings that may help scope the fix.

What happens today

• Membership survives a deleted folder: the header index keeps ENOENT candidates in missingSessionPaths, so the session stays under its workspace and the transcript still opens (packages/workspace/workspace/src/index.ts:179-185, :826).
• The conversation cannot continue. On the first prompt, system-prompt assembly calls workingDirectory.ensure(); the projected path is missing, the fallback is the same header.cwd, and it throws working-directory: directory does not exist (packages/session/working-directory/src/index.ts:134-152). The turn ends as turn/end { kind: 'error' }, and no tool can run first because cd is itself a tool call.
• Workspace.status() already returns 'ok' | 'missing-dir', but it is not exposed over RPC and not rendered; the hover card shows the stale path (packages/api/workspace-controller/src/index.ts:90-205).
• Dragging is reorder-only: session drops require sameGroupDrag, and insertSessionBefore rejects unaccounted sessions.
• Two side effects: session/create in a dead workspace silently recreates the directory (packages/api/session-controller/src/agent.ts:565), and a fork creates the child before failing to attach (session/workspace-attach-failed, packages/api/session-controller/src/commands.ts:300-305).

Why there is no workaround

attachSession requires realpath(header.cwd) === workspace.path (packages/workspace/workspace/src/entity.ts:110-150), so session/create({ sessionId, workspaceId }) only re-attaches when the header already points at the target. Editing workspace.json is reverted by the whole-file write, and replacing the old path with a junction breaks the realpath comparison, so the id is filtered and pruned.

Existing plans and ecosystem

The only written plan I can find is the deferred row in .agents/notes/proposed/architecture/2026-07-24-domain-kv-storage-and-workspace.md:298 ("relax the attach check into a 'detach first, then attach' orchestration"). Related: #10267 (no re-attach API), #10467 (accounting lost after a crash), #6445/#6448 (folder rename). The community plugin dsh-session-manager 0.7.4 does perform the move on 0.2.1-rc.2 Desktop, but through private registry/persistence internals, it leaves the durable working-directory row stale when the old path still exists (open issue #42), and its local HTTP API is unauthenticated (open issue #43).

Smallest complete fix I would ask for

1. workspace/moveSession (plus public attach/detach) with the same activity gate as archive.
2. A persistence-owned header relocation primitive that quiesces the writer, rewrites only the header frame, preserves body frames byte-for-byte, publishes without overwrite, and removes the old generation only after verification.
3. A missing-folder state in the workspace UI (status() already exists) with "Relocate workspace…" / "Move sessions…".
4. Cross-workspace drop on the workspace header once the command exists.

I can share the raw session event trace if useful for a fixture.