# pnpm 12.11 ermöglicht Agent Skills in npm-Abhängigkeiten: Was muss nach einer einmaligen Genehmigung bei Upgrades noch geprüft werden?

> Canonical: https://vxi.me/de/posts/pnpm-agent-skills-approval-scope/
> Locale: de-de
> Published: 2026-10-13
> Updated: 2026-10-13
> Markdown: https://vxi.me/de/posts/pnpm-agent-skills-approval-scope.md

# pnpm 12.11.0: Skills-Berechtigungen im Praxistest – was bedeutet „einmal genehmigen“ genau?

**Beschreibung:** Auf Grundlage des Quellcodes und der versionsgebundenen Dokumentation von pnpm v12.11.0 untersuche ich, wo Skills gefunden werden, wie Genehmigungen und Verknüpfungen funktionieren, und prüfe wichtige Verzweigungen mit einem unabhängigen synthetischen Modell. So können Entwickler Abhängigkeits-Upgrades und den Umgang mit Berechtigungen besser einschätzen.

## Erkennung und Berechtigungsgrenzen

Zunächst stellte ich mir die Frage ziemlich einfach vor: Taucht in einer Abhängigkeit eine `SKILL.md` auf, legt pnpm sie entweder bei der Installation im Agent-Verzeichnis ab – oder kümmert sich überhaupt nicht darum. Als ich den versionsgebundenen Quellcode von pnpm 12.11.0 genauer untersuchte, stellte ich fest, dass dazwischen mehrere Schritte liegen: Erkennung, Berechtigungsprüfung und Verknüpfung. Diese Grenzen sind entscheidend dafür, was „einmal genehmigen“ tatsächlich bedeutet.

Zuerst verfolgte ich die Erkennungslogik und nahm an, dass jede Skill-Datei im Abhängigkeitsbaum in den Genehmigungsprozess gelangt. Tatsächlich ist der Scanbereich enger: pnpm prüft die direkten Abhängigkeiten jedes Workspace-Importers in der Lockdatei und scannt nur eine Ebene von Skills-Verzeichnissen. Indirekte Abhängigkeiten sind von diesem Erkennungspfad nicht erfasst. „Eine Datei befindet sich im Abhängigkeitsbaum“ und „pnpm erkennt sie“ sind also nicht gleichbedeutend.

Anschließend betrachtete ich Installation, Verknüpfung und das Laden durch den Agent getrennt. Die Dateien eines Pakets können bereits im Abhängigkeitsverzeichnis liegen. Der Berechtigungsstatus entscheidet, ob pnpm dafür einen symbolischen Link zum Zielverzeichnis erstellt. Ob Claude Code oder ein anderer Agent die Dateien danach einliest und wie er sie verarbeitet, entscheidet der jeweilige Client. Der pnpm-Quellcode verwaltet die Verknüpfungen, parst oder führt den Inhalt eines Skills aber nicht aus.

Zu den Berechtigungszweigen gehören die Zustände „ausstehende Genehmigung“, „abgelehnt“ und „genehmigt“. Die Genehmigung erfolgt auf Paketebene; `pnpm approve` betrifft sowohl Build-Skripte als auch Skills-Berechtigungen. Das ist nicht dasselbe wie eine Prüfung jeder einzelnen Datei. Die Berechtigung für Build-Skripte und `permissions.skills` sind getrennte Berechtigungsbereiche. Wird das Build-Skript eines Pakets genehmigt, bedeutet das nicht, dass der Skill-Inhalt gesondert geprüft wurde.

Am längsten hielt ich bei der Frage inne, wie weit eine Genehmigung reicht. Die offizielle Dokumentation zu v12.11.0 besagt, dass eine Genehmigung auf Paketebene alle Skills dieser Abhängigkeit umfasst und auch für spätere Versionen gilt. Bei Upgrades sollte man auf Änderungen an den Anweisungen in neueren Versionen achten: Der frühere Genehmigungsstatus kann weiterhin gelten, während eine neue Version Skills hinzufügen oder überarbeiten kann.

Wenn im Workspace mehrere geeignete Versionen vorhanden sind, wählt der Quellcode die höchste installierte, geeignete Registry-Version aus. Das beeinflusst, auf welchen Inhalt tatsächlich verlinkt wird. Ein Blick auf den Versionsbereich in `package.json` reicht daher nicht aus. Um zu beurteilen, was ein Agent nach einem Upgrade möglicherweise einliest, muss man auch die tatsächlich ausgewählte Paketversion und die darin enthaltenen Skills prüfen.

Auch für das Zielverzeichnis gelten klare Bedingungen. v12.11.0 berücksichtigt die Umgebungsvariablen `CLAUDECODE`, `CURSOR_AGENT` und `GEMINI_CLI` sowie bereits vorhandene Agent-Skills-Verzeichnisse im Workspace. Mit `skills.dirs` lässt sich dies explizit überschreiben. Eine explizit leere Konfiguration deaktiviert Skills. Wird bei der Genehmigung kein Zielverzeichnis automatisch erkannt, tritt ein Fehler wegen des fehlenden Ziels auf.

```yaml
# pnpm-workspace.yaml
skills:
  dirs:
    - .claude/skills
    - .cursor/skills
```

Ich hatte außerdem angenommen, dass beim Widerruf einer Berechtigung auch die Inhalte im betreffenden Verzeichnis gelöscht würden. Der Quellcode und ein unabhängiges Dateisystemmodell zeigen eine engere Grenze: Im Modell werden von ihm erstellte Links entfernt, manuell angelegte lokale Skills bleiben unangetastet. Ist der Zielpfad bereits durch ein echtes Verzeichnis belegt, wird dieses nicht ersetzt. Auch Zweige wie das Entfernen eines Pakets oder ein fehlendes Zielverzeichnis müssen anhand ihrer jeweiligen Logik für die Link-Bereinigung und Fehlerbehandlung verstanden werden.

## Synthetisches Modell und Testergebnisse

Um diese Zweige konkreter zu untersuchen, schrieb ich mit der Standardbibliothek von Node 22.16.0 ein unabhängiges Modell eines synthetischen Dateisystems. Es erstellt temporäre Dummy-Abhängigkeiten, synthetische `SKILL.md`-Dateien und symbolische Links und berechnet anschließend Inhalts-Fingerprints. Die acht Szenarien decken ausstehende Genehmigungen, Ablehnungen, Genehmigungen, nach einem Upgrade neu hinzugefügte Skills, Widerruf, Pfadkonflikte, ausschließlich indirekte Abhängigkeiten sowie das Fehlen eines automatisch erkannten Zielverzeichnisses ab.

Alle acht Szenarien des Modells liefen erfolgreich durch. Im Upgrade-Szenario änderte sich der Inhalts-Fingerprint, und es erschien ein zweiter Skill-Link. Beim ersten Modelllauf schlug ein Szenario fehl, weil ich anhand der erwarteten Link-Anzahl von null prüfte, ob ein genehmigter Skill vorhanden war. Dadurch stufte ich den Fall „kein Zielverzeichnis“ fälschlich als Fehler ein. Nach der Analyse prüfte ich stattdessen die Anzahl der genehmigten Skills separat. Beim erneuten Lauf waren alle acht Szenarien erfolgreich.

## Prüfung im Repository und Geltungsbereich

Bei der Prüfung eines Repositorys kann man zunächst mit `pnpm permissions` oder `pnpm permissions list` die Berechtigungen anzeigen lassen und sie mit der Workspace-Konfiguration abgleichen. Nach einem Abhängigkeits-Upgrade sollte man die Skills-Dateien der neuen Version und deren Änderungen prüfen. Projekte, die stärker auf stabile Anweisungen angewiesen sind, können Abhängigkeitsversionen festschreiben und `SKILL.md` in der CI vergleichen.

```sh
pnpm permissions
pnpm permissions list
```

### Grenzen / Einschränkungen

Diese Analyse basiert auf dem Quellcode von pnpm v12.11.0 und der versionsgebundenen Dokumentation. Die Tests wurden mit einem unabhängig von Node ausgeführten synthetischen Modell durchgeführt und decken Dateisystemverhalten ab. Das Modell verwendet weder die pnpm-CLI noch echte Installationen oder Updates und bindet auch keinen Agent ein. Die Erkennungs- und Ausführungsregeln der Clients können sich außerdem je nach Version ändern. Die Änderungen an der Umgebungserkennung in pnpm 12.11.1 dürfen nicht rückwirkend als Funktion von 12.11.0 betrachtet werden. Der durch eine Genehmigung auf Paketebene entstehende Vertrauensumfang für spätere Versionen ist eine Gestaltungsgrenze, die bei der Upgrade-Prüfung berücksichtigt werden sollte.

**Referenzen:** [pnpm-Quellcode v12.11.0](https://github.com/pnpm/pnpm/tree/v12.11.0) · [pnpm-Dokumentation v12.11.0](https://github.com/pnpm/pnpm/tree/v12.11.0/docs)