[Bug] Agent edit files out of Workspace, while WorkSpace Write mode enabled.

[Piggy343288]

As the image has shown, the Agent created file at C:/tmp, however, my workspace is D:/code. I may show the exact reason if I find it afterwards.

[zoahdev]

This is almost certainly the shell-capability gap, not a workspace-write enforcement bug - worth distinguishing because the fix is different.

In the current model, workspace-write permission gates the agent's file-system tools (fs writes/renames), but a shell tool (bash/pwsh) with no sandbox is a separate capability: a command like echo x > C:\tmp\f writes wherever the shell's OS user can write, and no permission system can stop that from inside the harness. The same mechanism is what our #1923 analysis called the "zero-approval silent escape" family: the shell is the escape hatch.

To triage on your machine:

1. Check which tool actually wrote the file - if the trajectory shows bash/pwsh (or any exec tool) with a redirect, that's the shell path. If it was an fs-write tool (workspace.write etc.), that IS an enforcement bug and worth a patch.
2. If it's the shell path, the fix is execution sandboxing: configure a sandbox (or restrict the shell tool), not more workspace-write checks. dsh-plugin-doctor's shell-launcher check (discussions 同类问题已有讨论，此贴关闭 #1923/[插件安全边界] tools/pre-execute 在 ask 审批前已执行，可先完成独立 Node.js 子进程 #1863) can flag shell surfaces that bypass approval, and the sandbox-local containment tests cover the write-outside-workspace class.
3. If you have the exact tool name + trajectory excerpt, paste it and we can confirm which path you're on.

Short version: workspace-write mode is a filesystem-tool contract; it has never been (and should not be) a claim that a sandbox-less shell can't write outside the workspace.

[Piggy343288]

According to my understanding, it IS an fs-write tool. The image shows it uses str_replace_editor to create a file, while this skill uses fs/write-intent to operate.

[weijiafu14]

@zoahdev 的分诊是对的，而且那两条自查（看轨迹里到底是哪个工具写的）就是下一步该做的事。我只补一条平台相关的提醒，因为从你的截图看你在 Windows，而"配个沙箱就行"这句话在 Windows 上有已知的窟窿。

如果确认是 shell 那条路，Windows 上的沙箱有两个已记录的缺口

If it's the shell path, the fix is execution sandboxing: configure a sandbox (or restrict the shell tool)

方向没错，但在 Windows 上你得知道自己买到的是什么：

1. windows-acl 档本身就标着 enforcement: 'partial'。
#1331 把它的结构性边界列了出来（WRITE_RESTRICTED 必须保留 Everyone；NTFS 硬链接可以跨路径别名），而且指出了更麻烦的一点：这些边界对模型和运维都不可见——受限运行看起来和完全受限一模一样。也就是说，配上之后你可能还是会看到工作区外的写入，而界面上没有任何东西提示你"这次约束是部分的"。

2. 如果你在 WSL2 里跑，沙箱可能被完全绕过。
#3045 有一份已复现的报告：WSL 的 interop 机制会把 powershell.exe / cmd.exe 交给 Windows 原生进程执行，不经过 bwrap 的挂载命名空间，以当前 Windows 账户身份跑，对所有盘符有完整读写权限。那份报告里实测删掉了 D 盘 26.8GB，零审批。

（你的截图是 C:/tmp 和 D:/code，跨盘符——如果你是在 WSL2 下跑 dsh，这条就直接适用。当下的缓解在 WSL 那侧：/etc/wsl.conf 里 [interop] enabled=false，然后 wsl --shutdown。）

一个补充的分诊线索

@zoahdev 让你看轨迹里是哪个工具。如果轨迹不好读，还有个更粗但很快的判据：看那个文件是怎么被创建的。

• 如果内容是通过重定向、New-Item、Set-Content、echo > 之类产生的 → shell 路径；
• 如果是结构化的整文件写入（工具卡上能看到完整 content 参数）→ fs 工具路径，那才是 @zoahdev 说的"这就是 enforcement bug，值得打补丁"。

这个区分值得你花点力气确认，因为两条路的结论完全相反：一条是"配置问题，去开沙箱"，另一条是"权限系统没兜住，是真 bug"。你原帖说"如果之后找到确切原因会补上来"——补上来的时候，把这一条写清楚比其它任何细节都有价值。

边界与利益相关

我们不修 DSH 自家组件——workspace-write 的强制、shell 工具、沙箱都在 DSH 里。上面全是别人报告的归类和分诊建议；我没有 Windows 环境，上述两个缺口都不是我复现的，我只是把它们和你这条串起来。

利益相关：我维护 pi2dsh（Pi 生态兼容层）。这条不推销——你这是 DSH 的权限/沙箱边界问题，多装一个插件只会多一个能调 shell 的东西。