Session cannot be re-attached to a Workspace (no API, no UI) — and unreadable logs disappear silently

[DNMCJH]

What happens

A Workspace owns a directory, and a Session is a log whose header carries a cwd. Creating a Session inside a Workspace works as expected (session/create with workspaceId → attachSession). The gap is the other direction: a Session that exists on disk but is not accounted by any Workspace cannot be attached again — there is no API and no UI for it.

Concretely, this state is reachable and I hit it today:

• the log exists at $DSH_HOME/sessions/<slug>/session-<id>/session.v4.jsonl.zstd
• its header cwd equals the Workspace path
• session/list returns it (so the Host can read it)
• the sidebar renders it under "Ungrouped"
• and every documented mutation refuses it:
  • workspace/insertSessionBefore → workspace/move-invalid ("the session is not accounted")
  • the session … menu only offers pin / rename / fork / archive
  • session rows are draggable, but onDrop is gated on sameGroupDrag, so cross-Workspace drop is impossible
  • workspace/archiveSession / pinSession require the session to be known too

The only way I found is an undocumented side effect: call session/create with an explicit sessionId plus the target workspaceId. That path runs ensureSession(restore) → rememberSessionPath → attachSession, which both re-indexes the path and attaches. It works, but it is not a public "attach" operation and I would not want to depend on it.

How the Sessions ended up unaccounted: a bulk re-encode of the session logs produced single-frame Zstandard files, and readFirstZstdLine requires the first frame to contain exactly the header line (assertZstdHeaderFrame). Those Sessions were reported as corrupt at startup, silently dropped from the header index and from session/list, and then pruned out of workspace.sessionIds by the filter inside mutate():

const sessionIds = changed.sessionIds.filter((id) => this.host.sessionPath(id) === changed.path);

Once sessionPath(id) is undefined, the next write removes the id permanently. (Restoring the frames brought the Sessions back in the list, but the membership was already gone.)

What I would expect

1. A first-class workspace/attachSession(sessionId) (or an attach option on an existing method) that validates realpath(header.cwd) === workspace.path, calls rememberSessionPath, and adds the id — i.e. exactly what attachSession already does internally, exposed as a command.
2. A UI entry for it: "Move to Workspace…" in the session … menu, enabled only for Workspaces whose path matches the session cwd. Cross-Workspace drag would be nice, but the cwd === path invariant makes it a move-between-directories problem, so a filtered menu item seems like the honest version.

With (1) alone, a broken registry is recoverable without editing workspace.json by hand. With (2), the "Ungrouped" bucket stops being a dead end.

Related robustness issue (separate, but this is how it surfaced)

When a stored log cannot be read, listArtifacts catches SessionPersistenceCorruptionError and continues, so the Session vanishes from session/list with no signal. Two things would have saved me a few hours:

• accept a first frame that contains the header line plus following lines (decode until the first \n instead of requiring the frame to be exactly one line), or
• surface unreadable logs somewhere (a warning in the UI, a session/repair-style command) instead of dropping them silently.

Environment

dsh 0.2.0-rc.2, web profile, Windows 11, $DSH_HOME=A:\dsh\home, 11 stored Sessions across 6 Workspaces.

[373831615]

Confirmed on 0.2.1-rc.2 (Windows, kernel bin.js web) — the membership filter silently drops manual registrations and there is still no re-attach/move API. Concrete case plus a verified workaround below, since the data model itself turns out to be workable.

Repro (2026-10-19, 25 idle sessions)

• 25 idle sessions created under workspace A, registered into workspace B's sessionIds (registry storage edit) and removed from archivedSessionIds.
• After a kernel restart: all 25 leave A's group and land in "Ungrouped". No error is surfaced anywhere.
• attachSession() throws cannot attach session '<id>' to workspace '<path>': its cwd resolves to '<cwd>', and Workspace.sessionIds is record.sessionIds.filter(id => host.candidateMatches(id, record.path)) where candidateMatches compares the canonical header cwd from the startup-time index.
• Registry edits made outside the kernel are also reverted on the next kernel persist (whole-file snapshot write-back): we observed 161 registered sessions rolled back to 136 after an unrelated workspace write.

Verified workaround (25/25 recovered, message contents intact)

1. Rewrite the header cwd inside the session log (session.v4.jsonl.zstd) to the target workspace path, and rebuild the log as canonical frames: frame 1 = exactly one header line (the assertZstdHeaderFrame contract), then the JSONL body frame(s). Naive single-frame rewriting breaks boot with corrupt Zstandard session log: first frame is not exactly one header line.
2. Register the ids in the target workspace and drop them from archivedSessionIds immediately before a kernel restart (the registry is a startup snapshot; anything written earlier can be clobbered).
3. After restart, a tiny one-off plugin injecting workspaceRegistry re-runs attachSession() through the official write path so the kernel itself persists the membership.

This is exactly what dsh session move (#10006) should do atomically: attachSession() could accept the header cwd rewrite as part of the attach (it is the only immutable input in the way), or grouping could trust explicit registry membership instead of re-filtering by startup-time cwd. Also relevant: #7573 (membership filter + startup-only cwd index + durable prune), #8561.

[smithfabian]

One clarification from Desktop 0.2.1-rc.3 that may help separate two different states:

1. Attach gap: some readable logs created through CLI/headless and seeded flows were never attached, even though their header cwd matched the Workspace path. mutate() cannot prune ids that were never in sessionIds; this is solely the missing-attach case.
2. Prune-on-write: an id that is already a member can disappear from the startup header index; the next mutate() then persists its removal through the candidateMatches filter. This is the destructive case described here.

The brief appearance while Workspace state is pending is read-time Ungrouped/bootstrap rendering, not evidence of membership. When checking attach candidates, I excluded parented/subagent logs and considered only top-level, cwd-matching Sessions. An additive, backup-first edit re-attached those out-of-band logs; it does not prove that they had previously been members.

A public attach operation, together with an authoritative or repairable header index, would address both cases without manual workspace.json edits.