一名开发者在Windows 11 22H2系统上使用DeepSeek Harness（版本0.2.1-rc.2）时遇到权限异常问题。因C盘空间不足，该用户将AppData文件夹设为DSH工作区，用于分析哪些文件可以删除。分析完成后，Codex无法正常写入项目文件，桌面图标也丢失显示变为白色。经排查，问题根源在DSH的Windows沙箱授权机制：在默认权限（工作区内修改）下执行shell命令后，沙箱会在工作区目录及所有子目录添加Low Mandatory Label（低强制完整性标签）。受影响的程序运行时继承该标签，以Low完整性级别运行；当它们向其他项目的Medium完整性目录写入文件时，会被Windows强制完整性控制机制拒绝，报Access denied错误。该问题并非孤例，GitHub上deepseek-ai/deepseek-harness仓库的Discussion #7846也报告了类似情况：Windows ACL沙箱的常驻低完整性标签导致工作区内其他工具无法写入，Electron构建静默退出。作者最终借助GPT分析受影响目录，将完整性级别恢复为Medium后问题解决。整个排查耗费大量时间，作者发布这篇复盘，希望帮助遇到同样问题的开发者少走弯路。
事件分析
该事件暴露了AI编程工具沙箱设计中安全与兼容性的平衡难题。Windows强制完整性控制机制自Vista时代便已存在，但普通开发者很少直接接触低完整性标签的副作用。DSH采用ACL配合完整性标签实现权限隔离，思路符合最小权限原则，却低估了对工作区内其他工具链的连锁影响，且缺乏清晰的诊断提示，导致排查成本高昂。值得注意的是，作者最终使用GPT来分析并修复DSH造成的问题，AI工具之间互相救场的场景颇具代表性。随着AI Agent被授予越来越大的文件系统操作权限，沙箱机制的粒度、可观测性与退出通道将成为工具竞争力的关键指标。DeepSeek官方能否在后续版本提供标签自动清理或白名单机制，值得持续关注。
核心观点：AI Agent的沙箱安全机制若缺乏透明性与恢复通道，防护本身就会成为新的故障源。
原文链接：Linux.do
