Home/Models, permissions & security/Permissions & allowlists

Plugins declare no permissions in package.json: measured across 223 packages

You want to see what a plugin asks for before installing, and there is no permissions field anywhere in package.json.

VerifiedVersion and environmentChecked 2026-11-14

Host version: 0.1.2-alpha.5
Sample: 223 packages under profiles/node_modules
Checked: 2026-11-14

Copyable command

python -c "import json,glob,os;b=os.path.expanduser('~/.dsh/profiles/node_modules/@deepseek-ai');print(sorted({k for p in glob.glob(b+'/*/package.json') for k in (json.load(open(p,encoding='utf-8')).get('dsh') or {})}))"

Leading with the conclusion, because this is where people look in the wrong place: plugin packages in 0.1.2-alpha.5 declare no permissions.

Measured: reading every package.json for the 223 @deepseek-ai/* packages under ~/.dsh/profiles/node_modules, the dsh subtree holds exactly three keys:

Key under dsh	Purpose	Permission declaration?
bundle	Marks this as a loadable bundle	No
client	Declares a client-side entry	No
configTrees	Declares config trees	No

Searching for permissions, allow, allowedTools, sandbox, and capabilities: 0 hits.

So how is permission governed

Through two session-level knobs: sandbox mode (file effects) and approval policy (whether to proceed). In other words, permission is not declared by the plugin; it is granted by your session.

That difference matters: declared permissions would let you read a manifest and assess risk before installing; session-granted permissions mean every plugin shares the same grant. The latter means 'an untrusted plugin' equals 'something with the same reach as everything else you run'.

What you can actually check before installing

What bundle and client entries the dsh subtree declares — that decides which layer it joins.
Its dependencies. An unfamiliar dependency deserves more suspicion than an unfamiliar plugin.
Whether there is a postinstall style script — those run at install time and are outside the session sandbox.
Try it against a copy of your workspace, never the one you are working in.

How to write a risk note that is not empty

Not 'grant permissions carefully'. Be specific: this plugin runs an install script, it depends on a non-official package, it writes outside the workspace (if so). If you have no evidence, say there is none.

What counts as working

Check every line. All of them pass or the job is not done.

Run the command above and confirm three keys
You know permission comes from the session, not the manifest
You checked for install-time scripts before adding a plugin

Where it fails

Symptom, cause, what to do — written in the order it actually happens.

Symptom	Cause	What to do
No permissions field, as the internet suggested	This version has no such field	Look at the dsh subtree and dependencies instead
A plugin did more than expected	Permission is session-granted and shared	Test in a workspace copy and tighten sandbox and approval if needed

Sources

Verified means measured here. Compiled means every line carries a source.

Plugins declare no permissions in package.json: measured across 223 packages

Copyable command

So how is permission governed

What you can actually check before installing

How to write a risk note that is not empty

What counts as working

Where it fails

Sources

Other topics in this group