[Feature Idea] 多文件夹工作区与 primary 文件夹（对齐 Codex 的项目模型）

[vincent-guo]

[功能建议] 多文件夹工作区与 primary 文件夹（对齐 Codex 的项目模型）

摘要

DeepSeek Harness 目前把一个工作区（workspace）严格绑定到一个目录。本提案建议将工作区模型扩展为有序的文件夹列表，并指定其中一个为 primary，对齐 OpenAI Codex 桌面版已落地的多文件夹项目设计，同时保持现有「单目录」行为作为兼容默认值。

问题

真实项目很少只存在于一个目录里。一个典型任务往往横跨前端仓库、后端仓库和一个共享库。而目前 DSH 要求：

• 一个工作区只能对应一个目录（packages/workspace/workspace）——工作区是建立在唯一 canonical path 之上的持久记录；
• 一个会话只有一个 cwd，解析自 workspace.path（见 packages/api/session-controller/src/commands.ts）；
• 一次沙箱执行只有一个可写根：SandboxExecutionPolicy.workspaceRoot（见 packages/sandbox/sandbox/src/index.ts）。

因此跨目录工作只能依赖频繁的 danger-full-access 升级，或复制／移动文件——两者体验都很差。

Codex 的做法（参考）

Codex 把「组织」与「权限」分离，并且让每一层都可选：

• 项目（Project） 是组织单元，聚合相关对话，不要求任何文件夹。
• 本地项目可挂 0..N 个文件夹，通过 "Make primary" 指定其中一个为 primary。新对话、Git 操作、AGENTS.md／skills／config.toml 的自动发现都以 primary 为基准；secondary 文件夹可读可写可搜索，但不参与配置发现。
• 不建项目的对话是受支持的一等用法。
• 沙箱（可写根）是独立的一层，决定「能写什么」。

参考：https://learn.chatgpt.com/docs/projects

建议的 DSH 设计方案

对齐 Codex app 模型，映射到 DSH 现有分层：

1. 领域层——WorkspaceRecord 从单一 path 升级为有序 folders: string[]（第一项为 primary）。存量记录在启动时一次性迁移为 folders: [path]。唯一性不变量从「一个 canonical path 只属于一个工作区」扩展为「一个 canonical path 至多出现在一个工作区的文件夹集合中」（validateStoredState 同步收紧）。
2. 会话层（语义不变）——新会话的 cwd 仍等于 primary path，保持 SessionHeader 不可变契约。成员资格校验从 cwd === path 放宽为 cwd ∈ folders。变更 primary 只影响之后新建的会话；已有会话以当前文件夹集合作为可写范围。移除 secondary 只移除记录——文件与日志一概不动（与现有工作区删除不变量一致）。
3. 沙箱层（核心诉求）——SandboxExecutionPolicy 增加额外的可写根（workspaceRoot 仍作为 primary，用于展示与相对路径）。writableRoots() ——模式语义的唯一实现点——扩展为整个文件夹集合，并同步所有强制方言：Seatbelt、Bubblewrap、Landlock、Windows ACL（见 packages/sandbox/sandbox-local），以及进程内文件系统 fence。逐调用升级（sandbox_permissions）保持不变。
4. 发现层——AGENTS.md／config 发现保持单一锚点：primary 文件夹（即会话 cwd），对齐 Codex app 语义，避免多根合并的优先级与字节预算问题。secondary 仅提供读写与搜索。
5. GUI——「编辑工作区」增加 添加文件夹 与 设为 primary；工具卡片的相对路径摘要标注路径属于哪个根。

为什么这需要核心支持（插件边界）

按 CONTRIBUTING.md 的说明，生态路线是插件，而社区插件已经可以交付组织层（文件夹集合登记、primary 指定、侧边栏 UI）。但插件无法交付强制层：ctx.sandbox 是单实现 seam，且逐调用策略只携带一个可写根，secondary 的写入会退化为逐调用 danger-full-access 审批。因此本提案请求核心团队开放最小的 API 面——多根可写策略——同时社区插件可以先行承担组织层。

备选方案

• 会话级文件夹（对齐 Codex CLI --add-dir）：改动更小，但没有持久化与项目分组能力；保留为未来可能的会话级覆盖项。
• 每文件夹权限级别（对齐 Codex CLI permissions）：最灵活，但 profile 生成与 UI 成本显著更高；明确不在 v1 范围内（v1 中 secondary 与 Codex app 一致，可读写）。

风险与迁移

• 沙箱多根会触及四个内核级 runner 与文件系统 fence——工作量最大、最需要谨慎的部分；应在 runner 级别配测试（各方言的等价性约束已由 roots.ts 的文档明确）。
• 多代码库带来的上下文窗口压力；由于发现层保持仅 primary，风险可控。
• 领域 schema 迁移必须一次性、向后兼容、可崩溃恢复（工作区域已具备 pending-mutation 恢复模式可供复用）。

English TL;DR

DeepSeek Harness currently binds one workspace to exactly one directory, while real work spans multiple repositories. Codex solves this with optional multi-folder projects: a project may attach 0..N folders with one designated primary (driving new chats and config discovery), secondaries are readable/writable/searchable but excluded from discovery, and chats work without a project at all. This proposal asks DSH to adopt the same model: WorkspaceRecord.path becomes an ordered folders[] (existing records migrate automatically), a session's cwd stays the primary (preserving the immutable SessionHeader contract), SandboxExecutionPolicy gains additional writable roots across all four runners and the fs fence, and AGENTS.md discovery stays primary-only. The sandbox multi-root policy is the one API surface a plugin cannot reach (ctx.sandbox is a single-implementation seam); the organizational layer can meanwhile be carried by a community plugin.

English version (full text)

Summary

DeepSeek Harness currently binds one workspace to exactly one directory. This proposal extends the workspace model to an ordered list of folders with a designated primary folder, mirroring the multi-folder project design OpenAI Codex shipped in its desktop app, while keeping today's one-directory behavior as the compatible default.

Problem

Real projects rarely live in a single directory. A typical task spans a frontend repo, a backend repo, and a shared library. Today DSH requires:

• one directory per workspace (packages/workspace/workspace) — a workspace is a durable record over exactly one canonical path;
• one cwd per session, resolved as workspace.path (see packages/api/session-controller/src/commands.ts);
• one writable root per sandboxed execution (SandboxExecutionPolicy.workspaceRoot in packages/sandbox/sandbox/src/index.ts).

Working across directories therefore means either frequent danger-full-access escalations or copying/moving files — both poor experiences.

How Codex solves it (reference)

Codex separates organization from permissions, and makes every layer optional:

• Project = an organizational unit holding related chats; it does not require folders.
• Local project may attach 0..N folders; one is designated primary via "Make primary". New chats, Git operations, and automatic discovery of AGENTS.md / skills / config.toml all use the primary folder. Secondary folders are fully readable/writable/searchable but do not participate in configuration discovery.
• Chats without a project are a supported first-class case.
• The sandbox (writable roots) is an independent layer that decides what can be written.

Reference: https://learn.chatgpt.com/docs/projects

Proposed design for DSH

Aligned with the Codex app model, mapped onto DSH's existing layers:

1. Domain layer — WorkspaceRecord gains an ordered folders: string[] in place of the single path (first entry = primary). Existing records migrate once at startup to folders: [path]. The uniqueness invariant extends from "one canonical path per workspace" to "a canonical path may appear in at most one workspace's folder set" (validateStoredState tightened accordingly).
2. Session layer (unchanged semantics) — a new session's cwd remains the primary path, preserving the immutable-SessionHeader contract. Membership validation relaxes from cwd === path to cwd ∈ folders. Changing the primary affects only sessions created afterwards; existing sessions inherit the current folder set as their writable scope. Removing a secondary folder only removes the record — files and logs are never touched (same invariant as workspace deletion today).
3. Sandbox layer (the core ask) — SandboxExecutionPolicy gains additional writable roots (workspaceRoot stays primary for display/relative-path purposes). writableRoots() — the single home of the mode's meaning — extends to the folder set, and every enforcing dialect follows: Seatbelt, Bubblewrap, Landlock, and the Windows ACL runner in packages/sandbox/sandbox-local, plus the in-process filesystem fence. Per-call escalation (sandbox_permissions) remains unchanged.
4. Discovery — AGENTS.md/config discovery keeps a single anchor: the primary folder (the session cwd), matching Codex app semantics and avoiding multi-root merge/precedence/budget questions. Secondary folders are read/write/search only.
5. GUI — "Edit workspace" gains Add folder and Make primary; tool-card relative path summaries label which root a path belongs to.

Why this needs core support (the plugin boundary)

Per CONTRIBUTING.md, the ecosystem route is plugins, and a community plugin can already deliver the organizational layer (folder-set registry, primary designation, sidebar UI). It cannot deliver the enforcement layer: ctx.sandbox is a single-implementation seam, and the per-call policy carries exactly one writable root. Secondary-folder writes would degrade to per-call danger-full-access approval. This proposal therefore asks the core team to open the minimal API surface — multi-root writable policy — while a community plugin can carry the organizational layer in the meantime.

Alternatives considered

• Session-level folders (Codex CLI --add-dir parity): smaller change, but no persistence or project grouping; kept as a possible future per-session override.
• Per-folder permission profiles (Codex CLI permissions parity): most flexible, significantly more work in profile generation and UI; explicitly out of scope for v1 (secondary folders read/write like Codex app).

Risks / migration

• Sandbox multi-root touches four kernel-level runners plus the fs fence — the largest, most safety-sensitive change; it should land with runner-level tests (the per-dialect parity is already documented in roots.ts).
• Context-window pressure from multiple codebases; mitigated because discovery stays primary-only.
• Domain schema migration must be one-time, backward-compatible, and crash-recoverable (the workspace domain already has a pending-mutation recovery pattern to build on).

[codelearner1024]

目前支持了吗 ? 多根聚合 kiro codex 都是可以的 qoder等 是个非常实用的功能, 我也是搜索dsh是否有这个功能, 才发现已经有人提了, 就在这追踪了