Feature: Workspace should support multiple root paths (project with appended directories)

[ywsldxk]

Feature request: Workspace should support multiple root paths (a project with appended directories).

Problem

The Workspace model currently binds a single path (id/path/title/sessionIds). Users want a "project" concept: one project root + multiple appended directories, where all sessions under that project can access every path.

Example: project data-flywheel root E:\data-flywheel, appended paths E:\data-flywheel\processed, C:\Users\Acer\.codex\sessions.

Gaps

1. Data model: Workspace has no extraPaths field
2. Sandbox: workspace-write root = session.header.cwd only; appended paths cannot be written
3. Tool layer: sessionResolveOptions resolves relative to cwd only
4. UI: sidebar workspace has no "add path" entry

Requested

• Workspace.extraPaths: string[]
• read/glob/grep/bash/write allowlisted for extra paths (read at minimum; write configurable)
• sidebar workspace can add/display multiple paths
• persisted with the workspace; sessions auto-aware

Workaround today

danger-full-access mode + project-root AGENTS.md listing paths; model uses absolute paths. Works but is not a product-level capability.

Env: v0.1.0-rc.6 (47f9438)

[jjiangweilan]

+1 for this

[gullitmiranda]

+1 — this also blocks ACP multi-root support (Zed and other editors)

Adding another concrete consumer of this feature: the Agent Client Protocol (ACP) already has a wire field for it. NewSessionRequest carries additionalDirectories?: string[] — "Additional workspace roots for this session… expand the session's filesystem scope without changing cwd." Zed sends the workspace's extra roots there, and other ACP agents (Claude Code, Gemini CLI, Codex) honor them.

With dsh (via @openma/deepseek-harness-acp), Zed shows "This agent doesn't currently support multi-root workspaces" and the session stays confined to the first root. Even if the ACP adapter forwarded additionalDirectories today, it would have nowhere to put them — confirming the gap list above from the wire side:

• writableRoots(policy) in dsh-sandbox is built from the singular policy.workspaceRoot (+ /tmp fallbacks), so workspace-write can't cover extra roots.
• The fs layer resolves and confines paths against the session cwd only.
• Session persistence records a single meta.cwd, so session/load/fork/resume would also need to carry the extra roots.

One encouraging note: the sandbox profile renderers already iterate over a list of roots (roots.map(...) when building the Seatbelt profile) — the singular assumption lives in the policy type and its producers, not in the backends. So the ACP additionalDirectories field could map almost 1:1 onto Workspace.extraPaths once the model supports it.

Environment: dsh 0.1.0-rc.7, @openma/deepseek-harness-acp 0.4.14, Zed with a two-root workspace, macOS.

[li-jun]

+1
A feature like this is highly desirable—similar to VS Code workspaces—where multiple related projects can be added to a single workspace, enabling the AI ​​model to better analyze issues.