Introduction

The plugin ecosystem of DeepSeek Harness (DSH) emphasizes modularity and security. When working with cross-directory projects, developers often face a dilemma: either grant the model danger-full-access permissions, which carries higher risk, or rely on cumbersome manual authorization workflows, which are inefficient. The dsh-codex-project plugin is inspired by Codex’s project handling model. It allows a workspace to mount an arbitrary number of shared subdirectories (including across drive letters) while consistently maintaining workspace-write permissions, without needing to escalate to danger-full-access.

Core Features

The plugin provides the following capabilities:

  • Shared subdirectory configuration: Supports mounting across drive letters and supports bare directories that are not registered workspaces.
  • GUI interaction: Provides an “Edit Workspace” dialog, a “Project Folders” sidebar tab, and an “Open Local Directory” entry point.
  • Runtime security: Uses a multi-root sandbox runner and multi-root fs fence to ensure that read/write access to subdirectories remains within workspace-write boundaries.
  • Context management: Provides session context reminders, folding and listing the shared directory manifest during model inference.
  • Management and persistence: Supports CRUD operations on configuration and persists the data storage.
  • Interactive tools: Provides the add_dir model tool and the /adddir command, allowing both users and the model to actively add directories.

How It Works

The plugin hooks into the DSH runtime loop through hooks provided by Cordis (DSH’s IoC framework), without modifying source code.

  1. HTTP routing bridge: On startup, it mounts the /codex-project/api route. The client calls it via fetch, while the host handles configuration CRUD and file read/write operations.
  2. Context injection: It listens for the agent/pre-step event and, based on the configuration matched by the current session, generates a <system-reminder> message that informs the model of the set of writable directories.
  3. Tool registration: It registers the add_dir model tool. The model can invoke this tool to request adding a directory, which takes effect after user confirmation.
  4. Sandbox wrapping: It wraps the sandbox.confine method. When no shared directory is present, it passes through unchanged; when multiple root directories are involved, it uses runner.js to create a restricted token (Windows ACL + space-level SID) and executes the subprocess under that token.
  5. FS isolation: Through the ctx.fs provider (bundle patch), it replaces the core fs-sandbox. Within the process, fs fence allows or denies operations based on the set of writable roots.

Usage

1. Add or remove directories via the GUI

In the “Project Folders” tab in the sidebar or the “Edit Workspace” dialog in the workspace menu, you can view the current primary root and shared subdirectory list. Click the “Add” or “Remove” button and select the target directory to complete the configuration. Using “Set as Primary” changes the directory’s ordering and labeling in context reminders.

2. Add a directory via the command line

Type /adddir in the composer and press Enter. The system opens a native directory chooser. After selecting a directory, it is directly added to the current session workspace’s additional writable set.

3. Add a directory via the model tool

During inference, the model can invoke the add_dir tool to request adding a directory. A confirmation dialog will appear. After user approval, the directory is written to the SQLite database and takes effect immediately.

Security and Notes

  • No permission escalation: The plugin consistently maintains workspace-write permissions. It uses Windows ACL restricted tokens and space-level SID to isolate permissions among different root directories. Deny lists and space-level SID write authorization prevent out-of-bounds access to other directories.
  • Handling of invalid roots: If a shared subdirectory in the configuration is physically deleted (invalidated), the writable set is automatically narrowed to only the existing roots. The plugin does not automatically clean up invalid records, but it marks the entry with (⚠ directory missing) in context reminders.
  • Root directory conflicts: The same directory cannot simultaneously be the path of two records. If the session’s cwd falls under a conflicting directory, the earlier matching record in the configuration file takes precedence.
  • No read-only sharing: In the current version, all roots are granted read/write access, and read-only sharing is not supported.

Configuration and Data

Configuration is stored by default in a SQLite database: ~/.dsh-codex-project/dirs.db. The environment variable DSH_CODEX_PROJECT_CONFIG can override this path.

The logical model of the workspaces table is as follows:

{
  "workspaces": {
    "<workspaceId>": {
      "path": "主根（该工作区自身的路径）",
      "dirs": ["共享子目录1", "共享子目录2"],
      "primary": "展示层主要根（可选）"
    }
  }
}

Source and Documentation

  • GitHub repository: https://github.com/luoxunhao/dsh-codex-project
  • Community directory: https://www.skillhub.cn/plugins/luoxunhao/dsh-codex-project
  • License: MIT