DSH 权限与沙箱指南：workspace-write、审批与安全边界

先看结论

DSH 的“权限”不是单个开关，而是沙箱模式与审批策略的组合。0.1.1-rc.2 新会话默认使用 workspace-write 预设，即文件写入被限制在会话工作区和平台临时目录，遇到需要批准的操作时采用 ask；这不等于完全离线，也不保证所有平台拥有相同的进程隔离效果。

日常代码任务优先使用 workspace-write。只有在你理解命令、目录、凭据和外部副作用后，才考虑 danger-full-access。本文依据官方 Tag dsh-v0.1.1-rc.2 源码复核，未对所有系统后端进行实机穿透测试。

权限预设由哪两部分组成

官方的权限预设服务把两个独立控制项组合成一个界面选项：

控制项	回答的问题	0.1.1-rc.2 的值
沙箱模式	文件修改可以发生在哪里	read-only、workspace-write、danger-full-access
审批策略	工具请求批准时如何处理	ask、never

默认预设表包含：

预设	沙箱模式	审批策略	适合场景
workspace-write	workspace-write	ask	大多数交互式开发任务
danger-full-access	danger-full-access	never	已隔离环境中的完全自动化，风险最高

界面中可能出现的 custom 不是可以选择的第三个预设。它表示当前沙箱和审批组合没有匹配具名预设，是由实际状态推导出的展示值。

三种沙箱模式分别限制什么

read-only

拒绝文件写入，适合阅读代码、梳理目录和分析日志。它降低了文件被修改的风险，但不要把“只读文件系统”理解成“没有网络、看不到进程或不能读取敏感文件”。

workspace-write

允许在当前 Session 的工作区根目录和 DSH 管理的平台临时目录内写入。会话的 cwd 决定工作区边界，因此选择过大的目录会同时放大可写范围。第一次使用应选择一个独立测试目录，而不是用户主目录或包含多个项目的父目录。

danger-full-access

绕过 DSH 的文件效果约束。这个模式不会因为名字里有 “full” 就自动获得正确业务权限，也不会替你避免误删、错误部署、凭据泄露或外部 API 副作用。它只是撤掉了一层文件隔离。

ask 和 never 容易被误解的地方

ask 会把审批请求交给可用的应答者，例如交互式 UI。没有应答者、应答者异常或返回无效结果时，结论是 unavailable，调用方必须拒绝操作。只有 allowed-once 才允许本次动作继续；rejected、cancelled 和 unavailable 都不会放行。

never 的含义是“永不询问，所有审批请求都拒绝”，不是“无需询问、全部允许”。但默认的 danger-full-access 预设同时取消了文件沙箱，因此不要仅凭审批策略名称判断整体风险。

每次审批的询问与结论都会写入 Session 审计事件。它有助于复核当时发生了什么，但不能自动撤销已经执行的命令或外部写入。

沙箱没有承诺限制哪些能力

0.1.1-rc.2 CLI 参考明确说明：新会话的文件修改受 workspace-write 约束，但读取与网络访问不受这项文件策略限制。进程可见性取决于平台后端：

• Linux 的 Bubblewrap 后端使用私有 PID namespace，可隐藏宿主进程；
• Linux Landlock 与 macOS Seatbelt 保持宿主进程可见性；
• 后端还可能报告 full 或 partial 强制执行完整度。

当受限模式没有可用沙箱后端时，官方约定是返回 SANDBOX_UNAVAILABLE 并失败关闭，不能静默退化成无隔离执行。遇到这个错误，应修复平台后端或停止任务，而不是把模式直接切到完全访问来“消除报错”。

另外，MCP server 命令可能在 Agent 沙箱之外作为受信任代码运行。安装来源、启动命令、环境变量和凭据要单独审查，不能因为主 Agent 使用 workspace-write 就默认 MCP 也处于相同边界。

如何为任务选择权限

任务	推荐起点	额外措施
阅读陌生仓库	read-only	不提供生产凭据，检查读取范围
修改受 Git 管理的代码	workspace-write	先检查 git status，任务后看 diff 和测试
安装依赖或访问网络	workspace-write	明确包源、锁文件和网络目标
部署、数据库迁移、外部消息	独立测试环境	每个不可逆动作单独确认并准备回滚
无人值守自动化	最小沙箱与显式工具白名单	不依赖临时人工审批，限制凭据和网络出口

General Settings 中保存的权限只影响之后创建的 Web Session，不会改变已经打开的会话。修改设置后应新建测试 Session，再验证实际生效状态。

用一个最小任务验证边界

在独立测试目录中创建一个受 Git 管理的小项目，然后让 Agent：

1. 读取目录并说明计划；
2. 只修改一个指定文件；
3. 不安装依赖、不访问工作区外目录；
4. 返回修改清单和测试结果。

完成后检查 git status、文件 diff、终端日志、审批记录和工作区外目录。验证目标不是证明沙箱绝对安全，而是确认当前系统、后端、会话和任务组合与预期一致。

如果你刚开始使用，先按DeepSeek Harness 中文入门创建最小 Session，再阅读安全工作区准备指南。想理解审批、工具结果为何能被回放，可继续阅读DSH Session 使用与恢复指南。

常见问题

workspace-write 是否等于只能读取工作区

不是。它主要约束文件修改位置；读取和网络不由这项文件策略限制。

每次操作都会弹出审批吗

不会。审批是否发生还取决于工具与策略是否提出请求。ask 只是规定“有请求时交给应答者”，不是强制所有工具先弹窗。

Session 日志能回滚文件吗

不能。Session 可以记录工具调用和结果，但文件、数据库、部署和网络请求等外部副作用仍需要 Git、备份、事务或平台回滚机制。