- DSH
- 0.1.5-rc.1
- 系统
- Windows / macOS / Linux
- 风险
- high
本页目录（11）
先看结论
DSH 的“权限”不是单个开关，而是沙箱模式与审批策略的组合。0.1.5-rc.1 新会话默认使用 workspace-write 预设，即文件写入被限制在会话工作区和平台临时目录，遇到需要批准的操作时采用 ask；这不等于完全离线，也不保证所有平台拥有相同的进程隔离效果。
日常代码任务优先使用 workspace-write。只有在你理解命令、目录、凭据和外部副作用后，才考虑 danger-full-access。基础说明于 2026-09-12 依据官方 0.1.5-rc.1 固定提交复核；后文另列 0.1.6-alpha.2 用户终端与 0.1.7-alpha.1 Windows 补充，未对系统后端进行实机穿透测试。
三种模式怎么选
按任务选择表决定文件修改范围，再核对当前会话的审批策略。三种沙箱模式不是所有版本界面都有的三个预设按钮；本文 rc.1 的具名预设与 custom 状态见预设组成。
完全权限意味着什么
danger-full-access 撤掉 DSH 的文件效果约束，不代表已经取得业务授权或系统管理员权限。目录、凭据与外部写入仍需确认；具体边界见三种沙箱模式。
选了工作区，为什么仍然不能写入
目录选中只说明会话已有关联位置。继续检查目标路径、沙箱模式、审批结果和系统后端，按无法写入分流处理，不直接扩大权限。
如何为任务选择权限
| 任务 | 推荐起点 | 额外措施 |
|---|---|---|
| 阅读陌生仓库 | read-only | 不提供生产凭据，检查读取范围 |
| 修改受 Git 管理的代码 | workspace-write | 先检查 git status，任务后看 diff 和测试 |
| 安装依赖或访问网络 | workspace-write | 明确包源、锁文件和网络目标 |
| 部署、数据库迁移、外部消息 | 独立测试环境 | 每个不可逆动作单独确认并准备回滚 |
| 无人值守自动化 | 最小沙箱与显式工具白名单 | 不依赖临时人工审批，限制凭据和网络出口 |
在本文 0.1.5-rc.1 范围内，General Settings 中保存的权限只影响之后创建的 Web Session，不会改变已经打开的会话。修改设置后应新建测试 Session，再验证实际生效状态。
权限预设由哪两部分组成
官方的权限预设服务把两个独立控制项组合成一个界面选项：
| 控制项 | 回答的问题 | 0.1.5-rc.1 的值 |
|---|---|---|
| 沙箱模式 | 文件修改可以发生在哪里 | read-only、workspace-write、danger-full-access |
| 审批策略 | 工具请求批准时如何处理 | ask、never |
默认预设表包含：
| 预设 | 沙箱模式 | 审批策略 | 适合场景 |
|---|---|---|---|
workspace-write | workspace-write | ask | 大多数交互式开发任务 |
danger-full-access | danger-full-access | never | 已隔离环境中的完全自动化，风险最高 |
界面中可能出现的 custom 不是可以选择的第三个预设。它表示当前沙箱和审批组合没有匹配具名预设，是由实际状态推导出的展示值。
三种沙箱模式分别限制什么
read-only
要求后端拒绝文件写入；POSIX shell 保留必要的 /dev/null 接收器，Windows ACL 后端可能报告部分强制执行。适合阅读代码、梳理目录和分析日志。它降低了文件被修改的风险，但不要把“只读文件系统”理解成“没有网络、看不到进程或不能读取敏感文件”。
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 审计事件。它有助于复核当时发生了什么，但不能自动撤销已经执行的命令或外部写入。
DSH 无法写入，先检查什么
| 现象 | 先检查 | 下一步 |
|---|---|---|
| 页面不能输入或尚未选项目 | 当前会话的 Workspace 与模型 | 工作区选择排障 |
| 读取成功、写入被拒绝 | 目标是否在实际工作区内，当前沙箱是否 read-only | 核对会话策略与目标路径，不扩大到整个用户目录 |
| 请求审批后仍失败 | 是否有可用应答者、结果是 rejected 还是 unavailable | 有交互需求时使用可应答的工作流；Headless 见一次性任务指南 |
| SANDBOX_UNAVAILABLE | 系统后端是否可用 | 保留脱敏错误并修复后端，不通过关闭隔离掩盖问题 |
先区分工作区、审批与系统文件权限，单独改变一项再检查。本文提供固定源码支持的策略解释，未执行跨平台运行验收。
0.1.6-alpha.2：用户终端与权限预设
选择只读模式后，Web 用户终端为什么仍能修改文件？ alpha.2 的 Web 用户终端以宿主系统用户权限运行，不受 Agent 会话的 read-only 或 workspace-write 限制。先看动作来自哪里，再判断权限；本节为 2026-09-18 固定源码审阅，未做跨平台沙箱实测，其余主体保留 rc.1 范围。
| 执行来源 | 权限边界 | 怎样辨认 |
|---|---|---|
| 用户在 Web 终端输入的命令 | 系统用户权限，独立于 Agent 会话权限 | 侧栏终端中的手工输入；只需用 pwd 等只读命令检查当前目录，不用写删文件证明权限 |
| Agent 调用 Shell / PTC 工具 | 由相应工具、运行时与会话策略共同控制 | 对话中的工具调用记录和当次审批；不能用用户终端结果推断工具获得了同等权限 |
| 宿主插件自身执行 | 插件与宿主进程的实现决定 | 不属于上述 Agent 工具审批的统一保证；应另核对插件权限与数据流 |
alpha.2 重新选择当前有效权限预设时，只对实际不同的权限字段提出变更；没有变化的重复选择不再触发相同变更审批。这不表示切换为更宽权限也免审批，更不表示后续所有工具操作免审批。Web 终端折叠后进程仍可运行；关闭终端会请求停止，结束任务后检查终端状态。
依据：Web 终端说明（外部链接，在新标签页打开）、终端控制器（外部链接，在新标签页打开）、权限预设实现（外部链接，在新标签页打开）。
沙箱没有承诺限制哪些能力
0.1.5-rc.1 CLI 参考明确说明：新会话的文件修改受 workspace-write 约束，但读取与网络访问不受这项文件策略限制。进程可见性取决于平台后端：
- Linux 的 Bubblewrap 后端使用私有 PID namespace，可隐藏宿主进程；
- Linux Landlock 与 macOS Seatbelt 保持宿主进程可见性；
- 后端还可能报告
full或partial强制执行完整度。
当受限模式没有可用沙箱后端时，官方约定是返回 SANDBOX_UNAVAILABLE 并失败关闭，不能静默退化成无隔离执行。遇到这个错误，应修复平台后端或停止任务，而不是把模式直接切到完全访问来“消除报错”。
另外，MCP server 命令可能在 Agent 沙箱之外作为受信任代码运行。安装来源、启动命令、环境变量和凭据要单独审查，不能因为主 Agent 使用 workspace-write 就默认 MCP 也处于相同边界。
用一个最小任务验证边界
在独立测试目录中创建一个受 Git 管理的小项目，然后让 Agent：
- 读取目录并说明计划；
- 只修改一个指定文件；
- 不安装依赖、不访问工作区外目录；
- 返回修改清单和测试结果。
完成后检查 git status、文件 diff、终端日志、审批记录和工作区外目录。验证目标不是证明沙箱绝对安全，而是确认当前系统、后端、会话和任务组合与预期一致。
如果你刚开始使用，先按DeepSeek Harness 中文入门创建最小 Session，再阅读安全工作区准备指南。想理解审批、工具结果为何能被回放，可继续阅读DSH Session 使用与恢复指南。
常见问题
workspace-write 是否等于只能读取工作区
不是。它主要约束文件修改位置；读取和网络不由这项文件策略限制。
每次操作都会弹出审批吗
不会。审批是否发生还取决于工具与策略是否提出请求。ask 只是规定“有请求时交给应答者”，不是强制所有工具先弹窗。
Session 日志能回滚文件吗
不能。Session 可以记录工具调用和结果，但文件、数据库、部署和网络请求等外部副作用仍需要 Git、备份、事务或平台回滚机制。
0.1.7-alpha.1：Windows 删除边界修复怎样理解
2026-09-22 固定源码补充，限 Windows ACL 沙箱后端；未在 Windows 实机验收，旧版的完整受影响范围尚未确定。 官方 Release 记录了授权目录外及跨工作区删除相关修复；不能据此宣称所有平台或所有文件操作都已获得同样保证。
固定实现通过目录上的拒绝规则阻止借用父目录的删除权限，并用不同的工作区、临时目录身份限制授权。只读模式与工作区写入模式仍需分别核对；写入或删除限制不等于读取、网络与宿主插件同时受限。
上游还明确记录硬链接、其他工具写入的 AppContainer ACL 等边界。工作区 ACL 与标签改动会保留以便复用，并非退出会话就全部撤销。若日常目录操作发生权限错误，先保留原文、实际路径、模式与后端信息；不要照搬清除 ACL 或开启完全访问来绕过问题。
需要评估这项修复时，在独立测试目录中核对允许的写入、应拒绝的越界操作及正常删除是否符合预期，结合升级备份与回退条件决定是否升级。本站源码审阅不是 Windows 运行或安全验收。
依据：官方发行说明（外部链接，在新标签页打开）、固定后端约定与已知边界（外部链接，在新标签页打开）、目录删除权限实现（外部链接，在新标签页打开）。
来源与维护信息
本文根据以下原始资料整理。版本变化后，请以官方资料和页面标注的验证日期为准。
- GitHub：deepseek-ai/deepseek-harness（外部链接，在新标签页打开）
- GitHub：deepseek-ai/deepseek-harness 固定提交 README.zh.md（外部链接，在新标签页打开）
- GitHub：deepseek-ai/deepseek-harness 固定提交 acl.ts（外部链接，在新标签页打开）
- GitHub：deepseek-ai/deepseek-harness 固定提交 README.zh.md（外部链接，在新标签页打开）
- GitHub：deepseek-ai/deepseek-harness 固定提交 terminal.ts（外部链接，在新标签页打开）
- GitHub：deepseek-ai/deepseek-harness 固定提交 index.ts（外部链接，在新标签页打开）
- GitHub：deepseek-ai/deepseek-harness 固定提交 permission-presets.zh.md（外部链接，在新标签页打开）
- GitHub：deepseek-ai/deepseek-harness 固定提交 sandbox.zh.md（外部链接，在新标签页打开）
- GitHub：deepseek-ai/deepseek-harness 固定提交 approval.zh.md（外部链接，在新标签页打开）
- GitHub：deepseek-ai/deepseek-harness 固定提交 README.zh.md（外部链接，在新标签页打开）