Introduction

DeepSeek Harness (DSH) provides a code execution interface ctx.codeRuntime for running programs in Code Mode. The built-in worker-thread backend runs within the agent process, with a trust posture equivalent to bash. For scenarios requiring strict isolation, this is insufficient. The dsh-code-runtime-container plugin provides a container-isolated backend implementation for this need. It runs programs in a fresh container and applies strict resource and permission restrictions.

Plugin Overview

This is a container-isolated backend for the DeepSeek Harness code execution interface. It is maintained by tancheng33. It addresses the insufficient isolation of the native backend and provides stronger execution boundaries using container technology.

Core Features

The plugin provides the following isolation capabilities through containers:

  • Network isolation: Uses --network=none to disable all network access.
  • Filesystem isolation: Uses a read-only root filesystem, preventing programs from writing to the host filesystem.
  • Resource limits: Enforces memory, CPU, and PID limits through the kernel to prevent resource exhaustion or Fork Bomb.
  • Permission control: By default uses --cap-drop=ALL and no-new-privileges, and runs as the nobody user.

Installation and Enablement

Before installation, ensure that a container engine (such as Docker, Podman, or Nerdctl) is installed on the host and that an available local image exists.

Run the following command to install the plugin:

dsh plugin --profile <name> add dsh-code-runtime-container

After installation, ensure that the container engine has an available image. For example, use the official Node.js image:

docker pull node:22-alpine

Configuration and Usage

The default configuration for this plugin is strict mode, intended to provide isolation capabilities. Configuration items are usually defined in a YAML file, for example:

- id: code-runtime-container
  config:
    workspacePath: /Users/me/projects/app
    workspaceReadOnly: true
  • workspacePath: If programs need to read project files, you can specify an absolute path and mount it to the container’s /workspace directory.
  • extraArgs: This parameter is used to pass additional docker run flags. Any misconfiguration (such as --network=host) may weaken all of the isolation policies above.

Use Cases and Considerations

This plugin is suitable for scenarios where untrusted code needs to be run in Code Mode. When using it, note the following:

  1. Security boundaries: The plugin does not protect against kernel or container runtime escapes, nor does it protect against Docker socket access. If an attacker can access the Docker socket, they may still be able to exploit host permissions.
  2. Trust posture: The design trust posture is equivalent to bash, meaning it assumes the runtime environment itself is secure.
  3. Error handling: Errors during program execution (such as timeouts or OOM) are returned as result fields rather than directly refusing execution.
  4. Tool isolation: The plugin only isolates code execution itself and does not isolate tool calls. If tool calls need to be restricted, it must be used with other plugins (such as dsh-egress-guard).

Conclusion

dsh-code-runtime-container provides container-level code execution isolation for DSH, complementing the isolation weaknesses of the native worker-thread backend. If you need to run untrusted code in Code Mode, this plugin provides stronger boundary control than the native environment. For more technical details and source code, please refer to the GitHub repository.