Lesson 2: What Can Plugins Actually Do?

In one sentence: From "give the model a tool that queries CSV" to "reskin the whole interface as QQ2006" to "run dsh on an Android phone" — if it is part of DSH, a plugin can change it. This lesson uses 275 real ecosystem plugins to map the practical boundaries.

1. First, the Size of the Plate

As of August 2026 the dsh-external org holds 275 catalogued plugin repositories (this site's Plugins page is exactly that list). By tag, the densest directions are:

One pattern stands out: interface plugins dominate. That is because the DSH web interface is itself assembled from dozens of UI plugins, so adding or swapping one piece is extremely cheap.

Below are seven categories organized by "what you want to change", each with real repositories.

2. Seven Kinds of Change, With Real Examples

2.1 Give the Model New Hands: Tools

Out of the box the model can read/write files, run commands, and search the web. You can give it any new ability:

This is the most common and most approachable category — Lesson 3 walks you through writing one.

2.2 Change What You See

The DSH web interface is stitched from dozens of ui-* plugins, so inserting things is easy:

2.3 Change How the Model Thinks and Collaborates

Not just "swap the model" — change the way it works:

2.4 Change Memory and Sessions

2.5 Use It Somewhere Else

DSH does not have to live in your terminal:

2.6 Purely for Fun

Fifteen repositories fall here, which says a lot about how low the barrier is:

2.7 Replace the Parts Underneath

This category best demonstrates "there is no core" — swapping the execution substrate itself:

• Swap the command execution backend (local / sandboxed / PowerShell / remote sandbox)
• Swap session storage (JSONL / SQLite / relational database)
• Swap the sandbox implementation (bwrap / Landlock / Seatbelt / microsandbox)
• Swap the subagent driver (in-process / ACP / Codex / Claude Code)

These ship in the official repository; switching is a one-line config change.

3. So What Is Not Possible?

Stating boundaries is more useful than advertising capabilities.

① Plugins cannot change "the laws of physics." Protocol constants, external API specs, and security invariants stay fixed — you cannot make a sandbox-denied file operation "slip through". A denial is a policy outcome, not a bug.

② Some capabilities are opt-in by design. The clearest case is the self-referential toolset tool-cordis, which lets the model mount new plugins into itself at runtime. The official stance is explicit:

This toolset requires explicit enabling, with the same deliberation as granting the bash tool.

The reason is blunt: plugin code written by the model really does enter the process you are running. Not shipping it by default is the right call.

③ Plugins are not fully isolated from each other. Two plugins competing for the same slot conflict — for example, both wanting to be the sole session-title generator. DSH's answer is to fail loudly at load rather than silently letting the later one win. This is "misconfiguration fails loud", and it is a feature: failing early beats behaving strangely halfway through a run.

④ Not everything deserves to be a plugin. There is an official rule — prefer maintained dependencies over hand-rolling — when a mature library genuinely deletes code and tests you would otherwise own.

4. Finding and Installing

Finding:

• This site's Plugins page — 275 repositories filterable by category
• dsh-hub / dsh-plus — community-curated shortlists
• marisa (aka dshx) — an external plugin manager that auto-discovers by GitHub topic

Installing: most plugin READMEs give you a one-liner. The official route adds it to a profile:

dsh plugin --profile web add <package or local path>

After installing you will see its entry in cordis.yml; to drop it, delete that line — back to the rule from Lesson 1: if it installs, it uninstalls.

💡 A practical suggestion: start with "give the model a tool" plugins (for example the six zero-dependency utilities in dsh-toolkit). They do not touch the UI or the substrate, so the blast radius is smallest if something goes wrong.

Key Takeaways

1. 275 real plugins, densest in interface changes (76), model tools (35), and skills (18).
2. Seven directions of change: add tools, change the UI, change how the model collaborates, change memory and sessions, change where it runs, pure fun, and replace substrate parts.
3. Interface plugins dominate because the web UI is itself dozens of UI plugins, making the marginal cost tiny.
4. The boundaries are real: protocol and security invariants are fixed; the self-referential toolset is off by default; conflicts fail at load time.
5. Install and uninstall are both config changes — delete the line in cordis.yml and you are back where you started.

🚀 Next lesson: write one. Three steps, twenty lines of code.