Introduction¶
DeepSeek Harness (DSH) stores project workspaces, multi-session chats, and attachments in the local data directory. After changing computers or reinstalling, these “memories” won’t follow you; if you copy the entire data directory over, you risk taking credentials, plugin configurations, and project code with you. The community also has sync plugins for hosting platforms like GitHub and Gitee, which are more suitable for automatic sync and multi-branch scenarios.
Below is an introduction to dsh-ownsync (maintainer Shengyis, npm package name dsh-ownsync): It uses a self-controlled bare Git repository as a transport channel, performing manual upload / download only. It syncs DSH workspace registrations, session logs, and attachments referenced in chats to another machine so you can continue chatting. The design does not include automatic sync or branch merging; the documentation requires that content be edited on only one computer at a time.
What is it?¶
dsh-ownsync is a “memory” type plugin in the DSH ecosystem: the sync scope is narrowed to the three types of data DSH itself needs, avoiding project repository code, settings.yaml, plugin manifests, and credentials, etc. The main branch on the server is always a snapshot-style commit of the current content, and the repository size will not expand infinitely with each upload.
What syncs, what doesn’t?¶
During upload, it scans the local data directory, writes to the local sync repository .ownsync/repo.git, and then pushes a root commit containing only the current content to the remote main.
| Category | Content |
|---|---|
| Workspace | storages/workspace.json: workspace list, titles, order, session ownership, archive status |
| Sessions | Highest generation logs for each session under sessions/** |
| Chat Attachments | Files referenced in the above session logs within attachments/** |
Not included in sync include: code and documentation in the project folder, settings.yaml, cordis.patch.yml, plugin manifests, credentials, cache, logs, AGENTS.md, skills/. Blank sessions with only a header and no events are also not synced.
The authoritative source is the server: whatever is on the server becomes what is on the local machine after download.
Core Mechanism¶
Server Side¶
Prepare a normal bare repository on your own machine, for example:
git init --bare /srv/git/dsh-sync.git
The README instructs not to set receive.denyNonFastForwards because each upload may correspond to a forced push.
Upload¶
- Scan the three types of sync content on the local machine;
- Write to
.ownsync/repo.git; - Generate a root commit containing only the current content and push it to
main.
Download¶
- Fetch
main; - Write back to the local machine (save originals to
.ownsync/backup/before overwriting); - Record the local baseline version;
- If sessions are written back, DSH will automatically restart to re-read the disk; if a session is in use, it will switch to a blank session first before restarting.
The plugin calls the git found in the system PATH (Git for Windows on Windows). If the git command is not found, you need to fully exit and reopen DSH after installation.
Interface and Status¶
There is a sync card in the bottom left of the sidebar (above the avatar): displaying local/server version numbers, last sync time, and Upload, Download, Check for Updates buttons; the gear icon opens settings (repository address, branch, two refresh intervals).
Local status refresh defaults to every 5 seconds and performs a local scan only; server auto-check defaults to every 10 seconds, executing git fetch. These intervals exist in the local browser and are not synced.
Common statuses include: unconfigured address, server not checked yet, connection failed, empty repository on server suggests upload, local not downloaded yet, local has unsynced changes, server version is newer suggests download, synced, etc. Buttons automatically enable or disable based on status; hovering over a disabled button may show the reason.
The “Sync” button is currently a placeholder; clicking it does nothing. “Restart” requires confirmation and is restricted by conditions such as running tasks, plugin installation, and within 5 seconds of a restart; automatic restart capability is mainly for the Windows desktop version; Web or other environments may only prompt for manual exit.
Installation and Enablement¶
The plugin is installed via npm (or a team private registry). The current package version is 1.1.0, license MIT, requires Node >= 24.
Inside DSH:
- Open DSH → Settings → Plugins;
- Enter package name
dsh-ownsyncand click Install; - Fully exit DSH and reopen.
Equivalent CLI commands:
# Web端
dsh plugin --profile web add dsh-ownsync
# Windows 桌面端
& "$env:LOCALAPPDATA\Programs\DeepSeek Harness\resources\runtime\cli\bin\dsh.cmd" plugin --profile desktop add dsh-ownsync
Upgrades can specify a version, e.g., dsh-ownsync@1.1.0, and require full exit and reopening after installation. If not using public npm, you need to configure the registry in the profile’s .npmrc, or add --registry <address> after the install command.
The plugin runs with the permissions of the current DSH process; it is recommended to read the GitHub repository source code and license before installing to determine if it suits your environment.
Typical Usage¶
1. Prepare Server and Credentials¶
git init --bare /srv/git/dsh-sync.git
The plugin does not pop up a login window. You need to establish git access locally first:
- SSH: Run
ssh-keygen, add the public key to the server, andssh -T user@hostshould work; - HTTPS: Run
git ls-remote <repository address>once in the terminal, enter username and token when prompted, and the system credential manager will save it.
2. Configure Repository Address¶
Click the settings gear in the DSH sidebar, enter the address (example: ssh://git@backup.example.com:2222/srv/git/dsh-sync.git), and save.
3. First Computer (Already has content)¶
Click Check for Updates. When the repository is empty, the status is “No content on server yet, suggests upload”. Click Upload to create v1 on the server.
4. New Computer¶
Install the plugin and enter the same address. Check for Updates → Download. It will back up to .ownsync/backup/ before overwriting. DSH will automatically restart after writing back sessions. The subsequent workflow for switching machines is fixed: Old machine Upload → New machine Check for Updates → Download.
Security Boundaries and Limitations¶
- Download overwrites the local machine; originals can be manually restored in
<Data Directory>/.ownsync/backup/<Time>/files/.... - When deleting too many synced files at once during upload, confirmation is required, and the server’s old version may be backed up to the local machine.
- Download requires confirmation if the local machine has unsynced changes; upload will be rejected if performed after the server has been modified by another endpoint, prompting you to download first (changes do not count
session/end-seedmarkers). - The server is just a transport channel, not a full backup solution; long-term backup still relies on the local data directory and
.ownsync/backup. - Upload will be rejected if a session is being generated; single file limit is 256 MiB, oversized attachments will be skipped and appear in the upload results.
- Scenarios like downloading and writing back sessions, or switching to a blank session when occupied will trigger an automatic restart (Windows desktop version is launched by an external helper; other platforms require manual restart as prompted).
This plugin is based on dsh-chatsync with modifications to remove hosting platform APIs, branch merging, and automatic sync, targeting self-hosted Git; if you need automatic sync and multi-branch on GitHub/Gitee, the documentation suggests using chatsync first.
Conclusion¶
dsh-ownsync converges DSH workspaces, sessions, and referenced attachments onto a Git channel you control, using a clear upload/download rhythm to switch computers and continue chatting, avoiding syncing irrelevant configurations and project code. See the plugin directory at SkillHub Item, and source code and changelog at GitHub: Shengyis/dsh-ownsync.