support grouping sessions

[pixel4696]

there might be too many chats within a single workspace, it's nice to add groupings

also it's nice to support workspace-less chats

[denial123789]

I think this contains two separate contracts.

In rc.2, the Web tree already groups Sessions by registered canonical Workspace and puts Sessions outside those accounts under Ungrouped. That grouping is execution-adjacent because SessionHeader.cwd is the root used by relative filesystem and bash work. A user-defined group should therefore be separate mutable navigation metadata keyed by SessionId; rename, move, and delete must not change cwd, sandbox mode, tools, lineage, archive state, or retention. Deleting a group should only ungroup its Sessions.

For workspace-less chat, I would make the execution profile explicit: conversation-only with workspace-bound tools omitted; a unique quota-bound ephemeral sandbox; or attach-later with those tools disabled until a directory is selected. It should never fall back to process.cwd(), home, /, the last Workspace, or a group title. Because rc.2 SessionHeader.cwd is immutable and tools read it directly, attaching a folder is safest as a fork into a rooted Session unless a versioned execution-root event is introduced.

I wrote up the data contract, revision conflicts, archive/restore semantics, migration order, and acceptance tests here: https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/operations/session-groups-workspace-less.md

[exoticknight]

The workspace-less part came up for me too while building a small DSH plugin.

https://github.com/exoticknight/dsh-just-chat

For real grouping and workspace-less execution, I agree the session/workspace boundary and execution profile need to be defined upstream rather than inferred from a group or directory.