[Feature] Directory-scoped write authorization — remember allowed folders for this session

[etzhe]

📌 更新 / Update — 2026-08-31 17:56 UTC+8
根据社区 @weijiafu14（逐文件核对 rc.2 源码）的反馈修正：

• 本需求是权限词汇表里的一个新维度（目录级 scoping），不是在现有 grant 上加"记忆"（否则记下的会是整会话 danger-full-access，恰是我不想要的）。
• 已确认无插件侧解决方案（ctx.sandboxPolicy 无 setter；permissionPresets 只有 ask/never、无 path 维度）→ 必须由上游在 sandbox 层实现。
• 临时 workaround：将会话 cwd 设在工作区与目标文件夹的共同父目录下可入单一 workspace-write 根；代价是纳入该父目录下其他一切，仅当其本就受信任时适用。

Summary

In the DSH web interface, writing files outside the current workspace root always prompts for approval — once per file / per request. There is no way to say "trust these 1–2 specific folders for the rest of this session, and stop asking me for every file inside them." The only options today are a global ask (every file prompts) or a global never / danger-full-access (everything is allowed, including dirs you never wanted touched).

This is a common workflow: a session repeatedly works with a fixed set of folders outside the workspace (e.g. another project dir, a data folder, or a network share). Users want a narrow, per-directory grant — not a whole-conversation full-access switch.

Expected behavior

Add a directory-scoped authorization so a user can:

• Approve writing into one or a few specific directories for the rest of the current session.
• After that, any write under those directories proceeds without re-prompting.
• Everything outside those directories still behaves as today (ask → per-file approval), so the safe boundary is preserved.

This is the "allow editing this folder" pattern familiar from Claude Code / WorkBuddy, but scoped per-session.

Environment

• @deepseek-ai/dsh version: 0.1.1-rc.2

Root cause (traced in source)

The approval grant is strictly per request and has no memory of a path/directory.

In packages/.../dsh-user-approval:

• request() issues a fresh ApprovalRequestId(randomUUID()) and appends a new approval/asked event every time — call IDs and events are independent, nothing is reused/keyed by path.
• decide() resolves the policy via effectivePolicy(session) (ask / never) and dispatches an approval/request waterfall. The only grant value is "allowed-once" ("allowed-once" is the only grant). There is no "approved directory, skip future prompts for this session" state.

Sandbox is likewise single-root:

• dsh-sandbox-policy resolves one workspaceRoot per session (resolveWorkspaceRoot(session?.header.cwd ?? this.workspaceRoot)); workspace-write only permits writing inside that one root. Outside it, writes are denied and need an escalation grant (per request). There is no additional write-whitelist / extra allowed directories list.
• dsh-sandbox exposes writableRoots, which is the single workspace root (+ temp), not a user-configurable set of directories.

So the model is: one workspace root = free write; everything else = per-request approval (with allowed-once), or all-or-nothing danger-full-access. There is no middle layer of "these N directories are trusted this session."

Suggested approach

A natural fit is to extend the approval/sandbox policy to accept a per-session list of granted directories:

1. Add a grant type (e.g. allowed-dir) alongside allowed-once, recording a normalized path. On a write request, if the target path is lexically under a granted directory, resolve to allowed without prompting.
2. Sessions hold the granted directories in their log (like permission/preset / sandbox/mode / approval/policy), so replay reconstructs the same trust set.
3. In the UI, when a write outside the workspace is requested, offer an explicit choice: "Allow once" vs "Allow [this directory] for this session".

This keeps the safe boundary intact (only trusted directories are auto-allowed) while removing the repeated prompts for folders a user already vouched for.

Related context

This overlaps with, but is distinct from:

• [Bug / Sandbox]: Inconsistent mode escalation vs path whitelist, silent permission drift, and write side-effects in --dump-config #1807 — a Bug report about the sandbox path whitelist (AllowedPathsSet) being inconsistent with mode escalation, causing silent permission drift. That is a bug in the existing whitelist mechanism; this request is a new feature to let a user explicitly trust a directory for the session.
• [Security] Web minimal preset allows unapproved writes outside workspace-write on Windows #523 — a Q&A about the web minimal preset allowing unapproved writes outside the workspace.

Motivation

danger-full-access is too broad — it disables prompts for everything, including sensitive dirs (~/.dsh, ~/.claude, ~/.workbuddy, network shares) the user never intended to authorize. A directory-scoped grant gives the precision of per-file approval with the convenience of a session-level trust boundary.

Thank you!

[weijiafu14]

Your trace is right, and I want to push the root cause one layer deeper, because it changes what the feature request is.

It is not that grants aren't remembered. It is that a grant has no path in it to remember.

Reading the escalation path end to end (packages/sandbox/sandbox/src/escalation.ts, packages/fs/tool-fs/src/sandbox.ts, packages/sandbox/sandbox-policy/src/index.ts on the 0.1.1-rc.2 line):

• approveEscalation(...) returns a SandboxMode, and ESCALATION_TARGETS is the closed set ['workspace-write', 'danger-full-access']. The grant's entire payload is a rung on a 3-value ladder.
• WIDER_MODES['workspace-write'] === ['danger-full-access']. So when you are in workspace-write and touch a file outside the root, the only thing that can be asked for is full access. Every prompt you are clicking through is a one-shot danger-full-access, not "allow this file".
• SandboxPolicyService.resolve() builds workspaceRoot: resolveWorkspaceRoot(session?.header.cwd ?? this.workspaceRoot) — one root, derived from the session's cwd, and overrideOf(session) returns a SandboxMode | undefined, i.e. a rung, not a path.

The consequence for your proposal: bolting memory onto the existing grant would remember "this session may use danger-full-access" — which is exactly the whole-conversation full-access switch you said you did not want. Directory scoping is a new dimension in the vocabulary, not a persistence feature on top of the current one. Worth framing the request that way, since the cheap-sounding version ("just remember the grant") produces the outcome you are trying to avoid.

Can a third-party plugin do this instead? No — and I checked rather than assumed. I enumerated the public services on Context from a real install tree. ctx.sandboxPolicy exposes resolve and overrideOf and no setter. ctx.permissionPresets does have set(session, name), so a plugin can genuinely flip DSH's own preset — but presets are ask / never, which has no path dimension either, so it lands you in the same place. There is no out-of-tree path to this feature; it has to be upstream, in the sandbox layer.

One thing available today that may cover your actual workflow. Since the root is resolveWorkspaceRoot(session.header.cwd), starting the session with its cwd at a common parent of your workspace and those 1–2 folders puts all of them inside a single workspace-write root, with no prompts and without turning on full access. The honest cost is that it also admits everything else under that parent, so it is only a real answer when the folders sit under a parent you would have trusted anyway. It is a workaround for a layout, not a substitute for the feature.

Interest disclosure: I maintain a third-party DSH plugin. The seam enumeration above is the reason I know there is no plugin-side answer here — I went looking for one for a related request and there is not one. We do not and cannot touch DSH's sandbox.

[etzhe]

Thanks for reading it end to end and pushing the root cause one layer deeper — the point that a grant has no path in it to remember is the key framing. I'll reframe this as a new dimension in the vocabulary (directory scoping), not a persistence feature on top of the current grant, and note that bolting memory onto it would just remember "danger-full-access," which is exactly what I wanted to avoid.

The workaround (starting the session's cwd at a common parent of the workspace + those folders) is a useful practical note — I'll present it as a workaround for a layout, not a substitute for the feature. And thanks for actually enumerating the seam (no setter on sandboxPolicy, presets only ask/never) — that confirms there's no plugin-side answer and it has to be upstream in the sandbox layer.