Introduction¶

DSH’s configuration is scattered across several locations: the plugin manifest and bundle list for profiles are in ~/.dsh/profiles/<profile>/package.json, models, MCP servers, and panel configurations defined by each plugin are in ~/.dsh/profiles/<profile>/cordis.patch.yml, skills are in ~/.dsh/skills/ and ~/.agents/skills/, and plugin states are in ~/.dsh/<plugin>/. These locations are prone to being lost: reinstallation, changing machines, accidental deletion—any one of these is enough to make you rebuild from scratch.

The existing approach is dsh export, which copies the configuration into a single file. After that, you have to manage where to move it, what changes you made before moving, etc. The dsh-settings-sync introduced below turns this action into continuous synchronization: a private Git repository you own, a button for each direction, and a complete diff view before committing.

What is it¶

dsh-settings-sync is a DeepSeek Harness plugin maintained by elfgzp. It collects DSH profile configurations, plugin settings, skills, the list of installed plugins, and MCP server definitions into a snapshot, pushes it to a private Git repository of your choice, and can also pull it back and restore it. It is not an incremental backup tool and does not maintain its own storage format—the snapshot itself is just a normal Git repository.

Sync Scope¶

The snapshot contains these files:

manifest.json                 what the snapshot is generated from and when
profile/package.json          plugin manifest and bundle list
profile/cordis.patch.yml      configuration for each plugin
profile/cordis.yml            root entry list for the profile
profile/pnpm-workspace.yaml   workspace and release age
homes/dsh/<plugin>/*.json     plugin-level settings (favorites, default projects, tasks)
homes/dsh/skills/<name>/…     user-level skills under $DSH_HOME
homes/agents/skills/<name>/…  shared skills under $DSH_AGENTS_HOME

Intentionally excluded:

• Credentials. ~/.dsh/.credentials.yaml, tencent-intranet-auth.json, .env, *.pem, *.token, pairing.json are excluded by both filename and content. Additionally, if plaintext values appear in configurations already included in synchronization (e.g., the apiKey: line in cordis.patch.yml), they will be replaced with <redacted by dsh-settings-sync> before the snapshot leaves the machine. The configuration structure is preserved, so when restoring, you know a key is needed there and can fill it in yourself.
• Dependencies and Cache. node_modules, pnpm-lock.yaml, __pycache__, .plugin-manager logs, attachment files.
• Sessions and History. ~/.dsh/sessions, ~/.dsh/storages. History is not configuration, and it is the largest chunk in the DSH home directory.
• Old edits backups. Any files in profile matching .bak.

README gives an order of magnitude for a real machine: 21 installed plugins, 66 skills, 6 plugin-level state directories, resulting in 263 files and 1.4 MB.

Installation and Activation¶

The approach in the README is to first put the repository in a local path, e.g., ~/Work/Github/dsh-settings-sync. Then install it in DSH via Settings → Plugins → Install, or run in the terminal:

dsh plugin install ~/Work/Github/dsh-settings-sync

The prerequisite is that git is in PATH (if not, fill in the absolute path in the plugin configuration); only the “Create private repo” button requires a logged-in GitHub CLI, meaning you need to authenticate first using gh auth login.

After the plugin is installed, a new Settings Sync page appears under Settings. On first launch, a question pops up: pull configuration from the remote, or push the configuration of this machine up.

Typical Usage¶

1. Set repository. Paste an empty private repository address, both git@github.com:you/dsh-settings.git and https://github.com/you/dsh-settings.git work; you can also click Create private repo and let gh build one for you.
2. Push to upload the configuration of this machine.
3. On another machine, install the plugin, paste the same address, and click Pull.

Before confirming, the diff panel will fully display what the push will change: +added, ~modified, -removed. Review them before confirming.

Auto Sync¶

Security Model¶

• No restore point means no overwrite. Pull will first copy the current state completely to <stateDir>/backups/<timestamp>-snapshot/, and after the pull ends, it will report this path. Restore points are listed on the settings page and can be restored with one click.
• Pushes with nothing to collect are rejected. An error in HOME resolution looks like “the user deleted everything”, and silently replacing a good backup with an empty snapshot is irreversible. Similarly, a push that would delete most tracked files will be rejected unless explicitly forced.
• Snapshot is a real Git repository located in <stateDir>/mirror. History is the backup: running git log there shows every sync, and git show <commit>:profile/cordis.patch.yml gets the old file for any commit. Therefore, the plugin does not need its own undo format.
• Push and pull run serially. Only one operation runs at a time, controlled by a busy flag. Clicking again will wait rather than queue up; auto-triggered pulls during a running pull will be skipped.
• Authentication uses your own. The plugin does not save tokens; it executes the git you usually run, so osxkeychain, SSH agent, or credential.helper work as normal. Conversely, it is honest: if git push in the terminal doesn’t work for that repository, it won’t work here either, and the error message will explain it directly.

All state is stored by default under $DSH_HOME/settings-sync:

config.json   repository, branch, policies, commit identity
mirror/       local clone, its history is the snapshot history
backups/      restore points
last-run.json result of the most recent push or pull

Development and Verification¶

Checks included in the repository:

pnpm test    # equivalent to node --test test/*.test.js
pnpm check   # runs node --check on each module

Tests use the real git binary directly, setting up a fake profile, two skill roots, plugin-level state directories, a credential that is forbidden from synchronization, and a bare repository representing the remote in a temporary home directory. There is no mock git because the most error-prone layer is the git layer. engines requires node >=20.

Suitable Scenarios and Notes¶

Suitable for people who want to take their DSH environment with them and don’t want to write scripts to maintain backups themselves: one machine pushes, another pulls, and configuration differences can be read before pressing the button. Also suitable for treating a private repository as a feed source, allowing the same profile configuration to run on different machines in a team.

Points to note:

• Credentials are never synchronized; after changing machines, API keys need to be filled in again. This is both a limitation and a design intention.
• The plugin runs with the permissions of the current DSH process and can read and write all paths it can access. Before installing, you should open the source code and take a look to confirm the directory exclusion logic fits your environment and verify the license (MIT).
• Snapshots save configuration, not session history or dependency cache; dependencies still need to be reinstalled after restoring.

The plugin is categorized as admin-security in the SkillHub community directory. It should be noted that SkillHub is an independent site with no official affiliation with DeepSeek / Hypersphere, and is not an official app store.

Conclusion¶

DSH’s philosophy is “everything is a plugin,” and configuration is no exception worth writing into your own repository. The capabilities mentioned above come from the descriptions in the README and package.json, and whether it fits you depends on your backup habits and familiarity with Git.

• Directory page: https://www.skillhub.cn/plugins/elfgzp/dsh-settings-sync
• GitHub: https://github.com/elfgzp/dsh-settings-sync