dsh-tensorlake-sandbox

One-Line Positioning

Move all DSH file, subprocess, Bash, terminal, and LSP operations to a short-lived Tensorlake remote Linux sandbox for execution—the local machine no longer touches any host files or processes, suitable for users who want AI to run entirely in a cloud isolated environment.

Core Capabilities

• When the dsh profile starts, immediately create a Tensorlake remote sandbox (Linux microVM); DSH automatically destroys it on exit, with the sandbox ID printed in both the creation and destruction log lines
• Replace the host's file and process execution layer: Bash, file read/write, subprocess spawning, and interactive terminals all run inside the sandbox; models and tools see the same remote Linux working directory for all paths
• Provide atomic remote file read/write capabilities: writes use a temporary directory + replace/hardlink atomic publish pattern to avoid half-finished overwrites; support NUL-terminated stat / find / base64 control script for reading metadata
• Replicate complete process and terminal semantics: including process groups from subprocess forking, POSIX sessions, PTY terminals, streaming stdout/stderr, signal forwarding (TERM/KILL), process group exit codes and signal name recognition
• Refuse to transparently pass environment variables with DSH_* prefix and credential forms into sandbox processes—explicit overrides can only be injected by the caller themselves; also validate that cwd is writable before sandbox startup, and use sudo escalation if necessary before transferring ownership back to the image user
• Lock sandbox policy to danger-full-access and approval policy to never, while exposing only danger-full-access in permission presets—avoid inconsistent messaging of "host restricted, sandbox fully open"

Technical Implementation

• Language: TypeScript (ESM, compiled output via tsdown)
• Key Dependencies: [email protected] (remote sandbox SDK) / @deepseek-ai/cordis (plugin service container) / @deepseek-ai/dsh-fs and @deepseek-ai/dsh-subprocess (host-defined file and process capability interfaces) / @deepseek-ai/schemastery (configuration Schema)
• Architecture Pattern: Use cordis.patch.yml to shut down host subprocess / fs-sandbox, lock the three-stage policies of sandbox-policy / approval / permission, then insert three Cordis services: tensorlake-runtime / tensorlake-subprocess / tensorlake-filesystem, with all layers sharing the same SDK handle (ctx.tensorlake.getSandbox())
• Entry Files: src/runtime.ts (shared sandbox owner, includes SDK creation and proxy readiness retry) / src/filesystem/index.ts (remote filesystem provider) / src/subprocess/index.ts (remote subprocess and terminal provider)

Use Cases

Users who want to use DSH without letting AI touch local files or processes at all—for example, consolidating build, test, and script execution into a single remote temporary machine; also suitable for running DSH in shared CI or evaluation environments, ensuring each task starts from a clean Linux image and leaves no trace on exit.

Prerequisites & Compatibility

Installation

dsh plugin --profile web add github:tensorlakeai/dsh-tensorlake-sandbox

Configuration Options

Sandbox permission presets and approval policies are locked by this plugin to danger-full-access + never and do not accept other combinations; to customize, you must rewrite the entire sandbox-policy / approval / permission layer configuration in the profile.

FAQ

Q: After installation, when I run a task and see the sandbox ID log, what's the significance?

A: The startup log prints Tensorlake sandbox created: <sandbox-id>, and when DSH exits it prints Tensorlake sandbox terminated: <sandbox-id>. Matching IDs indicate the sandbox was created normally and recovered; if only the creation line appears, destruction failed—check upstream logs for debugging.

Q: Can I read/write files on my local hard drive?

A: No. All file operations happen on Linux paths inside the sandbox (default /home/tl-user/workspace); models and tools see this remote path. To change the working directory, use the DSH_TENSORLAKE_CWD environment variable to simultaneously override runtime cwd and sandbox policy workspace directory, preventing policy and execution layer misalignment.

Q: Can I change the permission preset?

A: The plugin locks danger-full-access sandbox + never approval policy, and only exposes danger-full-access in permission presets. cordis.patch.yml is a one-time replacement—to change it, you must rewrite all three sections of sandbox-policy, approval, and permission, otherwise they'll be overwritten back to defaults.

Q: What's the default sandbox configuration? How do I increase memory or CPU?

A: Defaults only set a 600-second idle timeout; CPU/memory/disk use Tensorlake server defaults. Override cpus / memoryMb / diskMb of tensorlake-runtime in the profile's cordis.patch.yml. Note timeoutSecs must be a positive integer, and like cwd must be a positive finite value.

Q: Will credentials enter the sandbox? Is it safe?

A: The plugin code will not automatically pass TENSORLAKE_API_KEY, DEEPSEEK_API_KEY, other credential-form environment variables, or DSH_* variables into sandbox processes; explicit injection can only be done separately through DSH tools or service calls. The sandbox itself is a remote isolated microVM, but you should still evaluate the npm audit report for dependencies passed through the Tensorlake SDK before production use.

Q: Will uninstalling affect DSH itself?

A: No. Uninstalling the plugin just restores the layers it replaced; the DSH installation directory won't be modified. To clean up, just remove the plugin and restart dsh—no extra commands needed.

Difficulty Level

Advanced—requires a Tensorlake platform account, API key, and some awareness of sandbox resource allocation; first-time users may get stuck on credentials and environment variables. Customization requires understanding the cordis.patch.yml replacement semantics in DSH profiles.

Known Issues & Limitations

• [email protected] (current SDK version) has transitive dependencies on [email protected] and [email protected]; npm audit --omit=dev will report high-severity vulnerabilities; the upstream hasn't released an audit-clean Tensorlake SDK yet—please review relevant security advisories before production use and upgrade promptly when Tensorlake releases new versions
• Two TODOs exist in the source code: process group signaling at src/subprocess/remote:29 currently uses bash built-in kill, with potential PGID reuse race conditions—waiting for daemon-native's process group signal interface in the future; sandbox initialization rollback at src/runtime.ts:323 doesn't do dual-failure retry, relying only on Tensorlake's built-in timeout cleanup
• Sandbox permission policy and approval policy are locked by the plugin to danger-full-access + never, suitable only for "fully trust sandbox boundary" use cases; if the host itself uses restricted modes like workspace-write, installing this plugin will force switching to full-access mode—please confirm this is expected in advance

@tensorlakeai/dsh-sandbox moves DeepSeek Harness file, subprocess, Bash, terminal, and LSP operations into one short-lived Tensorlake microVM. It is an installable dsh bundle and does not require changes to the Harness installation.

Prerequisites

• Node.js ^22.19.0 or >=24.0.0
• @deepseek-ai/dsh 0.1.0-rc.6 or a later compatible release
• A Tensorlake project with TENSORLAKE_API_KEY set in the host environment
• DEEPSEEK_API_KEY set in the host environment for the default DeepSeek model provider

Keep credentials in environment variables or a secret manager; do not commit them to the profile or repository.

Install

Install dsh and add this 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"

During development, install a local checkout from its directory:

npm install
npm run build
dsh plugin --profile headless add .

Use dsh --profile headless --dump-config to verify that the @tensorlakeai/dsh-sandbox layer disables the host subprocess and fs-sandbox providers, inserts the Tensorlake runtime, subprocess, and filesystem rows, and keeps bash-sandbox mounted in danger-full-access mode. In that mode Harness's sandbox-aware Bash executor delegates directly to the Tensorlake subprocess provider while still satisfying the permission-preset capability contract.

Smoke test

Run one headless task that 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, the tl-user identity from id, and reads hello back from the file. The model-facing working directory is the same remote Linux path, so the response should not mention or fall back from a host-machine path.

Configuration

The bundle starts an ephemeral sandbox on profile boot and terminates it when dsh exits. The runtime module accepts these Cordis config fields:

Each run prints the sandbox ID at both lifecycle boundaries. The IDs should match:

Tensorlake sandbox created: <sandbox-id>
Tensorlake sandbox terminated: <sandbox-id>

The shipped bundle derives both the runtime cwd and policy workspace from DSH_TENSORLAKE_CWD. Prefer that single setting when changing the workspace so the Bash policy and remote providers cannot drift:

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

To configure the rows directly in the profile's cordis.patch.yml, override both together. A patch replaces the complete config, so restate every non-default field you need:

- id: sandbox-policy
  config:
    mode: danger-full-access
    workspaceRoot: /workspace/project

- id: tensorlake-runtime
  config:
    cwd: /workspace/project
    timeoutSecs: 1800
    cpus: 2
    memoryMb: 4096

apiKey is optional and should normally remain omitted. The package never copies TENSORLAKE_API_KEY, DEEPSEEK_API_KEY, other credential-shaped environment variables, or DSH_* variables into sandbox processes. A caller may still pass an explicit environment entry through a Harness tool or service request.

Runtime requirements

The Tensorlake image must provide bash, Node.js, and GNU base64, cat, chmod, env, find, grep, ln, mkdir, mktemp, mv, ps, realpath, rm, stat, and tee. The default managed Ubuntu image provides these tools. The runtime verifies that a configured cwd is writable and uses the managed image's passwordless sudo to create and hand off a protected path when necessary.

The package targets @deepseek-ai/dsh 0.1.0-rc.6 or later compatible release. The dsh installation supplies its optional Cordis, filesystem, subprocess, and Schemastery peers through the profile module fallback. The package uses only public ctx.fs and ctx.subprocess service definitions; no DeepSeek Harness source registration, generated catalogs, or in-repository configuration is required.

Known limitations

• [email protected], the current SDK release, pins [email protected] and [email protected]; npm audit --omit=dev reports high-severity advisories for those transitive versions. No audit-clean current Tensorlake SDK release is available, so review the upstream advisories before production use and update the SDK pin when Tensorlake publishes one.

Develop

npm install
npm run check
npm pack

The three Loader entry points are @tensorlakeai/dsh-sandbox/runtime, @tensorlakeai/dsh-sandbox/filesystem, and @tensorlakeai/dsh-sandbox/subprocess. Each module default-exports its service class; do not add function-plugin named exports to those modules because the Cordis Loader treats mixed export forms as a function-plugin namespace.