Security · Independent guide

DeepSeek Harness Permissions & Sandbox Security

Do not treat workspace-write as a complete security boundary. Official rc.7 documentation says network access is outside SandboxMode, and the web_fetch source warns that private-network and SSRF protection is not implemented. Treat PTC Mode run_code as host user-level code execution unless an upstream fix explicitly proves confinement.

Reviewed Aug 19, 2026Developer previewIndependent guide
Evidence status: Official rc.7 documentation and tagged source, with two open reports labeled separately. Re-check the linked first-party source after a new release candidate.
Track setup progress →

Sharing includes the public link only, without local progress or private configuration.

Verified capability boundaries

SandboxMode governs documented filesystem effects; it is not a promise to isolate network access, process visibility, every extension, or every code-runtime path. The Python minimal example is intentionally more permissive and uses danger-full-access, so its behavior must not be generalized to workspace-write.

The official rc.7 web_fetch provider source states that private-network and SSRF protection is not implemented. On a host that can reach cloud metadata, loopback services or private subnets, do not enable that provider without an external egress policy that blocks those destinations.

  1. Separate filesystem policy, approval policy, network egress and process isolation in the threat model.
  2. Use a disposable OS account or container without production credentials for untrusted work.
  3. Apply outbound proxy or firewall rules; a workspace sandbox does not supply SSRF filtering.

PTC Mode and run_code

The rc.7 worker-thread implementation creates a Node worker and executes generated code through an AsyncFunction path. Open Discussion #3245 reports that this run_code path is not wrapped by ctx.sandbox.confine(). The source supports the execution-path concern, while the security impact remains an open community report rather than a publisher-confirmed advisory.

Until upstream resolves or documents the boundary, avoid DSH_TOOLS_MODE=code or both when filesystem confinement is a hard requirement. If PTC is needed, run the entire Harness process inside an independently enforced container or virtual machine boundary.

  1. Do not describe PTC run_code as protected by workspace-write without a version-specific proof.
  2. Keep secrets outside the process environment and mounted workspace.
  3. Re-check tagged source and the report after every release candidate.

Verification before sensitive use

A safe configuration is demonstrated by blocked effects at the external boundary, not by a preset label. Test with canary files and denied network destinations in a disposable environment, and record the exact rc, OS, runtime, profile and enforcement layer.

  1. Verify writes outside the allowed workspace fail at the OS or container layer.
  2. Verify loopback, link-local and private-network destinations are blocked by egress controls.
  3. Treat #3245 and #3051 as open, not independently reproduced reports until their upstream status changes.

First-party sources

Open the pinned or retrieved source before acting on a changed release candidate.

Community reports

These are open user reports hosted in the official repository. They are not publisher confirmation and have not been independently reproduced by this guide unless a separate local reproduction is linked.

Continue by layer

DeepSeek Harness Plugin Security Checklist
Open guide →DeepSeek Harness Windows Install: PowerShell and WSL
Open guide →DeepSeek Harness Telemetry & Privacy
Open guide →