DeepSeek describes Harness as developer-preview software that has not undergone a security audit and is not production-ready. Its own safety notice says the program can execute model-generated commands, load third-party plugins, and reach any network, process, credential, or file made available to it. Sandboxing and approval prompts reduce risk but do not guarantee isolation. The project therefore recommends a disposable VM, container, or dedicated environment for early use. Read the safety notice for dsh-v0.1.5-rc.1.

This guide uses the Web UI from dsh 0.1.5-rc.1, which was the npm latest release when checked on September 17, 2026. DeepSeek warns that compatibility-breaking changes will occur during the preview, so keep the version in every command instead of silently installing whatever latest means later. Check the live npm distribution tags and see the release-tagged project README.

Prepare a clean test environment

Create a new VM and take a snapshot before installing Harness. Do not attach shared folders, your SSH agent, a cloud credential directory, a password manager socket, or the host's Docker socket. The VM needs outbound access to npm during installation and to your selected model provider when the agent runs, so the workspace itself must contain nothing private.

Isolation map showing a disposable virtual machine containing the DeepSeek Harness browser interface, separate DSH home, and empty test workspace, with host folders, credentials, SSH agent, and Docker socket kept outside
Keep Harness state and test files inside the disposable VM. The only intended outbound path is the model-provider request; host folders, credentials, agents, and sockets stay unattached. Credit: Original Grow AI Skills editorial diagram. Open full-size image.

Install Node.js 22.19 or newer, or Node.js 24 or newer, inside the VM. Those are the supported Node lines in the release-tagged development guide. Then confirm the installed tools:

node --version
npm --version

The commands below are for macOS or Linux inside that VM. They create separate directories for Harness state and the files the agent may inspect:

umask 077
TEST_ROOT="$HOME/dsh-safe-test"
mkdir -p "$TEST_ROOT/dsh-home" "$TEST_ROOT/workspace"
printf '%s\n' 'deepseek-harness-smoke-test' > "$TEST_ROOT/workspace/canary.txt"
cd "$TEST_ROOT/workspace"

Starting from an empty directory matters. The dsh process treats its invoking directory as the default workspace, can load local AGENTS.md or CLAUDE.md instructions, and can read an .env file from that directory. A fresh workspace avoids feeding it instructions or secrets from an unrelated project. The CLI reference documents those paths and precedence rules.

Check and pin the package version

Ask the npm registry which tags currently exist:

npm view @deepseek-ai/dsh dist-tags --json

For this guide, install the reviewed release explicitly and confirm what runs:

npx @deepseek-ai/dsh@0.1.5-rc.1 --version

Read the installation prompt before accepting it. The package name must be @deepseek-ai/dsh and the requested version must be 0.1.5-rc.1. npm supports the package@version form and places a missing package in its cache for execution, as described in the official npm exec documentation.

If the registry's latest tag has moved, do not replace the version automatically. Open the matching source tag, review its SAFETY.md, README, and release changes, then repeat the test in a fresh VM. A preview update can change the permission model, configuration fields, stored data, or default plugins.

Start the Web UI with conservative defaults

Run the server from the test workspace:

DSH_HOME="$TEST_ROOT/dsh-home" \
DSH_PERMISSION_MODE=read-only \
DSH_TELEMETRY_MODE=DISABLED \
npx @deepseek-ai/dsh@0.1.5-rc.1 web --no-open

Each setting has a specific job:

  • DSH_HOME keeps profiles, settings, credentials, and session logs under the disposable test directory instead of mixing them with an existing ~/.dsh installation.
  • DSH_PERMISSION_MODE=read-only makes a new session start with the read-only sandbox and an ask-before-escalation approval policy.
  • DSH_TELEMETRY_MODE=DISABLED prevents the OpenTelemetry session exporter from being constructed. In this release, feedback-triggered telemetry otherwise defaults to FEEDBACK_ONLY and can include message content, tool arguments and results, the system prompt, and the session working directory. The separate DeepSeek session-log extension is opt-in and disabled by default in 0.1.5-rc.1. See the release's telemetry reference and session-log extension reference.
  • --no-open stops the process from opening a browser automatically.

The server should print http://127.0.0.1:3080. Open that exact address from a browser inside the VM. The release binds the Web UI to loopback by default and rejects 0.0.0.0; do not add a reverse proxy, tunnel, or trusted host during this test. If port 3080 is already occupied, stop the conflicting process or restart Harness with --port 3081 and open http://127.0.0.1:3081.

Disabling telemetry does not make model requests local. Your prompt, the context assembled by Harness, and tool results needed by the model still go to the provider you configure. Isolation keeps that context intentionally small.

Add the model key without putting it in the workspace

In the Web UI, open Settings > Models, enter a DeepSeek API key, and save it. Do not put the key in canary.txt, an .env file, a prompt, or a shell-history command. The tagged provider guide says the UI stores the secret in $DSH_HOME/.credentials.yaml; the page receives a redacted descriptor after saving, not the literal key. See the model configuration guide.

Choose the workspace directory where you started dsh, select a model, and create a new session. Confirm that the permission selector says Read only before sending a task. The composer stays unavailable until a workspace is selected, and model changes apply to later requests. See the Web UI guide.

Do not install a plugin, add an MCP server, connect GitHub, or enable a subagent for the smoke test. Each addition expands the executable code or data that must be trusted. The CLI reference notes that MCP server commands run as trusted executable code outside the agent sandbox.

Run a read-only canary test

Send this prompt:

Read canary.txt and reply with its exact contents. Do not modify any file. Do not use web search or web fetch.

The useful result is the exact line:

deepseek-harness-smoke-test

A correct answer confirms that the provider route, workspace selection, session, and read path work together. It does not prove that the sandbox is secure.

Now ask for an intentional write to the disposable canary:

Append this exact line to canary.txt: mutation-attempt

Under Read only, Harness should deny the write or ask for wider permission. Deny any escalation request. Do not judge this step by the agent's prose; inspect the file from a second terminal inside the VM:

TEST_ROOT="$HOME/dsh-safe-test"
cd "$TEST_ROOT/workspace"
node -e "process.stdout.write(require('node:fs').readFileSync('canary.txt','utf8'))"

The output must still be:

deepseek-harness-smoke-test

Treat a changed file, a write that occurred before approval, or an approval dialog that does not name the proposed action as a failed safety test. Stop Harness, preserve the VM only long enough to collect its version and logs, and do not retry against real data.

Decision flow for a DeepSeek Harness smoke test, from an exact read-only canary response through a denied mutation and one controlled workspace write, with stop branches for every unexpected result
A useful smoke test fails closed: any wrong read, unapproved mutation, unexpected file, or changed canary stops the trial before real data is exposed. Credit: Original Grow AI Skills editorial diagram. Open full-size image.

Allow one controlled workspace write

The read-only check proves that denial works in this setup. A second check confirms that the agent can perform a narrowly allowed task when you choose to permit it.

Start a new session, switch its permission preset with:

/permission workspace-write

Then send:

Create result.txt with exactly one line: dsh-write-test-pass
Do not change any other file. Do not use web search or web fetch.

Inspect the workspace yourself:

TEST_ROOT="$HOME/dsh-safe-test"
cd "$TEST_ROOT/workspace"
ls -la
node -e "process.stdout.write(require('node:fs').readFileSync('result.txt','utf8'))"
node -e "process.stdout.write(require('node:fs').readFileSync('canary.txt','utf8'))"

The directory should contain only canary.txt and result.txt. The new file should contain dsh-write-test-pass, while the canary should remain unchanged.

workspace-write is still not a complete security boundary. In this release it restricts Bash and filesystem mutations to the selected workspace and temporary roots, but reads and network access are not confined. Process visibility also depends on the operating system's sandbox backend. That is why the controlled write belongs in a VM that contains no host secrets, even when the workspace is disposable. Review the permission behavior in the CLI reference.

Do not use sdk-minimal for the first safety test

The name sounds restricted, but sdk-minimal describes a smaller feature composition, not a tighter security mode. The 0.1.5-rc.1 CLI reference says this profile pins danger-full-access and omits the approval and permission-settings services. Use the base-backed Web profile for the procedure above.

If you later test the Python SDK, give it a fresh Harness home and disposable workspace. Do not assume the Web session's permission choice carries over to sdk-minimal.

Decide whether the installation passed

Keep the installation only if every check below passes:

  • The command and UI report the version you pinned.
  • The Web UI is reachable only at a loopback address inside the isolated environment.
  • Harness state appears under the test DSH_HOME, not an existing home directory.
  • The first session starts in Read only.
  • The denied mutation leaves canary.txt unchanged.
  • The controlled write creates only result.txt inside the disposable workspace.
  • No third-party plugin, MCP server, host folder, or production credential was exposed during the test.

Stop the server with Ctrl+C. Revoke the test API key if you created it only for this run, then delete the VM or roll it back to the pre-install snapshot. Move to a real repository only after repeating the same checks with a reviewed Harness version, a current backup, and the least permission that the intended task requires.

Next: use How to Find, Install, and Audit AI Agent Skills before adding third-party extensions, and apply human approval gates before granting consequential permissions.