feat(sidebar): first-class workspace-less "chat" sessions — Work/Chat affordance in the sidebar and a "no workspace" option in the picker

[omnisurge]

Summary

Today the Web GUI can only start a session bound to a workspace. But a large class of conversations has no project: "help me configure dsh", quick Q&A, one-off errands, talking through an idea. Users currently must either pollute a real project workspace with chatter or create a throwaway folder just to talk.

Proposal: make workspace-less chat sessions a first-class citizen — a Work/Chat distinction in the session sidebar, plus a "no workspace" option in the workspace picker when starting a session.

The session model already supports this (no core change needed)

• session.create accepts payloads with neither workspaceId nor cwd (packages/host/apiproxy/src/api/sessions.schema.ts:101-110) and falls back to the deployment default directory (api-proxy.ts:2180: workspace?.path ?? payload.cwd ?? defaults.cwd).
• So a "chat session" is already representable — what is missing is purely the client affordance and a presentation rule for where such sessions live in the sidebar.

Proposal

A. Work/Chat segmentation in the session sidebar (primary vision).
Let users switch between "Work" (workspace-bound sessions, today's view) and "Chat" (workspace-less sessions) — e.g. a small tab pair at the top of the sidebar, or a distinct sidebar section. Optional flourish: a mode accent (e.g. two tints of the orca mark) so the current mode is glanceable.

B. A "no workspace" option in the workspace picker.
When starting a session, the picker currently offers only registered workspaces + "add workspace". Add a "Chat (no workspace)" entry that creates the session without a workspace binding.

C. Minimal variant — an extension slot instead of built-in UI.
If first-class UI is more than you want to commit to, a list slot in the workspace-picker menu (and/or the sidebar session area) would let plugins ship the entry themselves — consistent with the existing slot architecture (sidebar.footer.action, settings.*, conversation.input.left, the directoryFlow holes). Zero behavior change when nothing registers.

Open questions (for you)

• Where should workspace-less sessions be stored/grouped — the deployment defaults.cwd, a designated directory, or a virtual group independent of cwd?
• Should defaults.cwd become user-configurable in settings?
• Does a chat session default to a particular agent preset (e.g. minimal) or keep the user's current selection?

Downstream context

We ship a downstream distribution (omnidsh). In the meantime we plan to prototype a "new chat" entry via the sanctioned sidebar.footer.action list slot, creating sessions against a designated chat directory — happy to retire it the moment a first-class affordance lands.

[omnisurge]

One concrete accent idea for the mode distinction, if the Work/Chat split ever lands: the orca mark already exists in two recognizable tints — black (the current dsh logo) for Work mode, and blue (the DeepSeek app's logo) for Chat mode. Same mark, two tints: instant mode recognition with zero new iconography, and it visually ties the chat mode to the familiar DeepSeek consumer brand.