DSH Plugin market upgrade: compare permissions first

Browsing the DSH Plugin market, two DSH plugins can look alike and still ask the runtime for very different access. The difference usually sits in five permission fields, and reading them side by side explains more about fit than any feature paragraph.

DSH plugin permissions are scopes, not feature badges

A permission field tells you what a DSH plugin can reach, not what it promises to do.

Market descriptions are written to sell a workflow: summarize this, sync that, automate the other. A permission field is written for the runtime, which only cares whether a process may open a path, spawn a command, or call a service. Two plugins that both say "project assistant" can therefore arrive with one reading files and the other running shell commands. The label is marketing; the scope is engineering.

That distinction matters because permissions outlive intentions. A plugin may only touch the extra directory in an edge case, but the grant applies whenever the process runs. Once you accept the scope, you are trusting every future call path in that package, including the ones added in a minor release. Reading permissions is a way of asking what the worst realistic version of this plugin could do.

The practical habit is to treat each grant as a separate decision rather than a package-level yes or no. File access, command execution, network calls, cross-plugin service calls and background work carry different consequences. A plugin that needs one narrow directory is a smaller commitment than one that wants a shell.

Reading the permission fields of a DSH plugin

Each field answers a different question, and the answers should be read in the order that matches your risk.

Start with file scope, because it is the easiest field to verify and the most common source of surprise. Look for the exact roots a plugin reads or writes, and notice whether the list is narrow or recursive. A workspace-relative path is a very different request from a home directory or a drive root. When the field only says "files", treat it as unknown until you find the detail.

Command execution is the field that changes the category of risk for any DeepSeek Harness plugin. If a plugin can spawn processes, its effective reach is no longer limited to the paths it declares, since commands can do arbitrary work. Network access deserves similar attention: outbound requests can move data beyond the machine, and a new domain in the list is a new destination. Cross-plugin services and background activity complete the picture, because they let a plugin read other tools' data or keep working when no task is running.

The order is not arbitrary. File and command scopes bound what happens locally, network and cross-plugin scopes bound what leaves the session, and background scope bounds when it happens. Reading the fields in that order gives you a story you can compare across candidates instead of a checklist you forget by the next page.

Why similar DSH plugins request different scopes

Different implementations of the same feature can need different access, and the difference is often a design choice.

One plugin might read a project's configuration files directly, while another delegates to an existing tool and only asks for that tool's service. Both produce a similar result, but the first needs file access and the second needs a cross-plugin grant. Neither is automatically wrong; they are different bets about coupling.

Scope also grows with ambition. A plugin that only formats text needs almost nothing, while one that watches a directory, runs a build and posts a summary needs file, command, network and background access at once. When two candidates differ sharply in permissions, compare what the extra access buys. If the answer is a feature you will not use, the wider scope is pure cost.

Version history adds another reason for divergence. A plugin may have started narrow and accumulated grants as features were bolted on. Another may have been designed around a sandbox from day one and still achieve the same workflow. A permission diff between versions, not just between plugins, shows which pattern you are looking at.

A permission diff table for DSH plugin upgrades

Compare the five scopes before and after an upgrade, and mark every row as changed, unchanged or unknown.

The table below is deliberately small; it is meant to be filled in during a review, not read as documentation. Keep one column for the version you run and one for the version offered. Where a field is vague, write unknown rather than guessing, because unknown is the row that deserves investigation.

Filling the table takes a few minutes and usually changes the conversation. A row marked changed sends you to the release notes or the package metadata for an explanation. A row marked unknown sends you to the code. Rows that stay unchanged are the baseline that makes the other two meaningful.

Letting the permission difference choose a DSH plugin

When two candidates overlap in features, the smaller defensible scope is the better default.

Selection is easier once permissions are on the table. If candidate A needs a directory and candidate B needs a shell, the burden of proof sits with B. That does not make B wrong, but it does mean B should offer something A cannot do, not merely the same task with more machinery.

The numbered pass below turns that idea into a decision you can record. It works for a first choice and for an upgrade where a familiar plugin suddenly asks for more. The point is not to produce a score but to make the trade visible to whoever reviews it later.

1. Name the feature you actually need from the DSH plugin, in one sentence.
2. Mark which permission rows changed or remain unknown.
3. Ask what each new grant enables that the old version could not do.
4. Prefer the candidate whose scope maps to that feature with the least reach.
5. If the wider scope is unavoidable, plan to run it in a restricted profile.
6. Record the choice, the rejected alternative and the review date.

A recorded decision is what keeps a team consistent when the next similar plugin appears. The specific winner matters less than the reasoning that can be reread. Permissions make that reasoning concrete, because they describe behavior rather than marketing.