---
title: "DSH 权限与沙箱指南：workspace-write、审批与安全边界"
seo_title: "DSH 权限与沙箱指南：workspace-write、审批与安全边界"
description: "按任务选择 DSH 权限，区分沙箱模式与审批，排查工作区写入失败；保留 0.1.5-rc.1 基础说明，补充 0.1.7-alpha.1 Windows 删除边界。"
canonical: https://52dsh.com/tutorials/dsh-permissions-sandbox/
authors: ["52DSH 编辑部"]
audience: []
outcomes: []
prerequisites: ["已了解 DSH 工作区的作用"]
difficulty: intermediate
estimated_action_time: null
next_steps: null
published_at: 2026-08-21
updated_at: 2026-09-22
verified_on: 2026-09-12
maintenance_status: community
verification_level: source_reviewed
risk_level: high
dsh_version: 0.1.5-rc.1
plugin_id: null
tutorial_kind: null
related_plugin_url: null
---

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

按任务选择 DSH 权限，区分沙箱模式与审批，排查工作区写入失败；保留 0.1.5-rc.1 基础说明，补充 0.1.7-alpha.1 Windows 删除边界。

## 先看结论

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 的文件效果约束，不代表已经取得业务授权或系统管理员权限。目录、凭据与外部写入仍需确认；具体边界见[三种沙箱模式](#三种沙箱模式分别限制什么)。

### 选了工作区，为什么仍然不能写入

目录选中只说明会话已有关联位置。继续检查目标路径、沙箱模式、审批结果和系统后端，按[无法写入分流](#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 与模型 | [工作区选择排障](/errors/dsh-workspace-not-selected/) |
| 读取成功、写入被拒绝 | 目标是否在实际工作区内，当前沙箱是否 read-only | 核对会话策略与目标路径，不扩大到整个用户目录 |
| 请求审批后仍失败 | 是否有可用应答者、结果是 rejected 还是 unavailable | 有交互需求时使用可应答的工作流；Headless 见[一次性任务指南](/tutorials/dsh-headless-guide/) |
| 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 终端说明](https://github.com/deepseek-ai/deepseek-harness/blob/ddefc45fbc7f8e46dd73185e68295696d1297887/packages/client/ui-sidebar-terminal/README.zh.md)、[终端控制器](https://github.com/deepseek-ai/deepseek-harness/blob/ddefc45fbc7f8e46dd73185e68295696d1297887/packages/api/terminal-controller/src/terminal.ts)、[权限预设实现](https://github.com/deepseek-ai/deepseek-harness/blob/ddefc45fbc7f8e46dd73185e68295696d1297887/packages/interaction/permission-presets/src/index.ts)。

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

`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：

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

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

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

## 常见问题

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

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

### 每次操作都会弹出审批吗

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

### Session 日志能回滚文件吗

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

## 0.1.7-alpha.1：Windows 删除边界修复怎样理解

**2026-09-22 固定源码补充，限 Windows ACL 沙箱后端；未在 Windows 实机验收，旧版的完整受影响范围尚未确定。** 官方 Release 记录了授权目录外及跨工作区删除相关修复；不能据此宣称所有平台或所有文件操作都已获得同样保证。

固定实现通过目录上的拒绝规则阻止借用父目录的删除权限，并用不同的工作区、临时目录身份限制授权。只读模式与工作区写入模式仍需分别核对；写入或删除限制不等于读取、网络与宿主插件同时受限。

上游还明确记录硬链接、其他工具写入的 AppContainer ACL 等边界。工作区 ACL 与标签改动会保留以便复用，并非退出会话就全部撤销。若日常目录操作发生权限错误，先保留原文、实际路径、模式与后端信息；不要照搬清除 ACL 或开启完全访问来绕过问题。

需要评估这项修复时，在独立测试目录中核对允许的写入、应拒绝的越界操作及正常删除是否符合预期，结合[升级备份与回退条件](/tutorials/dsh-update-uninstall/#017-alpha1升级前先检查数据与设置)决定是否升级。本站源码审阅不是 Windows 运行或安全验收。

依据：[官方发行说明](https://github.com/deepseek-ai/deepseek-harness/releases/tag/dsh-v0.1.7-alpha.1)、[固定后端约定与已知边界](https://github.com/deepseek-ai/deepseek-harness/blob/c36a83ff6bb95e3f82cf79f9be7c724270a8aa61/packages/sandbox/sandbox-windows-acl/README.zh.md)、[目录删除权限实现](https://github.com/deepseek-ai/deepseek-harness/blob/c36a83ff6bb95e3f82cf79f9be7c724270a8aa61/packages/sandbox/sandbox-windows-acl/src/acl.ts)。

## 原始来源

- https://github.com/deepseek-ai/deepseek-harness/releases/tag/dsh-v0.1.7-alpha.1
- https://github.com/deepseek-ai/deepseek-harness/blob/c36a83ff6bb95e3f82cf79f9be7c724270a8aa61/packages/sandbox/sandbox-windows-acl/README.zh.md
- https://github.com/deepseek-ai/deepseek-harness/blob/c36a83ff6bb95e3f82cf79f9be7c724270a8aa61/packages/sandbox/sandbox-windows-acl/src/acl.ts
- https://github.com/deepseek-ai/deepseek-harness/blob/ddefc45fbc7f8e46dd73185e68295696d1297887/packages/client/ui-sidebar-terminal/README.zh.md
- https://github.com/deepseek-ai/deepseek-harness/blob/ddefc45fbc7f8e46dd73185e68295696d1297887/packages/api/terminal-controller/src/terminal.ts
- https://github.com/deepseek-ai/deepseek-harness/blob/ddefc45fbc7f8e46dd73185e68295696d1297887/packages/interaction/permission-presets/src/index.ts
- https://github.com/deepseek-ai/deepseek-harness/blob/183f08e9c6dde7e36cd2318eaee70b0da08fb35e/docs/subsystems/permission-presets.zh.md
- https://github.com/deepseek-ai/deepseek-harness/blob/183f08e9c6dde7e36cd2318eaee70b0da08fb35e/docs/subsystems/sandbox.zh.md
- https://github.com/deepseek-ai/deepseek-harness/blob/183f08e9c6dde7e36cd2318eaee70b0da08fb35e/docs/subsystems/approval.zh.md
- https://github.com/deepseek-ai/deepseek-harness/blob/183f08e9c6dde7e36cd2318eaee70b0da08fb35e/apps/cli/reference/README.zh.md