Multi-user support: per-user session visibility behind an SSO proxy

[gerd-collab]

Summary

When the Harness web UI is served behind an authentication boundary (e.g. Authelia
forward-auth, as documented in packages/client/connection), every authenticated
user currently sees all sessions of the deployment and can open/continue any of
them. I propose per-user session isolation: each user sees, opens, and continues
only their own chats.

Why

• DSH is a single-operator tool today — that is fine for one person, but many of us
  self-host a shared instance behind SSO (Authelia, Authentik, etc.) and want the
  same UX as Open WebUI: one deployment, many users, each with their own chat
  history.
• The authentication boundary already works (that part is explicitly supported:
  trustedHosts + privilegedHosts unlock the privileged plane for browsers behind
  a reverse-proxy authenticator). What is missing is the identity → data scoping
  step.

Current behavior (verified in the code)

• DSH has no authenticated-user concept. packages/identity/ is only an
  anonymous telemetry correlation id ("does not represent an authenticated
  account").
• session.list returns every session of the deployment; its request payload is
  just a reserved cursor (see packages/host/apiproxy/src/api/sessions.schema.ts).
• Session persistence is keyed only by (cwd, sessionId) — no owner dimension:
  JSONL at <root>/<project-dir>/<session-id>/session.jsonl
  (packages/session/session-persistence-jsonl/src/format.ts), or the SQLite
  backend. There is no tenant/user column and no per-user path segment.
• So any user who passes the SSO gate sees and can drive every chat, and — since DSH
  agents run bash/filesystem tools on the host — can also access the underlying
  files directly.

Proposed change

1. Identity capture: read the authenticated user from the trusted proxy's header
   (Remote-User / X-Forwarded-User), behind the existing trust fence; make the
   header name configurable.
2. Per-user persistence namespace: scope session storage per user
   (e.g. <root>/users/<user>/<project>/<session>/… for JSONL, or an owner column
   for SQLite).
3. Per-user queries: filter session.list, session.search, and session
   creation/open/continuation by the authenticated user; sessionIds only resolve
   within the user's own namespace.
4. Backward compatibility: unauthenticated/loopback access keeps today's
   behavior (single operator, existing data untouched); document a migration path
   for existing global sessions.

Acceptance criteria

• After SSO login, session.list / session.search show only the current user's
  sessions.
• New sessions are created under the user's own namespace.
• A user cannot open or continue another user's session id (server-side check, not
  just UI hiding).
• Loopback/local access behaves exactly as before.

Scope note / related

• Chat/session isolation is the ask here. Full multi-user hardening (per-user OS
  sandboxing of bash/filesystem tools, quotas, approval scoping) is a separate,
  larger topic worth its own discussion.
• If a community plugin already covers this, please point me to it — happy to
  upvote/contribute there instead.

[LooKeng]

Adding a concrete use case + implementation direction, because this is exactly the multi-user shape we are trying to make upstreamable.

For our first slice, I think this should be treated as application-level ownership, not strong OS/container isolation:

• a deployment may still run one DSH Web host process;
• the auth gateway / SSO / Open WebUI-like front door supplies the authenticated user;
• DSH records and enforces ownership for conversation/session history;
• DSH also records and enforces ownership for workspace/project history;
• new sessions should default to a per-user workspace root;
• admins need an explicit bypass/repair policy;
• auth-disabled local mode should preserve today's single-user behavior.

Suggested PR decomposition:

1. Request-local identity context for host-side API calls, disabled by default.
2. Trusted-header resolver for authenticated reverse-proxy deployments.
3. Session owner metadata or side-index: list/search/history/export/mutations/event-stream filtering.
4. Workspace owner metadata or side-index: workspace list/mutations and workspace-to-session membership checks.
5. Per-user default workspace root under a deployment-configured base.
6. Admin + legacy-unowned behavior.

I wrote a fuller tracking draft in a fork issue here, keeping it upstream-safe because this repository currently has GitHub Issues disabled: ChatArch#1

The key point is that this does not require solving per-user shell/container isolation first. It would already address the Web product problem: users should not see or mutate each other's sessions, conversation history, or project/workspace history.