[Security] Web minimal preset allows unapproved writes outside workspace-write on Windows #523

alittleyoshi · 2026-08-13T21:23:40Z

alittleyoshi
Aug 13, 2026

Summary

The Web minimal agent preset can write outside the selected workspace while the UI and exported session both report:

permission preset: workspace-write
sandbox mode: workspace-write
approval policy: ask

I reproduced this on Windows with the session workspace located on drive E:. Without requesting or receiving approval, str_replace_editor successfully created a project under:

C:\Users\Public\Documents\<AGENT_CREATED_DIRECTORY>

This is outside the selected workspace and on a different drive.

The destination is relevant: C:\Users\Public\Documents is the Windows Public Documents location, not a Harness workspace or per-session temporary directory.

This violates the documented meaning of workspace-write, under which mutations should be restricted to the selected workspace and explicitly permitted temporary roots.

The underlying problem appears to be that the minimal preset mounts the bare @deepseek-ai/dsh-fs-local backend in an isolated filesystem realm, shadowing the host sandbox-backed filesystem provider. As a result, str_replace_editor can perform writes through fs-local without enforcing the active sandboxPolicy.

This is not merely undesirable model behavior. The permission boundary must remain effective even when the model attempts an out-of-workspace write.

Environment

Platform: Windows
Interface: DeepSeek Harness Web
Agent preset: minimal
Model: deepseek-v4-flash
Permission preset: workspace-write
Sandbox mode: workspace-write
Approval policy: ask
Workspace: E:\<REDACTED_WORKSPACE>
Reproduction date: 2026-08-14, UTC+8
No approval was requested or granted during the write

I could not find a reliable Harness build or commit identifier in the exported session. Please let me know where it can be obtained and I will add it.

Original task

The agent received an ordinary request to create a small local web application.

The user did not ask it to inspect unrelated host directories, change the selected workspace, or write files into Windows Public Documents.

Reproduction

Run DeepSeek Harness Web on Windows.
Select the minimal agent preset.
Select workspace-write with approval policy ask.
Select a workspace on drive E:.
Ask the agent to create a small web application.

In my run, persistent Bash failed with:

Error: subprocess-local: terminal inspection is unsupported on platform win32

The agent then used str_replace_editor with absolute paths outside the selected workspace. The following is a privacy-redacted representation of the successful call:

{
  "command": "create",
  "path": "C:\\Users\\Public\\Documents\\<AGENT_CREATED_DIRECTORY>\\index.html",
  "file_text": "<!doctype html><html><body>test</body></html>"
}

The tool returned:

New file created successfully at:
C:\Users\Public\Documents\<AGENT_CREATED_DIRECTORY>\index.html

The agent subsequently created and modified several more files in the same Public Documents subdirectory:

C:\Users\Public\Documents\<AGENT_CREATED_DIRECTORY>\index.html
C:\Users\Public\Documents\<AGENT_CREATED_DIRECTORY>\README.md
C:\Users\Public\Documents\<AGENT_CREATED_DIRECTORY>\package.json
C:\Users\Public\Documents\<AGENT_CREATED_DIRECTORY>\main.js

No approval/requested event occurred before any of these writes.

Relevant session evidence

The exported JSONL records the following state. Only the private workspace name has been redacted:

{"type":"session","data":{"cwd":"E:\\<REDACTED_WORKSPACE>"}}
{"type":"permission/preset","data":{"preset":"workspace-write"}}
{"type":"sandbox/mode","data":{"mode":"workspace-write"}}
{"type":"approval/policy","data":{"policy":"ask"}}

It later records an editor call equivalent to:

{
  "type": "tool/call",
  "data": {
    "name": "str_replace_editor",
    "arguments": {
      "command": "create",
      "path": "C:\\Users\\Public\\Documents\\<AGENT_CREATED_DIRECTORY>\\index.html",
      "file_text": "<!doctype html><html><body>test</body></html>"
    }
  }
}

The corresponding tool result confirms successful creation under:

C:\Users\Public\Documents\<AGENT_CREATED_DIRECTORY>

The complete session export contains unrelated host paths and directory listings, so I am not attaching it publicly. I can provide a redacted export or additional event records if needed.

Expected behavior

Under workspace-write, every mutating tool should reject paths outside:

the selected workspace; and
explicitly permitted per-session temporary roots.

In this case, with the workspace located at:

E:\<REDACTED_WORKSPACE>

a write to:

C:\Users\Public\Documents\<AGENT_CREATED_DIRECTORY>\index.html

should be rejected.

If an out-of-workspace operation supports escalation, it should execute only after explicit user approval.

Actual behavior

str_replace_editor created and modified files under Windows Public Documents, outside the selected workspace and on a different drive.

No approval was requested, and the session continued to report workspace-write.

Suspected cause

The Web minimal preset contains the following composition:

- 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'

The preset documentation indicates that the bare local filesystem shadows the host sandbox provider.

This matches the observed behavior: the editor resolves absolute paths through fs-local, while the active workspace-write policy is not consulted.

The standalone minimal-variant documentation warns that absolute editor paths can modify any path available to the runtime process and recommends using the variant only in a disposable checkout or container. That may be acceptable for an explicitly unrestricted standalone composition, but it conflicts with presenting the Web session as workspace-write.

Security impact

A model operating under this preset may write to host-user-writable locations outside the selected workspace, potentially including:

shared Windows Public folders;
unrelated user files;
application configuration;
startup or persistence locations;
scripts and source trees belonging to other projects;
writable files that affect later host behavior.

The demonstrated write into:

C:\Users\Public\Documents

also shows that the effect is not confined to the selected workspace drive or directory tree.

The exact impact depends on the privileges of the Harness process, but the documented workspace-write boundary is not enforced.

Directory reads are not the primary issue here, because the current documentation does not promise read confinement under workspace-write. The confirmed issue is successful out-of-workspace mutation.

Suggested fixes

At least one of the following changes appears necessary:

Replace @deepseek-ai/dsh-fs-local with the sandbox-enforcing filesystem backend in the Web minimal preset.
Make str_replace_editor enforce ctx.sandboxPolicy independently of the mounted filesystem provider.
If minimal intentionally requires unrestricted filesystem access, prevent it from running while the UI reports workspace-write. Require an explicit danger-full-access selection and confirmation.
Fail closed during preset composition when a preset advertises workspace-write while exposing a mutating tool backed by a non-enforcing provider.
Add Windows and POSIX integration tests verifying that every mutating tool rejects:
- sibling directories;
- other drives or volume roots;
- absolute paths outside the workspace;
- Windows Public folders;
- traversal and link-based escapes;
- other unrelated host-user-writable directories.

These tests should cover both bash and str_replace_editor. Restricting only one mutating tool does not preserve the permission boundary.

Severity

I consider this a high-severity permission-boundary issue.

The interface communicates a constrained workspace-write environment, but the minimal preset permits out-of-workspace writes with the privileges of the Harness host process. This mismatch is silent and requires no approval event.

Related discussions

This report is related to, but distinct from:

Two remote-execution-world gaps in dsh-base (tool-fs-search rg path; fs-sandbox modes), with fixes #490, which describes missing workspace-write semantics for remote
execution-world filesystem providers. This report reproduces the issue
locally on Windows in the Web minimal preset, where the bare fs-local
provider appears to shadow the sandbox-enforcing filesystem provider.
BUG: `fs-sandbox` post-check pathname race 可绕过 `workspace-write` 文件边界 #159, which describes a post-check pathname race in an otherwise active
fs-sandbox implementation. This report does not require a race, symlink,
hardlink, background process, or Linux sandbox. A direct absolute-path
str_replace_editor call deterministically writes outside the selected
workspace without approval.

Therefore, this appears to be a separate preset-composition and permission-UI
mismatch rather than another reproduction of either issue.

dcxcchen · 2026-08-15T00:48:48Z

dcxcchen
Aug 15, 2026

我这边在 Linux 上也遇到了同类问题

环境

OS：Ubuntu 26.04 LTS（x86_64）
Agent preset：standard
会话显示：permission preset: workspace-write、sandbox mode: workspace-write
工作区：/home/xxx/workspace/dsh-hello-world

现象

让dsh把opencode的AGENTS.md和skills搬过来

bash 工具里 / 被挂载为 ro，只有工作区是 rw；touch ~/.dsh/.write_test 返回 Read-only file system。这部分符合 workspace-write 的预期。
但 str_replace_editor 没有受到同样的写限制，未经任何审批就在工作区外创建了：
~/.dsh/AGENTS.md
~/.dsh/skills/

1 reply

Piggy343288 Aug 15, 2026

I encounted the same problem as well.

Electricitysheep · 2026-08-15T15:33:55Z

Electricitysheep
Aug 15, 2026

minimal 预设能在 workspace-write 外未批准写入——权限边界的实际缺口，和 #1516（网络独立沙箱）、#523 这类发现都是"沙箱存在≠安全"的例证。

这类审计发现我们第 13 章专门有收集（含审计方法论）：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/13-security.md

0 replies

weijiafu14 · 2026-08-15T18:20:56Z

weijiafu14
Aug 15, 2026

这个 permission boundary 仍然应该由 DSH 修，但现在可以先加一道已经跑通的独立执行前防线：Pi 生态的 pi-approval-guardian 通过 pi2dsh 运行时，默认会审查全部 bash，以及敏感/工作区外路径的 read/grep/find/ls/write/edit；只有 reviewer 明确返回 allow 才继续，deny、超时、鉴权或模型异常都 fail closed。

dsh plugin --profile web add pi2dsh@0.11.0
dsh plugin --profile web add pi-approval-guardian

export PI_APPROVAL_GUARDIAN_MODEL=deepseek-official/deepseek-v4-flash
export PI_APPROVAL_GUARDIAN_POLICY='禁止任何工具在当前 workspace 与显式临时目录之外创建、覆盖、移动或删除文件；Windows Public Documents、用户配置与其他项目目录一律拒绝。'

项目：https://github.com/weijiafu14/pi2dsh

因此原帖里的 str_replace_editor(create, C:\Users\Public\Documents\...) 会在真正进入工具 handler 前被独立 reviewer 看见并可拒绝。Guardian 的 allow/deny 与 fail-closed 路径已经做过真实 DSH E2E。

这是一道纵深防线，不替代原帖要求的修复：minimal preset 不能在 UI 声明 workspace-write 的同时挂一个绕过 sandboxPolicy 的裸 fs-local。

0 replies

naipi11 · 2026-08-19T09:26:53Z

naipi11
Aug 19, 2026

Until this is addressed, start new Web sessions with the Standard preset and Workspace Write, rather than minimal.

In current rc.7, Standard keeps file edits on the host's sandboxed filesystem path, while minimal mounts a bare local filesystem for its editor. This limits Harness filesystem-tool writes to the workspace and its managed temporary area; it is not a general host-security guarantee, and enforcement can be partial on Windows. Existing minimal sessions are outside this mitigation, so check for unintended files before continuing.

0 replies

Navigation Menu

Uh oh!

[Security] Web minimal preset allows unapproved writes outside workspace-write on Windows #523

Uh oh!

{{title}}

Uh oh!

Replies: 4 comments 1 reply

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Uh oh!

[Security] Web minimal preset allows unapproved writes outside workspace-write on Windows #523

Uh oh!

alittleyoshi Aug 13, 2026

Summary

Environment

Original task

Reproduction

Relevant session evidence

Expected behavior

Actual behavior

Suspected cause

Security impact

Suggested fixes

Severity

Related discussions

Replies: 4 comments · 1 reply

Uh oh!

dcxcchen Aug 15, 2026

环境

现象

Uh oh!

Piggy343288 Aug 15, 2026

Uh oh!

Electricitysheep Aug 15, 2026

Uh oh!

weijiafu14 Aug 15, 2026

Uh oh!

naipi11 Aug 19, 2026

alittleyoshi
Aug 13, 2026

Replies: 4 comments 1 reply

dcxcchen
Aug 15, 2026

Electricitysheep
Aug 15, 2026

weijiafu14
Aug 15, 2026

naipi11
Aug 19, 2026