Hoe werken dsh-plugins en hoe controleert u deze?

Wat is een dsh-plugin en wat kan deze doen?

dsh-plugins zijn Node-pakketten die de DeepSeek Harness in zijn eigen proces laadt. Wanneer u er een installeert, voert u code van derden uit met de rechten van uw agent, op de machine die uw agent al kan bereiken. Er zit niets tussen een geladen plugin en de rest van de harness. De vraag die u zich moet stellen voordat u een plugin installeert, is dus waar die code bij kan en hoe u die toegang beperkt.

dsh (DeepSeek Harness) is de open-source agent-harness van DeepSeek AI, gebouwd op een plugin-framework genaamd Cordis. In de README van het project staat dat alles een plugin is. De model-adapter is een plugin. De webinterface waarin u typt, is een plugin. Alles wat u van buiten het project installeert, komt in dezelfde boomstructuur terecht, op hetzelfde vertrouwensniveau als de onderdelen die standaard worden meegeleverd. Als u nog geen exemplaar heeft opgezet, begin dan met de DeepSeek Harness op een VPS en keer terug voordat u er iets aan toevoegt.

De extensiepunten die een plugin kan bereiken, staan vermeld in de AGENTS.md van de repository. Sinds augustus 2026 omvatten deze:

• LLM (large language model): de provider waarvoor uw API-sleutel betaalt
• Shell: de bash-functionaliteit, met lokale en pwsh-providers
• Filesystem: bestandsbeheer op basis van beleid
• Web: providers voor zoeken en ophalen
• Subprocess: een provider voor procesbomen
• Workflow: worker-threads
• Subagent: delegatie aan verdere agents
• Settings and credentials: uw opgeslagen configuratie en omgevingsvariabelen

Een plugin registreert ook tools op ctx.tools, en de documentatie is expliciet over het feit dat het schema van een geregistreerde tool wordt toegevoegd aan de prompt-assemblage. Dat tweede deel is wat mensen vaak over het hoofd zien. Een plugin kan beïnvloeden wat uw agent besluit te doen zonder dat de eigen code iets ongebruikelijks hoeft te doen, omdat de beschrijving die de plugin toevoegt, tekst wordt die het model leest. Dit is hetzelfde type probleem als prompt-injectie tegen coding agents, met één verschil: deze tekst arriveert wanneer u de plugin installeert en blijft aanwezig totdat u de plugin verwijdert.

Hoe vindt en laadt dsh plugins?

Er is geen globale plugin-directory. Een draaiende dsh is een plugin-boom die bij het opstarten wordt samengesteld uit geordende lagen; de eenheid die uw keuzes bevat, is een profiel. $DSH_HOME is standaard ingesteld op ~/.dsh en elk profiel bevindt zich in $DSH_HOME/profiles/<name>. De profielen web en headless worden bij het eerste gebruik automatisch aangemaakt op basis van meegeleverde templates.

Een profielmap bevat twee bestanden die alles bepalen:

• package.json, met de externe plugin-afhankelijkheden plus een dsh.profile-manifest dat de geordende bundles-lijst bevat
• cordis.patch.yml, uw eigen patch-laag boven op deze bundels

ls ~/.dsh
ls ~/.dsh/profiles/web

Bij het opstarten worden de lagen in deze volgorde toegepast, waarbij latere lagen voorrang krijgen:

1. een lege root
2. de bundels van het profiel, in de volgorde waarin het manifest ze vermeldt
3. de cordis.patch.yml van het profiel
4. $DSH_HOME/cordis.patch.yml
5. eventuele --patch <path>-overlays die via de command line worden meegegeven

Twee vlaggen tonen het resultaat van deze samenstelling zonder iets op te starten:

dsh --profile web --dump-default-config
dsh --profile web --dump-config

--dump-default-config toont de samengestelde boom op zichzelf. --dump-config voegt de profiel- en home-patchlagen toe, waardoor dit de meest nauwkeurige inventarisatie is van wat uw volgende opstartsessie zal laden. Lees dit door voordat u een machine vertrouwt die u heeft overgenomen.

Eén waarschuwing met betrekking tot deze patchbestanden. Configuratie is hier geen inerte data, omdat het formaat !!js-getagde waarden toestaat onder het config-blok van een plugin. Een cordis.patch.yml-fragment dat van een forum is gekopieerd, is code; behandel het daarom zoals u een shell-script uit dezelfde bron zou behandelen.

Wat voert dsh plugin add daadwerkelijk uit?

dsh plugin --profile <name> <args> stuurt de argumenten door naar pnpm binnen de directory van dat profiel, dus pnpm moet in de PATH staan. De werkwoorden zijn de werkwoorden van pnpm:

dsh plugin --profile web add '<package-or-git-spec>'
dsh plugin --profile web remove '<package-name>'
dsh plugin --profile web why '<package-name>'
dsh plugin --profile web update

Het beveiligingsmodel voor het installeren van een dsh-plugin is daarom gelijk aan het beveiligingsmodel voor het installeren van elke npm-achtige dependency, met één extra stap waarbij het resultaat in uw agent wordt geladen. Het pakket brengt zijn eigen dependency-tree mee en elk pakket in die tree eindigt in hetzelfde proces. Alles in hoe npm supply chain-aanvallen een server bereiken is hier ongewijzigd van toepassing.

pnpm 10 en later voeren standaard geen build-scripts van dependencies uit, en goedkeuring verloopt per pakket via onlyBuiltDependencies of pnpm approve-builds. Controleer welke versie van pnpm u heeft:

pnpm --version

Die standaardinstelling is waardevol en is tevens de meest genegeerde beveiligingsfunctie in het ecosysteem. Geblokkeerde build-scripts voorkomen dat code wordt uitgevoerd tijdens de installatie. Ze doen niets tegen de plugin zelf, omdat het hele punt van een plugin is dat de harness deze importeert en aanroept bij de volgende opstart. Een plugin heeft geen postinstall-hook nodig. Deze is immers uitgenodigd.

Wat u moet lezen voordat u een dsh-plugin installeert

Download het gepubliceerde tarball-bestand en lees de inhoud. Er wordt niets uitgevoerd wanneer u een archief uitpakt.

npm pack '<package-name>@<version>'
tar -tzf '<package-name>-<version>.tgz'
tar -xzf '<package-name>-<version>.tgz'
less package/package.json

Vier velden in dat package.json vertellen u het meeste van wat u moet weten. Lees scripts voor preinstall-, install- en postinstall-vermeldingen. Lees dependencies voor namen die u niet herkent, of namen die slechts één teken verschillen van namen die u wel kent. Lees bin voor alles wat het pakket op uw PATH vereist. Lees main of exports voor het entry-bestand, open dat bestand vervolgens en volg de instructies.

Lees daarna de code die daadwerkelijk wordt geladen. Een plugin die adverteert als notificatietool heeft geen reden om ~/.ssh te lezen, een host aan te roepen waar u nog nooit van heeft gehoord, of een shell te starten. Als het pakket alleen gebundelde of geminificeerde JavaScript bevat en er geen overeenkomstige broncode bestaat in een openbare repository, dan heeft u uw antwoord. Geef de voorkeur aan plugins waarvan u de broncode kunt lezen, en geef de voorkeur aan kleine plugins.

U kunt ook het register bevragen zonder iets te installeren:

pnpm view '<package-name>' dependencies
pnpm view '<package-name>' versions

Een pakket dat vorige week is gepubliceerd, met één versie, geen repository-veld en een naam die een populaire naam nabootst, is de oudste truc in elk register. Downloads verifiëren met checksums is de logische volgende stap: weet precies wat u heeft opgehaald voordat u het laat uitvoeren.

Versie vastzetten en het lockfile behouden

Een variërend versiebereik betekent dat de code binnen het proces van uw agent bij elke installatie of update kan veranderen zonder dat u daar zelf over beslist. Zet de versie vast.

dsh plugin --profile web add --save-exact '<package-name>@<version>'

De plaatsing van flags verschilt per pnpm-versie, dus controleer het resultaat in plaats van op het commando te vertrouwen. Open daarna het package.json van het profiel en bevestig dat de dependency als een kaal versienummer wordt weergegeven, zonder ^ of ~ ervoor. Dat bestand bepaalt wat er wordt geïnstalleerd.

Behoud vervolgens het lockfile, dat de volledige transitieve boom vastzet in plaats van alleen de naam op het hoogste niveau:

find ~/.dsh -maxdepth 3 -name 'pnpm-lock.yaml'

Kopieer dit naar een locatie waarvan u back-ups maakt, samen met het package.json van het profiel. Met deze twee bestanden bouwt u dezelfde boomstructuur opnieuw op een nieuwe machine. Voer dsh plugin --profile web update alleen uit wanneer u hebt besloten om van versie te wisselen, nooit als routineonderhoud, en lees daarna de diff van het lockfile.

Voor een plugin die vanaf git is geïnstalleerd in plaats van vanuit een registry, zet u de commit vast in plaats van de branch. Een specificatie in de vorm van github:owner/repo#<full commit sha> levert een vaste boomstructuur op. Een branch-naam geeft u wat die branch op dat moment bevat wanneer pnpm deze de volgende keer oplost; een beslissing die u aan iemand anders hebt overgelaten. De harness zelf vereist dezelfde discipline, omdat elke gepubliceerde dsh-build een release candidate is en een niet-vastgezette installatie op elke willekeurige dag naar een andere versie kan verwijzen. Dit is waar de meeste dsh installatie- en versie-fouten vandaan komen.

De plugin-markt en de waarde van "curated"

dsh beschikt over een marktplaats die als plugin wordt geïnstalleerd. Dit zegt iets over de architectuur:

dsh plugin --profile web add dshmarket

Na een herstart verschijnt deze onder Settings, gevolgd door Plugin Market. De README is duidelijk over de beperkingen. Installaties zijn beperkt tot bronnen die in een curated register staan; al het overige wordt geweigerd. Build-scripts zijn standaard geblokkeerd en het inschakelen hiervan vereist goedkeuring per pakket. Terminal-plugins worden gemarkeerd voordat ze in een webprofiel worden opgenomen. De belangrijkste zin is dat een vermelding geen goedkeuring inhoudt, aangezien de plugins code van derden zijn.

Een curated lijst verhoogt de ondergrens. Het leest de code niet voor u en kan niet voorspellen wat de volgende versie van een plugin doet nadat een beheerdersaccount van eigenaar is gewisseld. Behandel een installatie met één klik zoals u curl | bash van dezelfde auteur zou behandelen. Eén regel uit die README is het herhalen waard: een geëxporteerde back-up kan inloggegevens uit uw profielconfiguratie bevatten. Voeg deze daarom nooit toe aan een openbare issue of een paste-site. Als u op zoek bent naar een startlijst in plaats van een methode, dan is dsh plugins die het installeren waard zijn het bijbehorende artikel bij dit bericht.

Draai dsh als eigen gebruiker, niet als root

Controle vermindert de kans dat schadelijke code wordt uitgevoerd. Het principe van de minste privileges bepaalt wat die code kan bereiken als het toch misgaat. Op een VPS is dat tweede aspect eenvoudig te realiseren.

Geef de harness een eigen unix-account met een eigen home-directory en draai deze nooit als root:

sudo adduser --disabled-password --gecos "" dshrun
sudo -iu dshrun

Start de harness binnen die sessie, zodat deze de home-directory onder dat account schrijft:

npx @deepseek-ai/dsh web

De web-UI luistert standaard op http://127.0.0.1:3080. Laat dit zo. Alles wat die poort bereikt, kan een agent met een shell aansturen. Het publiceren van 3080 staat daarom gelijk aan het publiceren van een root-loze remote shell met een gebruiksvriendelijke interface. Benader deze vanaf uw laptop via een SSH-tunnel:

ssh -L 3080:127.0.0.1:3080 you@your-vps

Controleer vervolgens of er niets op een publiek adres luistert:

ss -lnt | grep 3080

Het lokale adres moet 127.0.0.1:3080 weergeven. Als er 0.0.0.0:3080 staat, is uw firewall de enige barrière tussen een buitenstaander en uw agent. De redenering achter veilig draaien van Claude Code op een VPS is ongewijzigd van toepassing op dsh. Geef de agent één werkmap die hij mag wijzigen en bewaar niets op die machine dat u niet opnieuw kunt opbouwen. Sterker nog, beschouw de machine als een wegwerpbare VM voor coding agents, aangezien het opnieuw opbouwen van een VPS een uur kost, terwijl het auditen ervan een week in beslag neemt.

Waar uw sleutels zich bevinden en waarom bestandsrechten slechts beperkt beschermen

dsh bewaart API-sleutels in $DSH_HOME/.credentials.yaml en omgevingsvariabelen in $DSH_HOME/.env, met modelinstellingen in $DSH_HOME/settings.yaml en sessiegeschiedenis onder $DSH_HOME/storages. Welke sleutel in welk bestand thuishoort en wat er in elke modus daadwerkelijk de server verlaat, is het onderwerp van het configureren van dsh API-sleutels, modellen en endpoints. Het is verstandig dit vast te leggen voordat u een plugin toevoegt, omdat elke sleutel die u configureert, een extra gegeven is dat een plugin kan uitlezen. Beveilig de twee gevoelige bestanden:

chmod 600 ~/.dsh/.credentials.yaml ~/.dsh/.env
ls -l ~/.dsh

Modus 600 geeft de eigenaar lees- en schrijfrechten en geeft alle anderen geen enkele toegang; dit is nuttig om te weten in beide notaties (numerieke versus symbolische chmod-modi). Wees realistisch over wat dit oplevert. Bestandsmodi beschermen deze bestanden tegen andere accounts op de server. Ze doen niets tegen een plugin, omdat de plugin wordt uitgevoerd als de gebruiker die eigenaar is van de bestanden, binnen het proces dat ze leest. Daarom betekent geheimen buiten het bereik van een AI-agent houden dat u ze helemaal niet op de machine moet plaatsen. Een dsh-server zou alleen de modelsleutel moeten bevatten die strikt noodzakelijk is. Uw cloud-inloggegevens en ondertekeningssleutels horen ergens anders thuis.

Waarom een plugin die het web leest het dreigingsmodel verandert

De web-interface biedt plugins zoek- en ophaalfuncties. Een plugin die een pagina in uw sessie ophaalt, haalt tekst op die door een aanvaller kan zijn geschreven. Een model-prompt maakt geen onderscheid tussen instructies en data. Een opgehaalde pagina kan daarom een regel bevatten die aan uw agent is gericht. Een omgeving die over shell-mogelijkheden beschikt, is slechts één gehoorzame stap verwijderd van het uitvoeren daarvan.

De controle is reeds aanwezig in de omgeving. dsh-base, het eerste pakket in elk profiel, levert de sandbox en het goedkeuringsbeleid. Gebruik dit. Een sessie die niet-vertrouwde pagina's kan ophalen, moet goedkeuring vereisen voor alles wat schrijft of uitvoert. Zo kan een opgehaalde instructie niet uit zichzelf een actie worden. Agentacties beveiligen met goedkeuringen behandelt hoe u moet nadenken over waar die grens ligt. De relatie werkt ook in beide richtingen, aangezien uw eigen server een pagina is die de agent van iemand anders zal ophalen. Dit is het geval bij AI-crawlers blokkeren op uw server.

Hoe controleer ik wat een plugin heeft gewijzigd?

Maak vooraf een snapshot, voer de installatie uit, maak daarna een snapshot en bekijk vervolgens het verschil.

dsh --profile web --dump-config > /tmp/dsh-before.txt
dsh plugin --profile web add '<package-name>@<version>'
dsh --profile web --dump-config > /tmp/dsh-after.txt
diff -u /tmp/dsh-before.txt /tmp/dsh-after.txt

De diff toont welke plugin-vermeldingen de installatie heeft toegevoegd aan de samengestelde boomstructuur. Als een plugin die u voor één kleine functie hebt geïnstalleerd meerdere vermeldingen toevoegt die u niet kunt verklaren, is dat een reden om te stoppen en de broncode te lezen voordat u deze opstart. dsh plugin --profile web why <package-name> beantwoordt de andere vraag: welke van uw directe afhankelijkheden een specifiek pakket heeft binnengehaald.

Geïnstalleerde pakketten komen terecht onder $DSH_HOME/profiles/node_modules, dus u kunt ook de boomstructuur op de schijf bekijken:

ls ~/.dsh/profiles/node_modules

Houd een tweede profiel bij waarin u nooit experimenteert. Wanneer een installatie de omgeving onbruikbaar maakt, vertelt het opstarten van dsh --profile <clean-name> u binnen enkele seconden of de plugin de oorzaak is.

Hoe verwijder ik een dsh-plugin?

dsh plugin --profile web remove '<package-name>'
dsh --profile web --dump-config > /tmp/dsh-after-removal.txt
diff -u /tmp/dsh-before.txt /tmp/dsh-after-removal.txt

Het verwijderen van de afhankelijkheid verwijdert niet altijd de configuratie. Inzendingen die in de cordis.patch.yml van het profiel zijn geschreven, blijven staan, omdat dat bestand van u is en de harness dit niet voor u zal herschrijven. Open het bestand en verwijder elk blok dat het pakket benoemt dat u heeft verwijderd.

less ~/.dsh/profiles/web/cordis.patch.yml

Ga vervolgens het onderdeel aan dat geen enkel uninstall-commando kan herstellen. Als u een plugin heeft verwijderd omdat u deze niet langer vertrouwde, dan heeft deze alles wat hij kon lezen al gelezen. Roteer de DeepSeek API-sleutel in de console van de provider en roteer alles wat zich in $DSH_HOME bevond. Bepaal daarna waar het unix-account waaronder de plugin draaide bij kon op de rest van uw netwerk.

De korte versie

• Lees de gepubliceerde tarball vóór de installatie, beginnend bij scripts en het entry-bestand
• Pin de exacte versie, of de exacte commit voor een git-spec, en behoud het lockfile
• Installeer in één profiel en houd een schoon profiel bij dat u kunt opstarten wanneer er iets kapot gaat
• Vergelijk --dump-config vóór en na elke installatie
• Draai de harness als een eigen unix-gebruiker, op loopback, bereikbaar via SSH
• Bewaar één API key op de server en roteer deze op de dag dat u een plugin verwijdert die u niet langer vertrouwt

Niets hiervan is een reden om plugins te vermijden. Het plugin-model is de reden waarom dsh nuttig is, en een harness die u niet kunt uitbreiden, is een harness die u zult vervangen. Het is wel een reden om te weten wat u heeft geïnstalleerd, van wie, op welke versie, en om het geheel ergens te draaien waar u het opnieuw kunt opbouwen.

FAQ

Isoleert dsh plugins van elkaar in een sandbox?

Nee. Een plugin wordt via Cordis in het harness-proces geladen en heeft toegang tot de gedocumenteerde capability seams, waaronder shell, bestandssysteem, web, subprocess, subagent en credentials. dsh-base, de eerste bundel in elk profiel, levert de sandbox en het goedkeuringsbeleid dat bepaalt wat de tools van de agent mogen doen; dit beleid vormt de basis van uw beveiliging. Er is geen permissiegrens per plugin. Het eerlijke model is daarom dat het installeren van een plugin uw vertrouwen uitbreidt naar de auteur ervan en naar elk pakket in de afhankelijkheidsboom.

Kan ik een dsh plugin installeren zonder de installatiescripts uit te voeren?

pnpm 10 en later blokkeren build-scripts van afhankelijkheden standaard, en dsh plugin ... add stuurt door naar pnpm. Op een actuele pnpm-versie voert de installatie dus geen pakketscripts uit, tenzij u dat pakket expliciet goedkeurt. Controleer uw versie met pnpm --version. Dit maakt een ongelezen plugin niet veilig. De code van de plugin zelf wordt bij de volgende opstart uitgevoerd omdat het harness deze bewust laadt; restricties tijdens de installatie hebben hier geen invloed op.

Waar staan dsh plugins en hun configuratie daadwerkelijk?

$DSH_HOME gebruikt standaard ~/.dsh. Profielen bevinden zich in $DSH_HOME/profiles/<name>, elk met een package.json met de plugin-afhankelijkheden, het dsh.profile manifest van geordende bundels en een cordis.patch.yml patch-laag. Geïnstalleerde pakketten komen terecht onder $DSH_HOME/profiles/node_modules. Keys staan in $DSH_HOME/.credentials.yaml, omgevingsvariabelen in $DSH_HOME/.env, en een $DSH_HOME/cordis.patch.yml op home-niveau is van toepassing op elk profiel. Voer dsh --profile web --dump-config uit om het samengestelde resultaat te zien zonder op te starten.

Is het veilig om te installeren vanuit de dsh plugin market?

De market beperkt installaties tot bronnen in een gecureerd register en blokkeert build-scripts tenzij u deze per pakket goedkeurt. Dit is een reële verbetering ten opzichte van het plakken van een pakketnaam uit een chatvenster. De README van de market vermeldt echter nog steeds dat een vermelding geen goedkeuring inhoudt, omdat de plugins code van derden zijn. Lees de broncode en pin de versie vast. Houd het harness op een gebruikersaccount, en bij voorkeur op een machine, die u kunt missen.