dsh-profile-share
English | 简体中文
Share a DSH plugin setup as one pasteable code.
dsh-profile-share packages the plugins you selected in a DSH profile — their enabled state and
your explicit configuration — into a single short code. Another machine pastes that code and ends
up with the same setup; subsequent codes carry only what changed. The same page then reports which
API keys, environment variables and logins each machine still has to supply for itself, because
credentials never travel in the code.
Features
- Export — pick plugins (all / none / invert), generate one
DSH-SHARE/1: code. Suspected
credential fields are stripped by default and every stripped path is listed.
- Apply — paste a code, preview the exact diff, then apply it. Only additions and updates by
default; nothing is disabled or removed unless you turn on full alignment.
- First-run configuration — one page listing the credentials a machine still needs, with the
secret fields writable there and login-only plugins linked to their own settings.
Requirements
- A DSH profile that mounts the
pluginManager and configEditor services (the desktop and web
profiles of DSH 0.2.x do). Endpoints answer 503 with an explicit message when either is absent.
- Node.js
^22.19.0 || >=24.0.0 for the host half.
- The receiving machine needs this plugin installed too; a share code alone cannot bootstrap it.
Installation
dsh plugin add https://github.com/sldmn233/dsh-profile-share
Or, from the plugin manager, install this checkout as a local directory. Restart DSH once after
installing. The page lives in Settings → 分享与同步 (section id profile-sync).
Usage
1. Export a code
Open Settings → 分享与同步 → 分享, tick the plugins you want to carry over, and press
生成分享码. The result is one line of text; copy it and send it however you like.
2. Apply a code
On the other machine open the 同步 tab, paste the code, press 预览, and read the plan:
installations, enable/disable switches, and configuration writes. Press 应用 to run it.
3. Finish credentials
Open 首次配置. Every detected requirement is listed as a secret, an environment variable, or a
login. Fill in your own values — the sender's keys were never in the code.
The page never shows a bare input box. Every item carries what the plugin can actually prove:
- the provider's application page, matched from the environment variable name, the configured base
URL, the row id or the bundle name (DeepSeek, 阿里云百炼, OpenAI, Anthropic, Google, Moonshot,
智谱, MiniMax, 硅基流动, OpenRouter, 火山方舟, Groq, WorkBuddy);
- a copyable
setx / export command for environment variables, so the value does not depend on
remembering the syntax;
- the field's own description from the plugin's config schema, when it documents itself.
Requirements that match a flow registered through ctx.authorization also get a 直接授权
button. The flow runs in the background: its links and its questions come back to this page, and
whatever it commits is the plugin's own credential record — not this plugin guessing at a config
field. Flows that ask for a secret are never answered from chat; the agent tool refuses and points
at the page instead.
Bootstrap on a machine that does not have the plugin
A share code cannot install its own reader, so a handoff starts with one message. The 分享
tab's 复制引导语（含码） button copies exactly this:
帮我安装这个 DSH 插件：https://github.com/sldmn233/dsh-profile-share
装好后用 profile_share_import 导入下面这条分享码，先给我看计划，我确认后再用 apply=true 执行：
DSH-SHARE/1:…
The receiving agent reads it, asks whether to install the plugin — that is the confirmation step —
installs it through the plugin manager, calls profile_share_import for a preview, applies it once
you agree, and then reports what is still missing, which is the same list the 首次配置 page
shows.
Why the message instead of full automation: nothing in a bare DSH can recognise a DSH-SHARE/1:
string before the plugin that understands it is installed. A prefix detector in DSH core would
remove the message entirely; until then this two-line prompt is the seam.
Agent tools
| Tool | Purpose |
|---|
profile_share_import | preview a share code, or apply it with apply: true |
profile_share_requirements | list the credentials this profile still lacks, with the same guidance the page shows |
profile_share_authorize | list authorization flows, start one, read its prompts, answer a non-secret one, or cancel |
Share code format
The code is gzip(JSON) encoded as base64url behind a DSH-SHARE/1: prefix. The version suffix is
checked: a code from an incompatible format is rejected instead of being half-applied. The payload
holds the selected bundles (name, version, install spec, enabled state), the explicit profile
configuration of each row, and the sender's profile name and DSH version for the header.
How it works
The host half (index.js) uses only public services, so the Loader keeps owning schema validation,
the profile file lock and hot reload:
| Service call | Purpose |
|---|
pluginManager.listBundles() / listPlugins() | read the live inventory |
configEditor.configuration() | read each row's explicit profile override |
configEditor.edit() | write a row's configuration back through the profile patch |
installBundle() / setBundleEnabled() / setPluginEnabled() | install and switch |
Six endpoints live under /api/dsh-profile-sync/: state, export, preview, apply,
requirements, configure. Writes require application/json and a same-origin request, and reuse
the host's own connection.requestRejection admission decision.
The client half (client.js) is a single settings.section page registered through
ctx.slots.register, requires only react, and has no build step.
Security
- Suspected credentials (
apiKey, token, secret, password, cookie, …) are removed on export
by default, and the removed paths are reported. Enabling 包含可能的密钥字段 is an explicit,
deliberate action.
- The code carries
apiKeyEnv-style variable names, not the keys they name.
- Writes are same-origin only and go through the profile's own configuration editor, so every change
is a normal, reviewable profile patch.
Behavior notes
- Bundles provided by the DSH installation itself (
availability: 'installation') are never
installed; they ship with DSH. Their configuration overrides are still shared, because that is
what reproduces the setup.
- Bundles the sender has not installed are not shared and are reported as
stats.uninstalled.
- Registry sources install as declared;
git+… and file:… declarations pass through unchanged
rather than being guessed at as name@version.
- Full alignment is off by default: nothing is disabled or removed unless you ask for it.
Differences from similar plugins
wbb316/dsh-profile-sync moves a plugin set between
two profiles on one machine and deliberately installs nothing. This plugin targets the machine-to-
machine, person-to-person case: the code is self-contained and the receiving DSH installs and
enables the delta itself. Both exist on purpose.
Project layout
index.js Host half: six endpoints, snapshot codec, plan/apply engine
client.js Client half: the settings page (three tabs)
cordis.patch.yml Bundle patch inserting the row
locale/ Localized plugin title and description
test/local-smoke.mjs Offline harness driving the real handlers against mock services
Development
No build step, no runtime dependencies.
npm run check # syntax-check both halves
node test/local-smoke.mjs # run the offline harness
The harness covers export and secret stripping, idempotent replay, install → enable → write on an
empty profile, requirement detection, configure path allow-listing, cross-origin rejection,
installation-provided bundles never being scheduled for install, row-level enable sync, and route
registration collisions during a hot reload.
Contributing
Issues and pull requests are welcome: https://github.com/sldmn233/dsh-profile-share/issues.
License
MIT
