DeepSeek Harness 权限与沙箱：read-only、workspace-write、danger-full-access

DeepSeek-Harness（dsh）通过两个相互独立的层来控制一个 agent 到底能做什么：沙箱模式（sandbox mode）（操作系统级的执行环境允许什么）和审批策略（approval policy）（agent 在动手之前是否要先问一句）。新 session 默认是 workspace-write 沙箱 + ask 审批——不带任何提示的完全访问权限确实存在，但它不是默认值，而且它确实会在某个地方默认出现，值得下面细看一下。

三档沙箱模式

模式	允许什么
`read-only`	完全禁止写入。POSIX 后端额外放行专门写入 `/dev/null`。
`workspace-write`	写操作被限制在该 session 的工作区根目录，以及平台约定的临时目录内。这个模式不限制网络访问和进程可见性。这是新 session 的默认值。
`danger-full-access`	完全不做任何隔离。

注意 workspace-write 里的这个缺口：它约束的是文件系统，不是网络或 agent 能看到哪些进程。一个 workspace-write 的 session 依然可以发起任意的出站网络调用。

各平台的沙箱后端

这些模式在不同平台上的强制执行方式并不一样，强制力等级也并非处处一致：

平台	后端
Linux	bwrap / Landlock
macOS	Seatbelt
Windows	基于 ACL 的受限令牌方案（`dsh-sandbox-windows-acl`）
云端（可选）	E2B 云沙箱（`packages/e2b`）——把执行环境换成一个远程隔离容器,而不是本机进程沙箱

较老版本的 Landlock ABI 和 Windows ACL 后端只能做到**部分（partial）**强制力，达不到 full——文档明确要求使用方区分这两种强制力等级，而不是把每种后端都当成同等强度对待。如果你正在为一个安全敏感的场景评估 dsh，这个区分比单看模式名字更重要。

权限预设：把沙箱模式和审批策略打包在一起

一个权限预设把一个沙箱模式和一个审批策略打包成一个命名选项，呈现给客户端（ctx.permissionPresets）。默认表恰好只有两条：

workspace-write:
  sandbox: workspace-write
  approval: ask        # 在沙箱允许范围之外的写入/执行操作之前先弹窗询问

danger-full-access:
  sandbox: danger-full-access
  approval: never       # 完全不问——全权访问，无任何提示

你可以在配置里定义更多自定义预设；custom 这个名字本身是保留的，不能被你自己定义的预设复用。这是一处 cordis.patch.yml 级别的改动——如何在不误删同一行其他设置的前提下新增一行，见配置指南，因为覆盖是整体替换目标行的配置,而不是合并。

DSH_PERMISSION_MODE 会覆盖"新 session 以哪个预设启动"这一进程级兜底选项——完整环境变量表见 CLI 速查表。

`danger-full-access` 在哪里会默认出现——以及为什么这很重要

Web UI 的极简提示路径和交互式 session 默认是 workspace-write + ask。但Python SDK 自己的示例代码默认接的是 danger-full-access：

from deepseek_harness import DeepSeekHarness

with DeepSeekHarness(
    provider="deepseek-official",
    model="deepseek-v4-flash",
    max_tokens=49_152,
    cwd=str(workspace),
    session_root=str(sessions),
    cordis=str(config),
) as harness:
    result = harness.run("Inspect the repository and fix the failing tests.", session_id="example-001")

文档在这个示例旁边附了一条明确警告：只应该在一次性 checkout 或容器里跑这段代码——原因正是它默认不做任何沙箱化。如果你正打算通过 SDK 把 dsh 接进一个脚本、CI 任务，或者任何程序化流水线里，先明确核实一下你实际运行在哪种沙箱模式下——不要假设 SDK 会继承 Web UI 那个更安全的默认值，因为开箱即用它并不会。

审批策略：预设的另一半

沙箱限制的是一个动作在操作系统层面能做到什么；审批策略决定的是 harness 在真正执行这个动作之前会不会先停下来问人一句。两个默认预设正好位于这条轴线的两端：workspace-write 把一个中等受限的沙箱和 ask 搭配在一起——agent 在超出其允许范围的写入或执行操作之前会停下来等一个是/否的回答。danger-full-access 把完全不隔离和 never 搭配在一起——什么都不会被确认，永远不会。

两条默认预设的表格没有明确展示出中间地带，但自定义预设可以表达它：一个更宽松的沙箱但依然开着 ask，或者一个范围收得很紧、因为影响面已经足够小而关掉审批的沙箱。如果你要在 cordis.patch.yml 里定义自己的预设，请把沙箱模式和审批策略当成两个真正独立的旋钮，而不是一个"我有多信任这个 session"的单一滑块——一个网络不受限、但文件系统不能写的 session，和一个文件系统可以随便写、但没有网络访问的 session，风险画像是完全不同的。

强制力等级并不统一

文档明确指出了两个已知的缺口：Linux 上较老版本的 Landlock ABI，以及 Windows 的 ACL 受限令牌后端，只能做到"部分（partial）"强制力，达不到"完全（full）"——使用方需要区分这两种情况，而不是把每种后端都当成同等强度对待。参考资料没有给出每个后端、每个平台版本的完整 full/partial 对照表，所以不要因为 macOS Seatbelt 或 E2B 没有和这两个有文档记录的 partial 案例并列出现，就想当然地认为它们在任何配置下都自动是"full"——如果这个区分对你的威胁模型很重要，应该针对你实际的操作系统/内核版本去核实。

"Partial" 不是可以一眼扫过的脚注——它意味着这个沙箱可能被绕过，或者存在一些 full 强制力会堵上的缺口。如果你打算在 Windows 或较老的 Linux 内核上把 dsh 用于个人可信场景之外的任何用途，值得花时间搞清楚那个具体后端上的"partial"到底留了哪些口子，并且在这些平台上把"是否沙箱化"当成一个程度谱系，而不是非黑即白的保证。

实操清单

搞清楚你的默认值是什么。 交互式 session（Web UI、headless CLI）默认是 workspace-write + ask。SDK 示例代码不是——需要明确核实。
不要把 workspace-write 等同于"网络不会被泄露数据"。 它限制的是文件系统,不是出站网络调用。
在 Windows 和较老的 Linux 内核上，要看强制力等级，不能只看模式名字——部分强制力是一个真实存在、有文档记录的缺口。
danger-full-access 有它的用武之地（一次性容器、一次性 checkout），但绝不应该是接触真实机器或真实凭据的 session 的默认值。
第三方插件在安装期也会在你的机器上执行代码，这与运行时沙箱是相互独立的——为什么权限预设本身覆盖不了安装期风险，见如何安装 DeepSeek-Harness 插件里关于 allowBuilds 的讨论。
如果你想对实际配置做一次本地、只读的审计——沙箱设置、插件来源、session 状态、网络暴露面——开发与运行时分类下的 dsh-security-audit 正是做这类检查的，会产出一份脱敏的风险报告。

DeepSeek Harness 权限与沙箱：read-only、workspace-write、danger-full-access

三档沙箱模式

各平台的沙箱后端

权限预设：把沙箱模式和审批策略打包在一起

`danger-full-access` 在哪里会默认出现——以及为什么这很重要

审批策略：预设的另一半

强制力等级并不统一

实操清单

FAQ

`workspace-write` 足以安全地运行一个不受信任的插件吗？

`read-only` 模式下 agent 还能跑任何命令吗？

为什么 Windows 沙箱后端的强制力等级会有影响？

我可以创建自己的权限预设吗？

E2B 会取代本地沙箱后端吗？

下一步