dsh-tensorlake-sandbox

一句话定位

把 DSH 的文件、子进程、Bash、终端、LSP 操作统一搬到一台短命的 Tensorlake 远程 Linux 沙箱里执行，本机不再触碰任何宿主机文件或进程，适合想让 AI 完全跑在云端隔离环境的用户。

核心能力

• 在 dsh profile 启动时立刻创建一台 Tensorlake 远程沙箱（Linux microVM），DSH 退出时自动销毁，沙箱 ID 会在创建与销毁两行日志里对应打印
• 替换宿主机的文件和进程执行层：Bash、文件读写、子进程启动、交互终端都改在沙箱内运行，模型和工具看到的路径都是同一个远程 Linux 工作目录
• 提供原子的远程文件读写能力：写入采用临时目录 + 替换/硬链接的原子发布模式，避免半成品覆盖；支持 NUL 终止的 stat / find / base64 控制脚本读取元数据
• 复刻完整的进程与终端语义：包括子进程派生的进程组、POSIX session、PTY 终端、流式 stdout/stderr、信号转发（TERM/KILL）、进程组退出码与信号名识别
• 拒绝把 DSH_* 前缀和凭证形态的环境变量透传到沙箱进程，显式覆盖也只能通过调用方自己注入；并在沙箱启动前自动校验 cwd 可写、必要时通过 sudo 提权并把所有权交还给镜像用户
• 将 sandbox 策略固定为 danger-full-access 并把审批策略固定为 never，同时让权限预设只暴露 danger-full-access，避免出现「宿主受限、沙箱全开」的口径不一致

技术实现

• 语言: TypeScript（ESM，编译产出 tsdown）
• 关键依赖: [email protected]（远程沙箱 SDK） / @deepseek-ai/cordis（插件服务容器） / @deepseek-ai/dsh-fs 与 @deepseek-ai/dsh-subprocess（宿主定义的文件与进程能力接口） / @deepseek-ai/schemastery（配置 Schema）
• 架构模式: 通过 cordis.patch.yml 关停宿主 subprocess / fs-sandbox，固定 sandbox-policy / approval / permission 三段策略，然后插入 tensorlake-runtime / tensorlake-subprocess / tensorlake-filesystem 三个 Cordis 服务，所有 layer 共享同一个 SDK handle（ctx.tensorlake.getSandbox()）
• 入口文件: src/runtime.ts（共享沙箱所有者，含 SDK 创建与代理就绪重试） / src/filesystem/index.ts（远程文件系统 provider） / src/subprocess/index.ts（远程子进程与终端 provider）

适用场景

想在「完全不让 AI 触碰本机文件或进程」的前提下使用 DSH 的用户，例如把构建、测试、脚本运行统一丢到一台远程临时机器里；也适合在共享 CI 或评测环境里跑 DSH，需要确保每次任务都从一张干净的 Linux 镜像开始、结束不留痕迹。

前置依赖与兼容性

安装方式

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

配置项

沙箱权限预设与审批策略由本插件固定为 danger-full-access + never，不接受其他组合；想自定义须自行重写 profile 里的 sandbox-policy / approval / permission 三个 layer 整段配置。

常见问题

Q: 装好后跑一次任务，看到沙箱 ID 日志有什么意义？

A: 启动日志会打印一行 Tensorlake sandbox created: <sandbox-id>，DSH 退出时再打印一行 Tensorlake sandbox terminated: <sandbox-id>，两个 ID 一致说明沙箱正常创建并被回收；如果只在创建行出现，说明销毁失败，可结合上游日志排查。

Q: 我能在本机硬盘上读写文件吗？

A: 不能。文件操作全部发生在沙箱内的 Linux 路径（默认 /home/tl-user/workspace），模型和工具看到的都是这个远程路径；要换工作目录请用 DSH_TENSORLAKE_CWD 环境变量同时覆盖运行时 cwd 与沙箱策略工作目录，避免策略和实际执行层错位。

Q: 我能改权限预设吗？

A: 插件固定启用 danger-full-access 沙箱 + never 审批策略，并把权限预设仅暴露为 danger-full-access。cordis.patch.yml 是一次性替换，要改必须把 sandbox-policy、approval、permission 三段都重写，否则会被覆盖回默认值。

Q: 默认沙箱配置是什么？想调大内存或 CPU 怎么改？

A: 默认只设置 600 秒闲置超时，CPU / 内存 / 磁盘沿用 Tensorlake 服务端默认值。在 profile 的 cordis.patch.yml 里覆盖 tensorlake-runtime 的 cpus / memoryMb / diskMb 即可，注意 timeoutSecs 必须是正整数，且与 cwd 一样要保证是正数有限值。

Q: 凭证会进沙箱吗？安全吗？

A: 包代码不会把 TENSORLAKE_API_KEY、DEEPSEEK_API_KEY、其他凭证形态的环境变量或 DSH_* 变量自动透传到沙箱进程；显式注入只能通过 DSH 的工具或服务调用另行发起。沙箱本身是远程隔离的 microVM，但仍需自行评估 Tensorlake SDK 传递依赖的 npm audit 报告再投入生产。

Q: 卸载会影响 DSH 本身吗？

A: 不会。卸载插件只是把被它替换的 layer 还原，DSH 安装目录不会被修改；如需清理只需移除插件并重启 dsh，无需额外命令。

上手难度

进阶 — 需要 Tensorlake 平台账号、API Key 与一定的 sandbox 资源调配意识，普通用户首次配置容易卡在凭证和环境变量上；理解 DSH profile 的 cordis.patch.yml 替换语义后才能自定义。

已知问题与限制

• [email protected]（当前 SDK 版本）传递依赖 [email protected] 与 [email protected]，npm audit --omit=dev 会报告高危漏洞；上游暂未发布 audit-clean 的 Tensorlake SDK，生产环境使用前请审阅相关安全公告，并在 Tensorlake 发布新版本后及时升级
• 源码中存在两处待办事项：src/subprocess/remote.ts:29 的进程组信号目前通过 bash 内置 kill 实现，存在 PGID 复用竞态，未来需等待 daemon-native 的进程组信号接口；src/runtime.ts:323 的沙箱初始化回滚暂未做双失败重试，仅依赖 Tensorlake 自带的超时清理
• 沙箱权限策略与审批策略被插件固定为 danger-full-access + never，仅适合「完全信任沙箱边界」的使用场景；如果宿主本身在用 workspace-write 等受限模式，安装本插件会被强制切换为全访问模式，请提前确认这是否符合预期

@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.