DeepSeek Harness Sandbox: Isolation for Agent Execution
DeepSeek Harness sandboxes are swappable plugins; Minimal mode uses bash + str_replace_editor; tool approval never sandboxes plugin code.
Sandboxes Are Plugins
In DeepSeek Harness, sandboxes are a first-class plugin category. The official capability list names them explicitly — models, tools, skills, sessions, sandboxes, storage, loops, scheduling, and the UI are all plugins — which means the execution environment an agent runs in is replaceable like any other component[1].
That matters for two groups. Security-conscious teams can plug in a container or VM-backed sandbox for tool execution, and benchmarkers can run the minimal two-tool composition for reproducible model evaluation without the noise of a full environment[1][2].
Because the sandbox is a plugin, its behavior is configured per profile — the same codebase can run a desktop agent and a benchmark harness.
What Each Mode Ships
The four official modes carry different default sandbox behavior[1]:
Minimal mode's two tools are the same pair DeepSeek used for the official V4-Flash-0731 agent benchmarks: a persistent bash shell and a str_replace_editor for file edits[2].
| Mode | Default execution environment | Notes |
|---|---|---|
| Standard | Full toolset: file editing + shell + web search | File access scoped to the workspace |
| Code | Standard + Code Mode SDK | TypeScript programs orchestrate multi-step tool calls |
| Minimal | Persistent bash + str_replace_editor only | Two-tool minimal environment for benchmarks[2] |
| Creator | Runtime inspection environment | In-memory plugin testing, no persistent side effects |
Workspaces and File Isolation
File-level isolation is organized around the workspace concept. dsh uses the launch directory as the default filesystem position, and in the Web UI you must explicitly choose a workspace before starting a session[3].
In practice this means an agent session's file reads and writes are anchored to the chosen project directory. Sessions started from the wrong directory are the most common 'my files are missing' failure — always confirm the workspace before delegating anything important[3].
- Workspace = the project directory the agent operates in
- Web UI requires an explicit workspace choice per session[3]
- Launching dsh from the wrong directory = empty or missing files
The Security Model (and Its Limits)
The honest security picture[4]:
Tool execution inside a session is gated by an approval policy — the agent proposes tool calls and you approve them. That is the primary control. What is NOT sandboxed: plugin code itself. Installing a plugin means running third-party code that can read your files, use your credentials, and reach the network. Tool approval does not sandbox plugin code[4].
The community guidebook recommendation is blunt: treat unfamiliar plugins as untrusted, test them in an environment without secrets, and prefer plugins that declare their dsh.bundle manifest so at least the dependency surface is visible[4].
For a browser of what plugins exist and their trust posture, see the plugin ecosystem guide.
Swapping the Sandbox Provider
To change the execution environment, you swap or extend the sandbox plugin in your profile's bundle list — the same mechanism as any other capability[1][5].
Because sandbox configuration is part of the profile patch layer (bundle patches → profile cordis.patch.yml → $DSH_HOME/cordis.patch.yml → --patch), you can keep a strict sandbox in your global config and relax it per-project — see the setup guide for the layering order[5].
# typical flow
dsh plugin --profile web add <sandbox-plugin>
# then edit the profile's cordis.patch.yml to select the plugin,
# and restart the profile:
dsh --profile webPractical Advice
Summary of what to do today[3][4]:
If you came here from the benchmark discussion, Minimal mode's two-tool environment is the reproducible setup to study — see harness benchmarks. For installation, start at install dsh.