[Bug] Windows 的极简模式运行 Shell 工具时报错，str_replace_editor 工具在 Read Only 的情况下可读写工作区外文件

[watermelon233nori]

代码分析部分完全使用 DeepSeek Harness 完成，本人没有动过一点大脑（）我对 Node 的了解比较少，这个 Discussion 也是大晚上写的，估计比较烂，凑合看看，轻喷（

---

我听到 Linux + Minimal 能发挥几乎全部实力，我就吭哧吭哧跑来了，虽然我是 Windows，搭配的是 PowerShell，但我觉得也可以试一下，结果 subprocess-local 盖了我一巴掌（bushi

测试环境：Windows 11 23H2 (22631.6199)

DSH 启动参数：npx @deepseek-ai/dsh web（默认，设置我也没调）

Windows 的极简模式下运行命令出错的问题很简单，我觉得大伙也知道：

极简模式没有根据平台区分 Shell 工具，而 subprocess-local 因为平台不对直接打回去了，喜提 Error: subprocess-local: terminal inspection is unsupported on platform win32。当然用户侧已经有一个解决方案了，比如 #1832 和对应的插件仓库。

标准模式倒是有按平台区分，DSH 核心也是这么做的：

deepseek-harness/packages/bundle/base/cordis.patch.yml

Lines 210 to 216 in 47f9438

	- id: tool-bash
	name: '@deepseek-ai/dsh-tool-bash'
	disabled: !!js process.platform === 'win32'
	- id: tool-pwsh
	name: '@deepseek-ai/dsh-tool-pwsh'
	disabled: !!js process.platform !== 'win32'

deepseek-harness/apps/cli/config/agent-presets/standard/agent.cordis.yml

Lines 35 to 50 in 47f9438

	# ── shell ───────────────────────────────────────────────────────────────────
	# `shell-env` stays in the HOST composition: `apps/cli/src/web.ts` injects it to
	# publish `DSH_WEB_URL`/`DSH_WEB_MODE`, and a host row that injects a service is
	# the criterion for host-plane ownership — injection resolves before any session
	# exists, so there is no agent to key by. Behind a preset realm those variables
	# never reached the model's shell at all. Both shell tools consume the host
	# registry from here; their executors (`bash-sandbox`/`pwsh-sandbox`) are
	# host-plane too.
	- id: tool-bash
	name: '@deepseek-ai/dsh-tool-bash'
	disabled: !!js process.platform === 'win32'
	- id: tool-pwsh
	name: '@deepseek-ai/dsh-tool-pwsh'
	disabled: !!js process.platform !== 'win32'

---

接下来是另一个问题：

我在尝试 Minimal 的过程中发现 str_replace_editor 可以任意读取工作区外的文件，我个人十分担忧，但大肥鱼跟我说这是工程取舍。我没怎么经常使用 AI 编程，不知道大伙怎么想的（）让别人能够读你工作区的密钥和私人文件，就算对面是只大肥鱼心里也会担忧吧（

但我让大肥鱼分析源码之后发现这个工具没有读限制，也没有写限制。没错，你在权限为 Read Only 的情况下也能读写，str_replace_editor 使用的文件系统 shadow 了宿主的文件系统沙箱，甚至源码里都写了相应的注释：

deepseek-harness/apps/cli/config/agent-presets/minimal/agent.cordis.yml

Lines 46 to 62 in 47f9438

	# The bare local filesystem shadows the host's sandboxed provider only for this
	# preset. The editor shares that realm and requires absolute paths.
	- id: filesystem
	name: cordis:group
	group: true
	isolate:
	fs: true
	config:
	- id: fs-local
	name: '@deepseek-ai/dsh-fs-local'
	config:
	cwd: !!js process.env.DSH_CWD ?? process.cwd()
	- id: str-replace-editor
	name: '@deepseek-ai/dsh-tool-str-replace-editor'
	config:
	maxOutputChars: 16000

测试我也简单的测了一下：

那么什么所谓的根因链我就引用大肥鱼的报告：

根因链（代码路径）

1. 极简 preset 给编辑器接了一个"裸"文件系统后端 — apps/cli/config/agent-presets/minimal/agent.cordis.yml:46-62：

   - id: filesystem
     group: true
     isolate: { fs: true }
     config:
       - id: fs-local          # @deepseek-ai/dsh-fs-local（无沙箱）
         config: { cwd: !!js process.env.DSH_CWD ?? process.cwd() }
       - id: str-replace-editor # @deepseek-ai/dsh-tool-str-replace-editor

   注释自认："The bare local filesystem shadows the host's sandboxed provider only for this preset."

2. 隔离 realm 的遮蔽机制 — isolate: { fs: true } 在组内开辟独立 fs 作用域（Cordis ctx.isolate 语义，见 docs/cordis-api/context.md）；组内 fs-local 在该 realm 提供 fs，遮蔽了根 realm 的宿主 fs-sandbox（packages/bundle/base/cordis.patch.yml:443-444）。编辑器 inject = ['tools', 'fs']（packages/fs/tool-str-replace-editor/src/index.ts:494）按名字解析，最近提供者获胜。

   deepseek-harness/packages/bundle/base/cordis.patch.yml

   Lines 441 to 444 in 47f9438

   	# The sandboxed filesystem provider. `cwd` defaults to `process.cwd()`; an
   	# overlay can pin another workspace.
   	- id: fs-sandbox
   	name: '@deepseek-ai/dsh-fs-sandbox'

   deepseek-harness/packages/fs/tool-str-replace-editor/src/index.ts

   Line 494 in 47f9438

   export const inject = ['tools', 'fs']

3. 工具以 sandboxMode 判断是否有沙箱，裸后端报告"无" — packages/fs/fs/src/index.ts:91-105 契约：FileSystem.sandboxMode 对裸后端返回 undefined（"does not confine at all"），仅 fs-sandbox 返回部署默认模式。于是 MutationPolicy（tool-str-replace-editor/src/index.ts:65-73）：

   this.policy = ctx.fs.sandboxMode === undefined ? undefined : ctx.get('sandboxPolicy')

   拿到裸后端时 policy = undefined → 三个写命令的 sandboxPolicy 恒为空。

4. 裸后端的写本来就无条件 — packages/fs/fs-local/src/index.ts:166-171 的 writeText 签名没有 sandboxPolicy 参数；沙箱 containment（checkedTarget）只存在于 packages/fs/fs-sandbox/src/index.ts:84-145（read-only 拒绝一切写；workspace-write 校验 containment；FS_SANDBOX_DENIED）。

   deepseek-harness/packages/fs/fs-local/src/index.ts

   Lines 166 to 171 in 47f9438

   	override async writeText(
   	target: FsTarget,
   	content: string,
   	expected?: FsWriteIntent,
   	signal?: AbortSignal,
   	): Promise<FsWriteOutcome> {

   deepseek-harness/packages/fs/fs-sandbox/src/index.ts

   Lines 73 to 148 in 47f9438

   	/**
   	* Fence the write by the per-call policy, then delegate to the inherited
   	* atomic write. See {@link checkedTarget}.
   	* @param target - the resolved target to write.
   	* @param content - the full new file content.
   	* @param expected - the write intent guarding the write; omit for unconditional.
   	* @param signal - aborts before atomic publication takes effect.
   	* @param sandboxPolicy - the per-call mode and workspace root; omit to use
   	* the deployment fallback.
   	* @returns the write outcome from the inherited backend.
   	*/
   	override async writeText(
   	target: FsTarget,
   	content: string,
   	expected?: FsWriteIntent,
   	signal?: AbortSignal,
   	sandboxPolicy?: SandboxExecutionPolicy,
   	): Promise<FsWriteOutcome> {
   	return super.writeText(await this.checkedTarget(target, sandboxPolicy), content, expected, signal)
   	}
   	/**
   	* Fence the edit by the per-call policy, then delegate to the inherited
   	* atomic edit. See {@link checkedTarget}.
   	* @param target - the resolved target to edit.
   	* @param edit - the literal search/replace request.
   	* @param expected - the version guard; omit for an unconditional edit.
   	* @param signal - aborts before atomic publication takes effect.
   	* @param sandboxPolicy - the per-call mode and workspace root; omit to use
   	* the deployment fallback.
   	* @returns the edit outcome from the inherited backend.
   	*/
   	override async editText(
   	target: FsTarget,
   	edit: FsEditRequest,
   	expected?: { version: FsVersion },
   	signal?: AbortSignal,
   	sandboxPolicy?: SandboxExecutionPolicy,
   	): Promise<FsEditOutcome> {
   	return super.editText(await this.checkedTarget(target, sandboxPolicy), edit, expected, signal)
   	}
   	/**
   	* Enforce the per-call policy against `target` and return the EXACT target the
   	* mutation must use, so the checked identity is the mutated one (no
   	* check-here-write-there TOCTOU). `read-only` denies; `workspace-write`
   	* re-canonicalizes NOW (`resolve` realpaths the deepest existing ancestor,
   	* reflecting a concurrently swapped symlink), requires containment under a
   	* writable root, and returns THAT fresh target; `danger-full-access` returns
   	* the caller's target unfenced. Throws the structured `FS_SANDBOX_DENIED` on
   	* refusal — the tool layer maps it to the model-facing `[sandbox: …]` marker
   	* and the escalation hint.
   	*/
   	private async checkedTarget(target: FsTarget, sandboxPolicy?: SandboxExecutionPolicy): Promise<FsTarget> {
   	const policy = sandboxPolicy ?? this.ctx.sandboxPolicy.resolve()
   	const { mode } = policy
   	if (mode === 'danger-full-access') return target
   	if (mode === 'read-only') {
   	throw new FsError(`cannot write "${target.displayPath}": file access denied under read-only mode`, 'FS_SANDBOX_DENIED')
   	}
   	// workspace-write: containment on the FRESH canonical path (catches a
   	// symlink ancestor swapped since the tool resolved this target), and the
   	// mutation delegates with THIS fresh target — never the stale one.
   	const fresh = await this.resolve(target.displayPath)
   	let contained = false
   	for (const root of writableRoots(policy)) {
   	if (await isPathUnder(fresh.targetKey, root)) {
   	contained = true
   	break
   	}
   	}
   	if (!contained) {
   	throw new FsError(`cannot write "${target.displayPath}": file access denied under workspace-write mode`, 'FS_SANDBOX_DENIED')
   	}
   	return fresh
   	}

从该报告可以看出，str_replace_editor 寻找 fs，发现了 fs-local 它就用了这个文件系统后端，直接绕开了宿主的文件系统沙盒。

---

另外一个我感觉不算太紧要的事情：

我去测试了一下 str_replace_editor 的写，让 AI 写入 E:\test.txt（工作区外），我发现如果在根目录创建文件夹会遇到目录创建不出来的问题，我觉得这好像是把盘符当作了目录处理来 mkdir 但是失败了：

Payload:

{
  "command": "create",
  "path": "E:\\test.txt",
  "file_text": "test"
}

Result:

Error: EPERM: operation not permitted, mkdir 'E:\'

[zoahdev]

Your root-cause chain is correct. One clarification and a patch.

Read vs write

Reading outside the workspace is by design, not a minimal-preset regression: the confining backend (fs-sandbox) also passes reads through in every mode ("Reads pass through untouched: every mode permits reading", packages/fs/fs-sandbox/src/index.ts). The genuine bug is the write path: MutationPolicy keys off ctx.fs.sandboxMode, and the bare fs-local reports undefined, so the editor sets policy = undefined and never enforces read-only (nor contains workspace-write). The shell (terminal-bash) does consume the host sandbox policy, so the editor is the one tool in minimal that silently drops the permission mode.

Patch (cherry-pick-ready against 47f943859b)

Branch: zoahdev/deepseek-harness@fix/str-replace-editor-bare-fs-policy

What it does, in packages/fs/tool-str-replace-editor/src/index.ts:

• Resolves ctx.sandboxPolicy unconditionally (it is host-plane and still visible through the isolated fs realm).
• Keeps the existing "confining fs without a policy → throw" guard.
• When the mounted fs does not confine (sandboxMode === undefined), the editor enforces the per-call policy itself before delegating to the bare backend:
  • read-only → deny all three write commands with the same FS_SANDBOX_DENIED marker the confining backend produces;
  • workspace-write → contain the target under the same writableRoots(policy) set fs-sandbox uses (workspace root + platform temp);
  • danger-full-access → unchanged.
• Confining backends keep delegating enforcement to writeText (no behavior change).

Verified locally

pnpm exec vitest run packages/fs/tool-str-replace-editor/tests/tools.spec.ts
Test Files  1 passed (1)
     Tests  16 passed (16)   # 14 existing + 2 new (read-only, workspace-write on a bare backend)
pnpm typecheck   # green

The two new tests model the minimal preset exactly: LocalFileSystem (bare) + SandboxPolicy mounted together, then assert create/str_replace/insert are denied under read-only and that workspace-write allows inside-workspace writes while denying a sibling under $HOME.

Honest scope

• This closes the file-editor policy bypass. The remaining minimal-preset issue — subprocess-local refusing win32 so the shell fails on Windows — is separate and larger (a Windows terminal/shell backend), tracked in dsh-win32 — 极简模式终于能在 Windows 上跑了（持久 Git Bash）| Real Minimal mode on Windows #1832 with sjh9714/dsh-win32 as a stopgap.
• It is a containment fence in trusted code over a model-controlled path (the same threat model fs-sandbox documents), not a kernel boundary.

如果你只想确认自己环境是否踩到这条路径，npx dsh-plugin-doctor 的 profile 检查会列出 minimal preset 实际挂载的 fs 后端；dsh-shelf 不受影响（它读 session 存档，不走这个 editor）。

[zoahdev]

中文

把这个 bug 族做成了可运行的静态审计工具：dsh-sandbox-audit。

它会读 cordis.patch.yml / agent.cordis.yml，逐工具检查「接线」与「它声称执行的策略」是否一致——正是这个帖子里 str_replace_editor 裸 fs-local 越权的通用化。对 minimal 预设它报 1 个 HIGH，对 base bundle 报 0 个 HIGH，正好把差异显式化。

• 仓库：https://github.com/zoahdev/dsh-sandbox-audit
• Show & Tell：#2196

同时覆盖 #951（搜索工具读越权）和 #149（shell 破坏性操作无门禁）。纯社区安全审计工具，非官方背书。

---

English

Generalized this bug family into a runnable static audit: dsh-sandbox-audit.

It reads cordis.patch.yml / agent.cordis.yml and checks, per tool, whether the wiring matches the policy it claims to enforce — the generic form of the bare-fs-local str_replace_editor escape in this thread. It reports 1 HIGH for the minimal preset and 0 HIGH for the base bundle, making the divergence explicit.

• Repo: https://github.com/zoahdev/dsh-sandbox-audit
• Show & Tell: #2196

It also covers #951 (search-tool read escape) and #149 (unguarded shell destructive ops). Community security audit, not an official endorsement.

[sjh9714]

I shipped the backend-layer version of this fix today, and the experience is an argument for @zoahdev's tool-layer patch rather than mine. Recording why.

What I did, and why it is the weaker layer

dsh-win32 mounts its own fs provider in the minimal realm to decode GBK and UTF-16 on read. That provider extended LocalFileSystem, so it inherited sandboxMode === undefined and reproduced this bug exactly, with a different package name on it. I published a variant that extends SandboxedFileSystem instead, which keeps the decoding and gets the fence, and wired it into the sandboxed preset.

That works. It also only helps backends whose authors know to do it.

Concretely, I ran @zoahdev's own dsh-sandbox-audit against my two presets expecting one to come back red, because one of them genuinely does not fence. Both came back 0 high. Renaming @deepseek-ai/dsh-fs-local to any other string and changing nothing else flips the verdict from HIGH to OK, because the realm's provider is matched by exact package name and anything unrecognized falls through to "inherits host sandbox". Filed as zoahdev/dsh-sandbox-audit#1.

So the bug family is not "the minimal preset mounts fs-local". It is "a mutating tool trusts whatever backend it is handed to enforce a policy the backend never promised to enforce". A fix that keys on backend identity, whether it is my subclass swap or a static audit's allowlist, is chasing names. The patch that enforces at the tool layer is the one that closes the family, and it covers third-party backends like mine without their authors doing anything.

One thing worth stating explicitly in the patch

writableRoots(policy) under workspace-write is

[policy.workspaceRoot, '/tmp', tmpdir()]

I found this the embarrassing way. I wrote a test asserting that a workspace-write session cannot write to a file outside the workspace, put the "outside" file in mkdtemp(tmpdir()), and it was permitted. The test was wrong, not the code, and the existing behavior is deliberate. But the patch inherits it, and "workspace-write" reading as "the whole system temp directory is writable" is not what most people picture from the badge name.

Not asking for a behavior change here, that is a separate argument and this thread is about the bypass. Just worth one line in the patch's docs or the mode description, because after this lands the editor will start enforcing containment and someone will file "why did it allow %TEMP%" within a week.

Scope agreement

Agreed on the split. The win32 shell gap is separate and larger. dsh-win32 stays the stopgap there, and my adoption packaging for the inspector is in #1889 if anyone wants to close that half too.

For the record on this half, if the tool-layer patch lands, my fs-confined backend becomes redundant and that is the outcome I want. Confining backends keep delegating under your patch, so it costs nothing to leave it in place during the transition.

---

中文

我今天把这个洞在后端层修了一遍，结果反而更支持 @zoahdev 的工具层补丁。原因如下。

dsh-win32 在 minimal realm 里挂自己的 fs provider 用来解码 GBK/UTF-16，它继承 LocalFileSystem，所以 sandboxMode 是 undefined，等于换了个包名把这个 bug 原样复现了一遍。我发了个改成继承 SandboxedFileSystem 的变体，解码保留，围栏拿到。

能用，但只对「作者知道要这么做」的后端有效。

更能说明问题的是，我拿 @zoahdev 自己的 dsh-sandbox-audit 去扫我那两个预设，本来预期有一个会红，结果两个都 0 high。把 @deepseek-ai/dsh-fs-local 换成任意别的字符串、其余一个字不动，HIGH 就变成 OK，因为 realm 里的 provider 是按包名精确匹配的，不认识的一律落到「继承宿主沙箱」。已提在 zoahdev/dsh-sandbox-audit#1。

所以这个 bug 族不是「minimal 挂了 fs-local」，而是「有副作用的工具把一个后端从没承诺过的策略，交给这个后端去执行」。任何按后端身份来判的修法，无论是我这种换基类还是静态审计的白名单，都是在追名字。在工具层执行的补丁才是关掉整族的那个，而且第三方后端的作者什么都不用做。

另外建议补一句文档。workspace-write 的 writableRoots 是 [workspaceRoot, '/tmp', tmpdir()]，我是写错测试才发现的。现有行为是有意的，但补丁落地之后编辑器会开始真的做包含检查，一周内一定有人来问「为什么 %TEMP% 是能写的」。