Registers `list_profiles` and `export_profile`, so the agent can show what setups exist and hand back a whole profile — bundle order, plugin versions and patch — as one portable file to share. Read-only.
Install
# from GitHub (first run asks for allowBuilds approval — follow the hint, retry)
dsh plugin --profile web add github:asdf17128/dshp
Any plugin you install runs third-party code with your own permissions — it can read your files, use your credentials, and reach the network, and tool approvals don’t sandbox it. GitHub-sourced plugins also run build scripts at install time — pnpm blocks those until you allow them, so an install can stop with ERR_PNPM_GIT_DEP_PREPARE_NOT_ALLOWED or ERR_PNPM_IGNORED_BUILDS; dsh prints the exact key to add under allowBuilds in your profile’s pnpm-workspace.yaml, and the install works on the next run. Allowing a build is a trust decision: only install sources you trust, and pin a commit (github:owner/repo#sha).
README
Hand your whole dsh setup to someone as one file — and they get the exact same tree.
English | 中文
npx github:asdf17128/dshp ls
Shows every profile on your machine in one line each. Read-only, zero dependencies.
What it gives you
See what you actually have. dshp ls and dshp show answer "what is
installed, in what order, and did I patch it" without opening a single file.
Copy before you break it. dshp clone web web-test duplicates a working
setup in under a second, node_modules and all. Experiment on the copy; rm
it when done.
Share a setup that reproduces exactly. dshp export writes bundle order,
plugin versions and your patch into one short file. dshp import rebuilds it —
verified: a 132-entry profile reproduced into a fresh $DSH_HOME composes an
identical tree, patch included.
dsh itself can boot a profile and forward installs to pnpm, but it cannot create
an empty one, list what you have, or copy a working setup before you experiment
on it. That is all manual work under ~/.dsh/profiles today.
Share a setup
dshp export web -o my-setup.dshp
# dsh profile — reproduce with: dshp import <this-file>
dshp: 1
name: web
bundles:
- @deepseek-ai/dsh-base
- @deepseek-ai/dsh-web-app
- dsh-cloudflare-browser-run
plugins:
dsh-cloudflare-browser-run: "^0.1.1"
patch: |
- id: session-title
config:
fallbackMaxWords: 12
Short enough to paste into a forum post. On the other machine:
dshp import my-setup.dshp
That writes the profile, installs the plugins through dsh's own pnpm, and you boot it with dsh --profile web. Verified end-to-end: a fresh $DSH_HOME reproduced a 132-entry tree identical to the original, patch included.
Experiment safely
dshp clone web web-试验田 # instant, keeps node_modules
dsh plugin --profile web-试验田 add some-experimental-plugin
dshp diff web web-试验田
web -> web-试验田
plugins
+ some-experimental-plugin@^0.2.0
If it goes wrong, dshp rm web-试验田 --yes. Your working profile was never touched.
Commands
dshp ls |
profiles, with bundle/plugin counts and disk size |
dshp show <name> |
bundles in load order, plugins, patch |
dshp new <name> [--web|--headless] |
create a profile — dsh itself cannot make an empty one |
dshp clone <from> <to> |
copy a working setup, node_modules and all |
dshp export <name> [-o FILE] |
portable file (stdout by default) |
dshp import <file> [--as NAME] [--no-install] |
recreate a profile |
dshp diff <a> <b> |
what differs |
dshp rm <name> --yes |
delete |
What a profile actually is
Under $DSH_HOME/profiles/<name>:
package.json—dependenciesare the plugins,dsh.profile.bundlesis the ordered layer stackcordis.patch.yml— your own id-targeted overridescordis.yml,pnpm-workspace.yaml— boilerplate, regenerated
So three things reproduce a setup: plugin versions, bundle order, and the patch. That is exactly what the portable file carries.
Bundle order is part of the format: it decides which layer patches which, so a reordering is reported by diff as a real difference.
The patch block is copied byte-for-byte rather than re-serialised, because it may hold !!js expressions (root: !!js dshHomePath('sessions')) that a YAML round-trip would mangle or evaluate. Nothing here ever evaluates your config.
Install and uninstall
As a CLI: npx dshp ls — nothing to install.
As a plugin:
dsh plugin --profile web add github:asdf17128/dshp # install
dsh plugin --profile web remove dshp # uninstall
Removing it drops the list_profiles and export_profile tools. Your profiles
are untouched — the plugin only reads.
Compatibility
Verified against @deepseek-ai/dsh 0.1.0-rc.5. The profile layout it reads
(package.json with dsh.profile.bundles, cordis.patch.yml) is dsh's own; a
change there is what would break it first.
Requirements
Node 18+. import needs a working dsh (local node_modules/.bin/dsh preferred, otherwise on PATH) because it installs through dsh's own pnpm; every other command is pure filesystem work.
See also
dsh-doctor — checks a profile for patches that silently stopped applying.
License
MIT
Links
More in this category
yjh051108/dsh-routing-suite★ 6995
One repository, three parts: a runtime injector for DSH plugin packages (inject, hot-reload, unload, promote a dev staging tool to the front, route self-heal, plus a settings-page plugin manager that lists, unloads and drags folders in to internalize), a task-aware reasoning-mode router agent preset (router-standard / router-spec / router-react), and a graded two-level task protocol whose six tools (commit_star, lock_stage, revise_do, edit_plan, mark_task, redteam_verdict) pin task state to disk. The injector implementation ships in-tree, so the install carries its own behaviour rather than a dependency list.
strukto-ai/mirage#dsh★ 3667
Swaps the filesystem and bash providers for a mirage virtual workspace: file tools and shell commands run over mounted resources (RAM, S3, Redis, Slack, Gmail, Notion, Postgres) instead of the host disk, with per-mount read/write/exec modes, per-command sandbox routing (monty, pyodide, quickjs in process; docker, e2b, daytona remote), and installed CLIs (git, gh, slack, linear, ntn, gws, or one you register) as head words in the virtual terminal.
hust-open-atom-club/oh-dsh★ 325
Community distribution: TUI, desktop, and Web UI as one bundle with layered installation.
weijiafu14/pi2dsh★ 208
Pi Host ABI compatibility engine: after one install, unmodified Pi extensions from npm mount as native DSH plugins with `dsh plugin add <pi-package>`. Verified end to end on stock DSH with pi-mcp-adapter (full MCP manager: OAuth, resources, prompts, MCP Apps, elicitation, sampling), @tintinweb/pi-subagents, pi-code, pi-hermes-memory and pi-background-tasks; `pi2dsh inspect` reports a package's compatibility before installing.
lire1131/dsh-undo-savepoint★ 167
Undo/redo & rollback system for DSH: every config change is auto-snapshotted; undo/redo/restore to any version from the WebUI or the offline CLI/GUI tools (works even when DSH fails to boot).
Fishquito7/dsh-skill-mcp-panel★ 158
Manages DSH skills and MCP servers from the web settings: skill cards with hot enable/disable, workspace scopes, groups, batch migration and drag-and-drop import, plus stdio/HTTP MCP CRUD with connection tests, secret redaction and the unified dsh-panel CLI.
Community comments
Comments are public GitHub Discussions. Loading them connects to GitHub and Giscus; a GitHub account is required to post.