HomeBlogPricingCareersDocsGitHubSlack community
Field notes/Engineering/Run DeepSeek Harness in a Tensorlake Sandbox

Run DeepSeek Harness in a Tensorlake Sandbox

The @tensorlakeai/dsh-sandbox bundle moves DeepSeek Harness file, subprocess, Bash, terminal, and LSP operations into one short-lived Tensorlake microVM. No changes to the Harness installation.

SBX-01C4SBX-01E3SBX-0202SBX-0221SBX-0240SBX-025FSBX-027ESBX-029DSBX-02BCSBX-02DBSBX-02FASBX-0319SBX-0338SBX-0357SBX-0376[ RUNTIME: ACTIVE ] P50 2.45S · P99 4.12S · 5M/PROJECT

DeepSeek Harness (dsh) is DeepSeek's coding agent harness, and like every capable harness it wants to read files, spawn subprocesses, and run Bash. @tensorlakeai/dsh-sandbox is an installable dsh bundle that moves all of those operations, file, subprocess, Bash, terminal, and LSP, into one short-lived Tensorlake microVM. It requires no changes to the Harness installation itself.

Setup

Install dsh and add the bundle to the profile you run:

npm install --global @deepseek-ai/dsh
dsh plugin --profile headless add @tensorlakeai/dsh-sandbox
TENSORLAKE_API_KEY=... DEEPSEEK_API_KEY=... dsh --profile headless "build and test this repo"

The bundle starts an ephemeral sandbox when the profile boots and terminates it when dsh exits. Each run prints the sandbox ID at both lifecycle boundaries, so you can confirm the sandbox that was created is the one that got torn down.

A quick smoke test exercises both the subprocess and filesystem providers:

dsh --profile headless \
  "Use Bash to run pwd and id. Create smoke-test.txt containing hello, read it back, and report the results."

A successful run reports /home/tl-user/workspace from pwd and the tl-user identity from id. The model-facing working directory is the remote Linux path, so the agent never falls back to a host path.

How it replaces the host providers

Under the hood, the bundle disables the host subprocess and fs-sandbox providers and inserts Tensorlake runtime, subprocess, and filesystem rows in their place. Harness's sandbox-aware Bash executor then delegates directly to the Tensorlake subprocess provider while still satisfying dsh's permission-preset capability contract. You can verify the resulting layering with dsh --profile headless --dump-config.

Configuration goes through the runtime module: working directory (default /home/tl-user/workspace), inactivity timeout (default 600 seconds), and CPU, memory, and disk allocations. To change the workspace, prefer the single DSH_TENSORLAKE_CWD variable, which keeps the Bash policy and the remote providers pointed at the same path:

DSH_TENSORLAKE_CWD=/workspace/project dsh --profile headless "build and test this repo"

Credential hygiene

The bundle never copies TENSORLAKE_API_KEY, DEEPSEEK_API_KEY, other credential-shaped environment variables, or DSH_* variables into sandbox processes. The API key is used only by the host SDK to drive the sandbox. If a task genuinely needs a secret inside the sandbox, you pass it explicitly through a Harness tool or service request, so nothing leaks by default.

Requirements

You need Node.js 22.19 or newer, @deepseek-ai/dsh 0.1.0-rc.6 or a later compatible release, and a Tensorlake project with TENSORLAKE_API_KEY set. The default managed Ubuntu image provides everything the runtime needs; custom images must include bash, Node.js, and the standard GNU userland tools.

For the sandbox primitives underneath, suspend and resume, snapshots, and custom images, start with the Tensorlake docs. For how other harnesses plug in the same way, see Run OpenCode in a Tensorlake Sandbox.

TT
WRITTEN BYTensorlake TeamEngineering
Read next —FROM THE LOG
◆ THE SANDBOX DIGEST

Subscribe for release notes, benchmarks, deep dives.

One dispatch per month from the Tensorlake team — no spam.