[Security][Windows sandbox] workspace-write modified files outside the authorized workspace / workspace-write 未提权却越界修改文件

[hecoococ]

This bilingual report describes a real destructive incident. Commands shown below are evidence only and must not be executed.

本双语报告记录了一起真实的破坏性事故。下文命令仅作为证据，严禁执行。

English

We maintain the community distribution Open DeepSeek Harness Desktop. A Windows user experienced destructive filesystem changes both inside and outside the selected workspace while the session was set to workspace-write.

This is a high-impact report based on a real incident. The exact recorded command is included below for technical review. It is destructive incident evidence and must not be executed. We can provide the remaining sanitized technical appendix through a private channel.

Confirmed session evidence

• The session cwd was a directory on the D: volume.
• The durable permission events recorded permission/preset = workspace-write, sandbox/mode = workspace-write, and approval/policy = ask.
• We found no later sandbox-mode change, approval event, or tool call containing a sandbox_permissions override.
• Immediately before the destructive call, the workspace listing still contained the user's original documents.
• The agent then called the pwsh tool with a malformed nested cmd /c command intended to recursively remove one pip temporary directory inside the workspace.
• The call ran for approximately 60.9 seconds. Its captured stderr contained access-denied paths associated with directories outside the workspace.
• Within seconds, a workspace inventory contained only the pip temporary directory.
• Later inspection found that directories outside the workspace had modification timestamps within the destructive call's time window and had unexpectedly sparse contents.

The user's estimated loss is approximately 200 GB. The session has no reliable pre-incident volume measurement, so we cannot independently verify the exact byte count.

Sanitized key excerpts from the session

The original is a 5,434-record JSONL file. Sequence numbers and UTC timestamps below are preserved; private names, unrelated paths, session IDs, and call IDs are redacted. The exact incident command and its intended workspace path are retained because quoting and path parsing are central to the report.

seq 0  2026-09-06T05:40:40.755Z
permission/preset  { "preset": "workspace-write" }

seq 1  2026-09-06T05:40:40.757Z
sandbox/mode       { "mode": "workspace-write" }

seq 2  2026-09-06T05:40:40.757Z
approval/policy    { "policy": "ask" }

Immediately before the incident, the cleanup result still listed the user's original files:

seq 60918  2026-09-07T05:49:06.488Z  tool/result
.dsh
.piptmp
tools
<original PDF>
<original Markdown files>
<original document files>

The failed cleanup was followed by an inspection that proved .piptmp still contained ten pip subdirectories:

seq 61051  2026-09-07T05:49:08.984Z  tool/result
still exists

seq 61118  2026-09-07T05:49:10.905Z  tool/result
D:\<workspace>\.piptmp\pip-build-tracker-<id>
D:\<workspace>\.piptmp\pip-install-<id>
D:\<workspace>\.piptmp\pip-target-<id>
D:\<workspace>\.piptmp\pip-unpack-<id>
... 10 directories total

The exact commands immediately preceding the incident were the following. They are included to show the escalation from native PowerShell cleanup to the later cmd.exe fallback.

CAUTION — RECORDED DELETE COMMANDS — DO NOT RUN. The first two commands delete files or directories. These are evidence excerpts, not remediation instructions.

seq 60917  2026-09-07T05:49:06.077Z
description: "Clean up temporary extraction files"

Remove-Item "D:\学习+工作\_pdf_extract.py","D:\学习+工作\_pdf_extract2.py","D:\学习+工作\_pdf_extract3.py","D:\学习+工作\_pdf_extract4.py","D:\学习+工作\_pdf_inspect.py","D:\学习+工作\_pdf_frag.py","D:\学习+工作\_pdf_chars.py","D:\学习+工作\_pdf_row.py","D:\学习+工作\_pdf_text_out.txt","D:\学习+工作\_pdf_inspect.txt","D:\学习+工作\_pdf_frag.txt","D:\学习+工作\_pdf_chars.txt","D:\学习+工作\_pdf_row.txt","D:\学习+工作\.piplog.txt" -Force -ErrorAction SilentlyContinue; Remove-Item "D:\学习+工作\.piptmp","D:\学习+工作\.pylibs" -Recurse -Force -ErrorAction SilentlyContinue; Get-ChildItem "D:\学习+工作" | Select-Object -First 20 Name

seq 61050  2026-09-07T05:49:08.606Z
description: "Remove leftover pip temp directory"

Remove-Item "D:\学习+工作\.piptmp" -Recurse -Force -ErrorAction SilentlyContinue; if (Test-Path "D:\学习+工作\.piptmp") { Write-Output "still exists" } else { Write-Output "removed" }

seq 61117  2026-09-07T05:49:10.524Z
description: "Inspect leftover pip temp contents"

Get-ChildItem "D:\学习+工作\.piptmp" -Force -Recurse -ErrorAction SilentlyContinue | Select-Object -First 10 FullName

The destructive call and result were:

DANGER — INCIDENT COMMAND — DO NOT RUN. The following line is quoted verbatim from the Session evidence. It invokes recursive, quiet deletion. It is included only so maintainers can analyze the nested PowerShell/cmd.exe quoting failure. Do not paste it into a shell and do not test it on a real filesystem.

cmd /c "rd /s /q \"D:\学习+工作\.piptmp\"" 2>&1; if (Test-Path "D:\学习+工作\.piptmp") { Write-Output "still exists"; (Get-ChildItem "D:\学习+工作\.piptmp" -Recurse -Force | Measure-Object).Count } else { Write-Output "removed" }

seq 61295  2026-09-07T05:49:13.134Z  tool/call
tool: pwsh
description: "Force remove pip temp directory via cmd"
command structure: pwsh -> cmd.exe /c -> rd /s /q -> D:\<workspace>\.piptmp
sandbox_permissions: absent

seq 61296  2026-09-07T05:50:14.017Z  tool/result
still exists
10
[stderr]
<file> - Access is denied.
\<drive-root-sibling>\<application tree>\<file> - Access is denied.
... many paths outside D:\<workspace> ...
[output truncated; full output was stored in subprocess spill files]
wrapper field: isError=false

The call lasted 60.883 seconds. Shortly afterwards, only the temporary directory remained:

seq 62399  2026-09-07T05:50:28.313Z  tool/result
.piptmp

seq 62590  2026-09-07T05:50:31.267Z  tool/result
1
.piptmp

Later inspection of a sibling directory outside the workspace showed modification times inside the destructive-call window and very small remaining file counts:

directory modification times: 2026-09-07T05:49:47Z through 05:50:01Z
remaining file counts in two application directories: 70 and 6

A scan of every actual tool/call record found zero calls containing sandbox_permissions. No permission or approval event widened the session after seq 2.

Expected behavior

Under workspace-write, a quoting or path-parsing error inside a child process must not allow filesystem modifications outside the authorized workspace. A malformed destructive command should be confined by the process sandbox even when it is launched as pwsh -> cmd.exe -> rd.

Actual behavior

The selected workspace was almost completely deleted, and the evidence supports contemporaneous destructive changes to sibling directories on the same volume. The session contains no evidence that the user granted full-volume access or approved an escalation.

Current assessment

The malformed native-command quoting is a likely trigger, but we have not reproduced the exact argv received by cmd.exe. Earlier pip output displayed mojibake for the same non-ASCII path; that observation does not prove that encoding expanded the deletion target.

The official dsh-v0.1.2-rc.1 sandbox documentation describes Windows ACL enforcement as partial. We do not yet know whether that documented limitation, the incident machine's ACLs, a runner startup/integration failure, or another defect caused the out-of-workspace writes.

The Harness core baseline in our community desktop distribution was synchronized with the official dsh-v0.1.2-rc.1 tag. The distribution also contains downstream desktop changes. The incident has not yet been reproduced in an unmodified official distribution, so we want to distinguish an upstream Windows sandbox boundary issue from downstream desktop integration before assigning root cause.

Requested maintainer guidance

1. Is there a private contact channel for the sanitized command, event excerpt, and affected-path evidence?
2. Which Windows sandbox runner/version and diagnostic markers should we collect to prove that confinement was active for this call?
3. Are there known NTFS ACL layouts under which workspace-write can modify sibling directories because enforcement is reported as partial?
4. Would maintainers prefer an inert argument-recorder reproduction first, followed by a disposable-volume boundary test?

Safe reproduction status

We have not rerun the destructive command. Any reproduction will use an isolated Windows VM, synthetic files, an inert argv recorder, and a disposable volume. We will not publish or execute the original command against a real filesystem.

Relevant upstream references

• Official dsh-v0.1.2-rc.1 Windows sandbox implementation: https://github.com/deepseek-ai/deepseek-harness/blob/dsh-v0.1.2-rc.1/packages/sandbox/sandbox-local/src/index.ts
• Official sandbox subsystem documentation: https://github.com/deepseek-ai/deepseek-harness/blob/dsh-v0.1.2-rc.1/docs/subsystems/sandbox.md
• Sanitized event attachment: sanitized-evidence-extract-en.md (available on request or as a separate attachment)

---

中文

我们维护社区发行版 Open DeepSeek Harness Desktop。一名 Windows 用户在会话设置为 workspace-write 时，遭遇了工作区内外的破坏性文件修改。

这是一起已有真实数据损失的高影响问题。下文保留 Session 中记录的原始命令，供技术核查。它是具有破坏性的事故证据，严禁执行。 如官方提供私密渠道，我们还可以提交其余脱敏技术附件。

已确认的会话证据

• 会话工作目录位于 D: 卷中的一个目录。
• 持久权限事件记录为 permission/preset = workspace-write、sandbox/mode = workspace-write、approval/policy = ask。
• 没有发现后续沙箱模式切换、审批事件，或包含 sandbox_permissions 提权参数的工具调用。
• 在事故调用前，工作区列表仍包含用户原始文档。
• 随后 Agent 通过 pwsh 工具执行了一条错误嵌套的 cmd /c 命令，原意只递归删除工作区内一个 pip 临时目录。
• 该调用运行约 60.9 秒；捕获的 stderr 出现了与工作区外目录相关的拒绝访问路径。
• 数秒后的工作区清单只剩 pip 临时目录。
• 后续检查发现，工作区外目录的修改时间落在该调用执行窗口内，且其中内容异常稀少。

用户估计损失约 200 GB。会话没有可靠的事故前磁盘容量记录，因此我们无法独立确认准确字节数。

Session 关键段落脱敏摘录

原文件包含 5,434 条 JSONL 记录。下面保留原始事件序号与 UTC 时间，隐去私人名称、无关路径、Session ID 和 Call ID。由于引号与路径解析正是本次事故的核查重点，原始事故命令及其目标工作区路径予以保留。

seq 0  2026-09-06T05:40:40.755Z
permission/preset  { "preset": "workspace-write" }

seq 1  2026-09-06T05:40:40.757Z
sandbox/mode       { "mode": "workspace-write" }

seq 2  2026-09-06T05:40:40.757Z
approval/policy    { "policy": "ask" }

事故前的清理结果仍然列出了用户原始文件：

seq 60918  2026-09-07T05:49:06.488Z  tool/result
.dsh
.piptmp
tools
<原始 PDF>
<原始 Markdown 文件>
<原始文档文件>

随后清理失败，检查证明 .piptmp 中仍有 10 个 pip 子目录：

seq 61051  2026-09-07T05:49:08.984Z  tool/result
still exists

seq 61118  2026-09-07T05:49:10.905Z  tool/result
D:\<workspace>\.piptmp\pip-build-tracker-<id>
D:\<workspace>\.piptmp\pip-install-<id>
D:\<workspace>\.piptmp\pip-target-<id>
D:\<workspace>\.piptmp\pip-unpack-<id>
……共 10 个目录

事故前紧邻的三个原始命令如下。保留它们是为了展示 AI 如何从 PowerShell 原生清理逐步转向后来出事的 cmd.exe 兜底。

注意：以下为包含删除操作的原始记录，严禁运行。 前两个命令会删除文件或目录；它们是事故证据，不是修复建议。

seq 60917  2026-09-07T05:49:06.077Z
description: "Clean up temporary extraction files"

Remove-Item "D:\学习+工作\_pdf_extract.py","D:\学习+工作\_pdf_extract2.py","D:\学习+工作\_pdf_extract3.py","D:\学习+工作\_pdf_extract4.py","D:\学习+工作\_pdf_inspect.py","D:\学习+工作\_pdf_frag.py","D:\学习+工作\_pdf_chars.py","D:\学习+工作\_pdf_row.py","D:\学习+工作\_pdf_text_out.txt","D:\学习+工作\_pdf_inspect.txt","D:\学习+工作\_pdf_frag.txt","D:\学习+工作\_pdf_chars.txt","D:\学习+工作\_pdf_row.txt","D:\学习+工作\.piplog.txt" -Force -ErrorAction SilentlyContinue; Remove-Item "D:\学习+工作\.piptmp","D:\学习+工作\.pylibs" -Recurse -Force -ErrorAction SilentlyContinue; Get-ChildItem "D:\学习+工作" | Select-Object -First 20 Name

seq 61050  2026-09-07T05:49:08.606Z
description: "Remove leftover pip temp directory"

Remove-Item "D:\学习+工作\.piptmp" -Recurse -Force -ErrorAction SilentlyContinue; if (Test-Path "D:\学习+工作\.piptmp") { Write-Output "still exists" } else { Write-Output "removed" }

seq 61117  2026-09-07T05:49:10.524Z
description: "Inspect leftover pip temp contents"

Get-ChildItem "D:\学习+工作\.piptmp" -Force -Recurse -ErrorAction SilentlyContinue | Select-Object -First 10 FullName

事故调用及其结果：

危险：事故原始命令，严禁运行。 下列内容逐字摘自 Session 证据，其中包含静默递归删除。这里只用于让维护者分析 PowerShell 与 cmd.exe 的嵌套引号问题。请勿复制到终端，也不要在真实文件系统中测试。

cmd /c "rd /s /q \"D:\学习+工作\.piptmp\"" 2>&1; if (Test-Path "D:\学习+工作\.piptmp") { Write-Output "still exists"; (Get-ChildItem "D:\学习+工作\.piptmp" -Recurse -Force | Measure-Object).Count } else { Write-Output "removed" }

seq 61295  2026-09-07T05:49:13.134Z  tool/call
tool: pwsh
description: "Force remove pip temp directory via cmd"
command structure: pwsh -> cmd.exe /c -> rd /s /q -> D:\<workspace>\.piptmp
sandbox_permissions: absent

seq 61296  2026-09-07T05:50:14.017Z  tool/result
still exists
10
[stderr]
<file> - Access is denied.
\<盘根兄弟目录>\<应用目录树>\<file> - Access is denied.
……出现大量 D:\<workspace> 以外的路径……
[输出被截断；完整内容当时写入 subprocess spill 文件]
wrapper field: isError=false

该调用持续 60.883 秒。紧接着，工作区只剩临时目录：

seq 62399  2026-09-07T05:50:28.313Z  tool/result
.piptmp

seq 62590  2026-09-07T05:50:31.267Z  tool/result
1
.piptmp

后续检查发现，工作区外某兄弟目录的修改时间落在事故调用窗口内，剩余文件数量异常少：

目录修改时间：2026-09-07T05:49:47Z 至 05:50:01Z
两个应用目录的剩余文件数：70 和 6

对所有实际 tool/call 记录的扫描结果为：包含 sandbox_permissions 的调用数量为 0；seq 2 之后也没有扩大权限的事件。

预期行为

在 workspace-write 下，即使子进程发生引号或路径解析错误，也不应获得授权工作区外的文件修改能力。即使命令链为 pwsh -> cmd.exe -> rd，进程沙箱也应限制其作用范围。

实际行为

选定工作区几乎被清空，现有证据也支持同一时间窗口内同卷其他目录遭到破坏性修改。会话没有用户授予整盘权限或批准提权的证据。

当前判断

错误的原生命令引号很可能是触发条件，但我们尚未复现 cmd.exe 最终收到的 argv。同一路径此前在 pip 输出中出现乱码，但这不能证明编码问题扩大了删除目标。

官方 dsh-v0.1.2-rc.1 沙箱文档将 Windows ACL 执行强度标记为 partial。现阶段还无法判断原因是这一已知边界、事故机器的 ACL、沙箱 runner 启动或接入失败，还是其他缺陷。

事故发生时，我们社区桌面发行版的 Harness 核心上游已经同步至官方 dsh-v0.1.2-rc.1 标签；发行版同时包含桌面端下游改动。该问题尚未在未经修改的官方发行版复现，因此我们希望先区分上游 Windows 沙箱边界问题与下游桌面接入问题，再确定根因归属。

希望官方协助确认

1. 是否有私密渠道接收脱敏命令、事件摘录及受影响路径证据？
2. 应收集哪些 Windows 沙箱 runner 版本和诊断标记，才能证明事故调用确实处于沙箱中？
3. 是否存在已知 NTFS ACL 布局，会让标记为 partial 的 workspace-write 修改同卷兄弟目录？
4. 官方是否建议先用无害 argv 记录程序复现参数解析，再使用一次性虚拟磁盘验证边界？

安全复现状态

我们没有重新执行危险命令。后续复现只会在隔离 Windows 虚拟机、合成文件、无害 argv 记录程序和一次性虚拟磁盘中进行。

相关上游资料

• 官方 dsh-v0.1.2-rc.1 Windows 沙箱实现：https://github.com/deepseek-ai/deepseek-harness/blob/dsh-v0.1.2-rc.1/packages/sandbox/sandbox-local/src/index.ts
• 官方沙箱子系统文档：https://github.com/deepseek-ai/deepseek-harness/blob/dsh-v0.1.2-rc.1/docs/subsystems/sandbox.md
• 脱敏事件附件：sanitized-evidence-extract-en.md（可在官方请求后单独提供）

[hecoococ]

用户的权限选择也是非常克制的，只是工作区内允许写入和读取，但是命令越过了沙箱，删除了几乎整个d盘。

[hecoococ]

而且，dsh并没有给出警告：权限不足的弹窗，用户并没有点击“确认”的时机。原因可能为powershell和cmd命令互相杂糅，加上中文路径导致的。

[argszero]

This deserves a serious, source-grounded triage. I read the current Windows sandbox implementation (master d347e70390) to establish what should have confined that call — because the answer determines where to look.

The design contract (what should have happened)

workspace-write on Windows routes pwsh through @deepseek-ai/dsh-pwsh-sandbox → the windows-acl runner (packages/sandbox/sandbox-windows-acl/), which is in the base bundle by default. Its contract is explicit:

• The confined child is NEVER spawned unrestricted (runner.ts: any runner-side failure prints a RunnerFailure signature line; there is no unrestricted fallback).
• workspace-write = restricted token + capability-SID write grant on exactly two scopes: the workspace tree and the private temp tree (runner.ts requires --write-sid + --temp-write-sid together; read-only rejects both).
• Writes anywhere else are denied by the restricted token (the process no longer holds writable user SIDs), surfacing as per-path access-denied.
• No prompt is expected in either of the two outcomes that matter here: a denial under the sandbox returns a structured [sandbox: …] error (a policy denial, never an approval prompt — prompts only exist for explicit sandbox_permissions escalation requests), and an operation inside the write grant runs without any prompt because it is already authorized. So "the user never got a click-to-confirm" is consistent with both "denied" and "within-grant" — it is not itself evidence of an escape.
• One design fact to keep in mind for the audit: workspace grants are standing ACEs and deliberately never revoked (sandbox-windows-acl/src/index.ts:31-35 — they are the cross-session reuse cache; only temp grants are revocable). ACEs are keyed to per-session SIDs, so stale grants only matter if a SID/path is reused, but any future "grant cache returns a stale/private path" bug in this family has destructive potential (there is precedent: the sandbox-local grant cache returned without a liveness check — windows-acl 沙箱临时目录被外部清理后不会自动重建，沙箱命令持续报错 #3203/Bug:Windows ACL 沙箱在其缓存的私有临时目录被回收后永久失效 #5477).

The candidate failure classes, in order of likelihood

1. Workspace boundary broader than the user believed. The session cwd becomes the workspace root; the write SID is granted on that resolved tree. If the cwd/中文 path resolved to a broad ancestor (path normalization: 8.3 short names, UNC, NFC/NFD — the repo has a whole family of Windows path-resolution bugs: [Bug Report]：Windows 上 dsh plugin 的含空格路径参数会被拆断 #1420, install-lefthook postinstall fails on macOS when the repo path contains non-ASCII characters (NFC/NFD mismatch) #4272, Bug: dsh 在 wsl2 环境下无法唤起 windows 程序 #5850), the grant itself covered far more than the intended folder. Deletions inside that grant are silent and authorized — no prompt, no denial. A malformed nested cmd /c whose quoting made del /s resolve one level up (or to the drive) would then sweep the granted scope without any sandbox error. The access-denied lines in stderr would be exactly the paths outside the (mis-bounded) grant that survived.
2. The del target resolved broader than the pip dir (cmd /c quoting + 中文 path mangling, independent of the sandbox). This turns a scoped cleanup into a broad sweep; the sandbox then only limits it to the grant scope.
3. Temp-grant overlap. pip temp directories commonly live under the granted temp root. If the sweep reached the granted temp tree, those deletions are also authorized-silent. (Limited volume, but part of the picture.)
4. Junction/symlink traversal. If the workspace (or the pip dir) contained a link to a directory outside, del /s follows it; whether the target is writable depends on the target's ACEs for the capability SID. The repo has a known symlink/junction-crossing family (用repo管理的仓库，查git相关内容时会反复申请权限，不友好 #5384/@ 文件补全无法识别 Windows 目录软连接（junction / 指向目录的符号链接） #5412).
5. Stale standing grants from prior sessions on the same volume (never revoked by design) — only exploitable if SID reuse applies.

The discriminating evidence to pull

The session JSONL can separate these cleanly:

1. The tool result's sandbox metadata for the ~60.9s call — the pwsh tool stamps sandbox: { mode, denied, enforcement?, runnerFailed? } on the result. mode: workspace-write + denied: false + runnerFailed absent ⇒ the process WAS confined and the deletions happened inside the granted scope → the bug is boundary/grant resolution (class 1/3), not containment. runnerFailed: true or absent enforcement ⇒ confinement wasn't applied (would contradict the runner contract — needs the appendix).
2. The exact workspace path, the exact pip-temp path, and the resolved delete target (redaction is fine — drive + depth + names suffice): was the workspace itself a large tree (e.g., the documents directory), and could the grant have covered what was lost?
3. Denial lines: did the 60.9s stderr contain the structured [sandbox: …] marker or raw Windows access-denied text? Structured ⇒ the sandbox was actively denying (containment on); raw-only ⇒ more consistent with an unrestricted/partially-granted scope.

Reproduce-on-VM protocol

On a Windows VM with a sacrificial tree: (a) benign Remove-Item of a file inside the workspace → expect success, no prompt; (b) benign Remove-Item of a file outside the workspace → expect a [sandbox: …] denial; (c) the exact malformed nested cmd /c shape with a 中文 path → check whether the resolved target stays inside the workspace and whether outside files survive. (a)+(b) passing and (c) destroying outside files isolates a quoting/path bug; (b) failing isolates systemic containment breakage.

Routing

The repo has no SECURITY.md and GitHub Issues/PRs are disabled, so there is no in-repo private channel I can point you to from here — the sanitized-appendix offer is valuable; please get it to the maintainers through whatever contact the Open DeepSeek Harness Desktop project has (the appendix contains the exact command + full paths, which is what makes classes 1/2 decidable). I'll keep analysis in this public thread to the sanitized evidence.

中文摘要：按当前源码，Windows workspace-write 的 pwsh 走 windows-acl runner——受限 token + 仅对 workspace 和 temp 两个目录树授予写 SID，子进程绝不无限制启动；"没有确认弹窗"符合"权限内静默执行"和"沙箱拒绝（结构化错误，非弹窗）"两种正常结局，本身不是逃逸证据。最可能的失效类是 workspace 边界解析过宽（中文路径/8.3/UNC，仓库有整族路径解析 bug）+ 嵌套 cmd /c 引号破坏使 del 目标上移，两者叠加即"授权范围内静默全删"。判别关键 = 那次调用的 tool result 里 sandbox: {mode, denied, enforcement, runnerFailed} 元数据 + workspace/pip-temp/del 目标的真实路径形状；VM 上用良性等价命令（workspace 内/外删除各一）即可分离"引号/路径 bug"与"系统性逃逸"。请把完整附录走私有通道给维护者——精确命令 + 路径是定类的钥匙。

[hecoococ]

好的，私有通道具体怎么提供？会话的session.jsonl已经导出