---
title: "DSH 权限与沙箱指南：workspace-write、审批与安全边界"
description: "基于 DeepSeek Harness 0.1.1-rc.2 官方源码，解释权限预设、沙箱模式、审批策略、平台差异和安全使用方法。"
canonical: https://52dsh.com/tutorials/dsh-permissions-sandbox/
authors: ["52DSH 编辑部"]
published_at: 2026-08-21
updated_at: 2026-08-21
verified_on: 2026-08-21
maintenance_status: community
verification_level: source_reviewed
risk_level: high
---

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

基于 DeepSeek Harness 0.1.1-rc.2 官方源码，解释权限预设、沙箱模式、审批策略、平台差异和安全使用方法。

## 先看结论

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 中文入门](/tutorials/dsh-complete-guide/)创建最小 Session，再阅读[安全工作区准备指南](/tutorials/safe-agent-workspace/)。想理解审批、工具结果为何能被回放，可继续阅读[DSH Session 使用与恢复指南](/tutorials/dsh-session-guide/)。

## 常见问题

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

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

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

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

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

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

## 原始来源

- https://github.com/deepseek-ai/deepseek-harness/blob/dsh-v0.1.1-rc.2/docs/subsystems/permission-presets.zh.md
- https://github.com/deepseek-ai/deepseek-harness/blob/dsh-v0.1.1-rc.2/docs/subsystems/sandbox.zh.md
- https://github.com/deepseek-ai/deepseek-harness/blob/dsh-v0.1.1-rc.2/docs/subsystems/approval.zh.md
- https://github.com/deepseek-ai/deepseek-harness/blob/dsh-v0.1.1-rc.2/apps/cli/reference/README.zh.md