Preface¶

After using DeepSeek Harness (DSH) for a while, a significant amount of assets accumulates locally under ~/.dsh: custom-written skills, historical sessions, profile configurations, global settings, and memory data. When switching machines or reinstalling, these files are scattered across different directories, making it easy to miss some when manually gathering and copying them. If you want to send a few skills to others, you are unsure if the files contain local paths or secrets.

dsh-packer targets these two issues: it packages local DSH assets into standard zip files by module. It covers migration (moving the entire environment) and sharing (only giving what is necessary) in a single pipeline, with privacy scanning before packing running through both scenarios.

What is it¶

dsh-packer is the “Agent Configuration Packer” plugin for DSH, maintained by KLRSL, under the MIT license, current version v0.2.2 (2026-09-05). The philosophy of DSH is “everything is a plugin,” where plugins are installed into a profile via the dsh plugin command; this plugin also follows the same mechanism.

Its capabilities are divided into three parts: modular packing, preview verification before and after packing/restoring, and privacy security scanning; all can be enabled on demand. The following sections introduce them separately.

Core Features¶

Modular Packing & Dual Mode Presets¶

Combinations of any six modules:

Two preset modes:

1. migrate (Migration): All modules selected by default, suitable for moving the entire environment.
2. share (Share): Only skills checked; sessions and memory are automatically excluded, and personal skill subdirectories _shared are also excluded to minimize sensitive content in the package.

Privacy Security Scanning¶

Scans text files before packing. Rules include: local absolute paths, user directory paths, suspected keys/tokens (assignments of api_key, secret, password, token, bearer, authorization, etc.), personal nicknames, and Windows username paths.

Interception strategy differs by mode: In share mode, hitting any rule results in an error, forced interception, and no package generation. In migrate mode, it only reports without intercepting. You can use /pack scan or --dry-run first to see hit points and decide for yourself.

Additionally, .credentials.yaml and .anonymous-user-id never enter the package—skipped when iterating any module, regardless of migration or sharing.

Previewability of Packing and Restoring¶

A file-level manifest can be previewed before packing. The --dry-run mode does not generate a zip. Before restoring, a difference report is generated first, listing files as Added/Changed/Identical/Skipped, which can be confirmed before applying.

Restore Conflict Strategy¶

Three choices for conflict files: overwrite (overwrite), skip (skip), merge (text append, does not overwrite existing content). Note that structured configurations like JSON/YAML do not support merge—appending will corrupt them, so use overwrite or manual merging for these files.

Manifest Integrity & Path Safety¶

The package manifest manifest.json records schemaVersion and the SHA-256 fingerprint of each file. A fail-closed verification is performed before restoring; if any item does not match, the entire operation is rejected, and no files are applied. The restore path also performs containment checks; ../ out-of-bounds via zip-slip or tampered manifests is strictly rejected.

Package Management¶

Package lists display creation time, size, included modules, and notes. Supports deletion and renaming. Notes can be filled in when packing. Shared packages automatically generate a README.md explaining the package contents.

Interface and Implementation¶

1. The settings page provides a “Configuration Packing” tab (module selection/preset switching/preview/pack/restore/package management), equivalent to the /pack command.
2. The packing workflow panel adapts to dark mode following the DSH theme (using --dsw-alias-* variables, dual-channel detection).
3. Zero native npm dependencies: Uses the system bsdtar (libarchive) to generate standard zip files, which can be opened by any extraction tool. Windows 10+ comes with tar.exe (which is bsdtar), and macOS’s tar is also bsdtar.

Installation and Enablement¶

Install from GitHub, requires git on the machine:

dsh plugin --profile web add github:KLRSL/dsh-packer

--profile web here is an example, change it to your own profile name. Restart DSH after installation.

For local development, you can link directly:

dsh plugin --profile web add link:./dsh-packer

Environment requirements:

Node.js ≥ 22.19.0
DSH dependency ≥ 0.1.1-rc.2 (v0.2.2 is adapted and tested with 0.1.2-rc.1)
peer dependencies: @deepseek-ai/cordis ^4.0.2, @deepseek-ai/dsh-tools ≥0.1.1-rc.2, @deepseek-ai/dsh-session ≥0.1.1-rc.2

Verify after installation, choose one:

1. Open the “Configuration Packing” tab in the settings page; seeing the module selection interface means installation was successful.
2. Run /pack list, returning a package list (empty for the first time) means the command is registered.
3. Run /pack create --dry-run to preview the file manifest and scan results, confirming that paths for each module are readable.

Typical Usage¶

First, do a preview to confirm what to pack:

/pack create --mode migrate --dry-run

This step does not generate a zip, only outputs the file manifest and scan results. After confirming, create a migration package, defaulting to all modules selected:

/pack create --note "迁移到新机器"

Or create a share package containing only Skills:

/pack create --share --note "分享给朋友"

The packing result is written to ~/.dsh/packs/.

When restoring, first import the package and view the difference report:

/pack restore ~/.dsh/packs/dsh-packer-2026-09-05-223045-migrate.zip

Then specify the conflict strategy to apply:

/pack restore <zip路径> --strategy merge

Strategy values are overwrite | skip | merge.

The other two common commands:

/pack list    # List existing packages: time/size/modules/notes
/pack scan    # Privacy scan for all packable modules

The output location is controlled by three environment variables, all with default values:

Scenarios and Notes¶

Suitable for two types of people: those who need to switch machines or reinstall and want to move the entire DSH environment; and those who want to share skills with others without manually checking for sensitive content. For personal backup, the migrate mode is fine (only reports privacy hits), but do not send these packages to others.

A few notes:

1. The share mode is strictly intentional; hitting any privacy rule will block it. Run /pack scan first to see which files hit, clean them up, then pack.
2. When restoring structured configurations like JSON/YAML, do not use merge; choose overwrite or manual merging.
3. If manifest verification fails during restore, it means the package is missing a manifest, version incompatibility, or has been tampered with. Re-generate or re-distribute the original package; do not manually unzip and modify zip content.
4. The plugin runs with the permissions of the current dsh process and can read/write files under ~/.dsh. Before installing any third-party plugin, it is recommended to check its source code and license (this project is MIT).

Summary¶

With the steps above, the migration and sharing of DSH local configurations can be consolidated into a single command pipeline: --dry-run preview, /pack create pack, /pack restore verify and restore, with privacy scanning strictly enforced in sharing scenarios. If you are maintaining DSH environments on multiple machines or frequently sending skills to others, give it a try.

Repository: https://github.com/KLRSL/dsh-packer