Feature request: per-workspace extra writable directories (工作区可配置"额外可写目录" — 显式沙箱授权)

[pbannister]

Feature request: per-workspace extra writable directories (an overt sandbox grant)

One line: Let a workspace declare one or more directories outside the workspace root as explicitly writable, so the sandbox permits writes there without a per-call approval prompt.

Motivation

workspace-write confines writes to the workspace root (the session cwd) plus platform temp dirs. In real work, projects frequently need to write into one or two sibling directories outside the project dir — on other storage, or shared with other projects. Today every such write is denied by the sandbox and requires an approval prompt (the agent retries with sandbox_permissions + justification, and the user approves). That is correct but tedious when the same external directories recur across a session or across many sessions.

What is missing is an overt, declarative grant: "this workspace may write to these extra directories." Not per-call approval — a standing grant visible in the UI and in the model-facing policy.

Why not symlinks

Creating a symlink inside the workspace pointing at an outside directory does NOT grant write access: both enforcement layers canonicalize (realpath) before deciding. The in-process fs fence re-resolves the target and checks containment against the writable roots; the kernel runners (bwrap/Landlock/Seatbelt/Windows ACL) grant only the canonical workspace root, and the kernel follows the symlink to the outside target, which has no grant. I verified this in the source. This is correct behavior and should stay closed: a symlink is not an overt grant. The feature below is the overt grant.

Proposed behavior

1. Configurable extra writable roots per workspace (absolute paths), e.g. a list on the workspace record or a sandboxPolicy.extraRoots-style config, canonicalized exactly like the workspace root.
2. One shared derivation, no drift: writableRoots in packages/sandbox/sandbox/src/roots.ts is already the single home of the writable allowlist, consumed by the fs fence and the Seatbelt profile; thread the extra roots through the same SandboxExecutionPolicy so fs tools and bash agree on exactly the same granted set.
3. UI surface: a settings row or workspace editor listing the extra writable directories, with add/remove via the existing directory picker; the model-visible runtime-context policy snapshot names the granted roots so the model knows them.
4. Semantics: writes under an extra root succeed without approval; writes anywhere else behave exactly as today (deny → approved escalation). Reads remain unrestricted. Temp dirs unchanged. Approval policy (ask/never) and audit events unchanged.

Acceptance criteria

• With an extra root configured, a write under it succeeds with no prompt; without the grant, the same write prompts as today.
• fs tools and bash confine to the same granted set (no "fs can, bash can't" asymmetry).
• Extra roots are canonicalized: a symlinked spelling resolves, and a symlink inside the workspace pointing at a granted root works only because the target itself is granted.
• Removing an extra root revokes the grant without a server restart.
• The grant list is visible in the UI and in the model-visible policy context.

Notes

• I have no strong opinion on where the list lives (workspace record vs deployment config vs settings); per-workspace feels most natural.
• Happy to provide more detail, test scenarios, or help validate a prototype.

---

功能请求：工作区可配置的"额外可写目录"（显式沙箱授权）

一句话说明预期结果： 允许一个工作区显式声明工作区根目录之外的一个或多个目录为可写，沙箱对这些目录的写入不再需要逐次审批弹窗。

动机

workspace-write 模式把写入限制在工作区根目录（会话 cwd）加平台临时目录内。实际工作中，项目经常需要写入项目目录旁边的一两个兄弟目录——它们可能位于其他存储上，或与其他项目共享。目前每一次这类写入都会被沙箱拒绝并触发审批弹窗（agent 携带 sandbox_permissions + justification 重试，由用户批准）。行为正确，但当同样的外部目录在一个会话或多个会话中反复出现时，逐次批准既繁琐又打断流程。

缺少的是一种显式、声明式的授权："本工作区可以写入这些额外目录"。不是逐次审批，而是可以在 UI 和模型可见策略中看到的常驻授权。

为什么符号链接不行

在工作区内创建指向外部目录的符号链接不会授予写入权限：两层强制机制都会在判定前做规范化（realpath）。进程内 fs 围栏会重新解析目标并对照可写根目录做包含检查；内核运行器（bwrap/Landlock/Seatbelt/Windows ACL）只授予规范化的工作区根目录，内核会沿符号链接解析到外部目标，而那里没有任何授权。我已在源码中核实过这一点。这是正确行为，应当继续保持封闭：符号链接不是显式授权。下面的功能才是显式授权。

建议行为

1. 每个工作区可配置的额外可写根目录（绝对路径），例如工作区记录上的列表，或 sandboxPolicy.extraRoots 风格的配置，并与工作区根目录一样做规范化。
2. 单一共享推导、杜绝漂移： packages/sandbox/sandbox/src/roots.ts 中的 writableRoots 已是可写白名单的唯一归属，fs 围栏和 Seatbelt 配置都消费它；把额外根目录通过同一个 SandboxExecutionPolicy 传递，使 fs 工具与 bash 对授权集合的理解完全一致。
3. UI 呈现： 在设置或工作区编辑器中列出额外可写目录，通过现有目录选择器增删；模型可见的运行时上下文策略快照点名已授权根目录，让模型知晓。
4. 语义： 额外根目录下的写入无需审批即可成功；其余位置的写入行为与今天完全一致（先拒绝，再经审批升级）。读取保持不受限。临时目录不变。审批策略（ask/never）与审计事件不变。

验收条件

• 配置额外根目录后，在其下写入不弹提示；未配置授权时，同样的写入仍按现状弹提示。
• fs 工具与 bash 对同一授权集合保持一致（不存在"fs 可以、bash 不可以"的不对称）。
• 额外根目录会被规范化：符号链接拼写被解析为真实路径；工作区内指向已授权根目录的符号链接可用，只是因为目标本身已授权。
• 移除某个额外根目录后，无需重启服务器即可撤销授权。
• 授权列表在 UI 和模型可见的策略上下文中均可查看。

备注

• 对列表存放位置（工作区记录 / 部署配置 / 设置）没有强烈意见；按工作区存放感觉最自然。
• 愿意提供更多细节、测试场景，或协助验证原型。

[pbannister]

To be clear, I am still on the learning curve with use of LLMs in development (a few months in). Though I do have considerable experience. I have been using Harness as an aid (with Deepseek V4), and find it quite useful.

Still discovering patterns of use for this sort of development. Compiled a project skeleton (in https://github.com/pbannister/00-project-skeleton) and use it as a base for new projects. There are dependencies between projects, and that is where I presently run into frequent sandbox violations. Wanted to make an overt grant for that pattern of use.

Pointed the Harness workspace at the Harness git repo, and asked if an overt grant was possible. (Always possible I may have missed something.) After introspecting the Harness repo, Deepseek reports that an overt grant is not possible. That lead to this feature request.

Which makes this a very thoroughly researched request. I am rather enjoying these new tools. :)

[pbannister]

Follow-up from the author: the mount --bind workaround is working well for me and meets my current needs — the filesystem tools treat the bind-mounted directory as a real path under the workspace root, so writes there go through without an approval prompt. I have not yet tested the bash/bwrap path (I was about to, but the bind mount already solves my case).

The core motivation for this request still stands: reads were never the problem (they are unrestricted), but every write outside the workspace requires an approval, and those prompts interrupt the flow of work often. An explicit, per-workspace list of extra writable directories — visible in the UI and in the model-visible policy context, and enforced uniformly by every sandbox dialect — would remove that friction properly, without relying on a host-level bind mount.

Happy to help validate a prototype if this is picked up.

---

作者跟进：mount --bind 方案对我很好用，已满足当前需求——文件系统工具会把绑定挂载的目录当作工作区根目录下的真实路径，写入不再触发审批弹窗。我还没有测试 bash/bwrap 路径（本打算测，但绑定挂载已经解决了我的问题）。

本请求的核心动机依然成立：读取从来不是问题（本就不受限），但工作区之外的每一次写入都需要审批，这些弹窗经常打断工作流。一份显式、按工作区配置的额外可写目录列表——在 UI 和模型可见的策略上下文中均可查看，并由所有沙箱方言统一执行——才能真正消除这种摩擦，而不必依赖宿主层的绑定挂载。

如果该功能被采纳，我乐意协助验证原型。

[NateScarlet]

Your "why not symlinks" section matches what I found on Windows, and there is a third route that does work — worth adding to the list, because it needs no approval prompt and no host-level mount.

The grant has to name the target, not point at it

You are right that a symlink cannot carry the grant: both layers canonicalize first, and the kernel follows the link to a target that was never granted. The Windows rung has the same property, and its grant mechanism makes the fix explicit: workspace-write mints a WRITE_RESTRICTED token whose restricting SIDs include a capability SID derived from the canonical workspace path. Write access requires both the normal and the restricting check to pass, so a directory is writable exactly when its own DACL carries an inheritable allow-write ACE naming that SID.

That means the grant can be put on the target directly. No symlink, no bind mount, no fstab, no root, and it survives across sessions and restarts.

Verified, with controls

Windows 11, session under workspace-write:

computed workspaceWriteSid = S-1-4-1022062912-955841020
Get-Acl <workspace> -> S-1-4-1022062912-955841020  (Write, Delete, …, inheritable)

After granting a git directory outside the workspace, git add + git commit wrote objects and refs there with no approval prompt. Two controls, because "it worked" is worth little without them:

• A write to C:\Windows\Temp in the same session still failed with UnauthorizedAccessException — the session was genuinely still confined.
• Under read-only the standing ACE is inert: that token's restricting list carries no capability SID, so the intersection grants nothing.

How this differs from what you and @weijiafu14 converged on

weijiafu14's point — that the grant has no path in it to remember, so bolting memory onto allowed-once would just remember danger-full-access — is confirmed by this mechanism. The restricting list is a fixed set of SIDs chosen by DSH; a session cannot add one. The ACL route sidesteps that by not asking DSH for anything: it makes an already-present SID match an additional directory.

The honest trade-offs, which are why this is a stopgap rather than the answer:

	allowed-dir / extraRoots (this request)	ACL grant
Scope	session or workspace, per your design	tied to the workspace path via the SID
Cross-workspace	configurable	no — different workspace, different SID
Model-visible	yes	no — undisclosed writable area
Platforms	all	Windows only
Revocation	remove from config	explicit revoke pass

The model-visibility gap is the one that matters most; it is exactly the asymmetry roots.ts exists to prevent, and it means an agent may still refuse a write it could actually perform.

https://github.com/NateScarlet/Scripts/blob/dcae2371b3c57a08615e3732f4d4bd68e8861fb6/specialized/dsh_sandbox_grant.py

Supports your framing that directory scoping is a new dimension in the vocabulary.