Dropstone Docs

Berechtigungen

Kontrollieren Sie, welche Aktionen genehmigt werden müssen.

Dropstone verwendet die permission-Konfiguration, um zu entscheiden, ob eine bestimmte Aktion automatisch ausgeführt, zur Genehmigung angefordert oder blockiert werden soll.

Die veraltete tools-Boolesche Konfiguration ist veraltet; sie wurde in permission zusammengeführt. Die alte tools-Konfiguration wird weiterhin aus Gründen der Rückwärtskompatibilität unterstützt.


Aktionen

Jede Berechtigungsregel wird zu einer der folgenden aufgelöst:

  • "allow": ohne Genehmigung ausführen
  • "ask": zur Genehmigung auffordern
  • "deny": die Aktion blockieren

Konfiguration

Sie können Berechtigungen global (mit *) festlegen und spezifische Tools überschreiben.

{
  "$schema": "https://dropstone.io/schema/config.json",
  "permission": {
    "*": "ask",
    "bash": "allow",
    "edit": "deny"
  }
}

Sie können auch alle Berechtigungen auf einmal festlegen:

{
  "$schema": "https://dropstone.io/schema/config.json",
  "permission": "allow"
}

Granulare Regeln (Objekt-Syntax)

Bei den meisten Berechtigungen können Sie ein Objekt verwenden, um verschiedene Aktionen basierend auf der Tool-Eingabe anzuwenden.

{
  "$schema": "https://dropstone.io/schema/config.json",
  "permission": {
    "bash": {
      "*": "ask",
      "git *": "allow",
      "npm *": "allow",
      "rm *": "deny",
      "grep *": "allow"
    },
    "edit": {
      "*": "deny",
      "packages/web/src/content/docs/*.mdx": "allow"
    }
  }
}

Regeln werden durch Musterabgleich ausgewertet, wobei die letzte übereinstimmende Regel gewinnt. Ein häufiges Muster ist, die Catch-All-Regel "*" zuerst zu platzieren und spezifischere Regeln danach.

Platzhalter

Berechtigungsmuster verwenden einfachen Platzhalter-Abgleich:

  • * entspricht null oder mehr beliebigen Zeichen
  • ? entspricht genau einem Zeichen
  • Alle anderen Zeichen entsprechen wörtlich

Erweiterung des Home-Verzeichnisses

Sie können ~ oder $HOME am Anfang eines Musters verwenden, um auf Ihr Home-Verzeichnis zu verweisen. Dies ist besonders nützlich für external_directory-Regeln.

  • ~/projects/* -> /Users/username/projects/*
  • $HOME/projects/* -> /Users/username/projects/*
  • ~ -> /Users/username

Externe Verzeichnisse

Verwenden Sie external_directory, um Tool-Aufrufe zuzulassen, die Pfade außerhalb des Arbeitsverzeichnisses berühren, in dem Dropstone gestartet wurde. Dies gilt für alle Tools, die einen Pfad als Eingabe verwenden (z. B. read, edit, glob, grep und viele bash-Befehle).

Die Home-Erweiterung (wie ~/...) beeinflusst nur, wie ein Muster geschrieben wird. Sie macht einen externen Pfad nicht zu einem Teil des aktuellen Arbeitsbereichs, daher müssen Pfade außerhalb des Arbeitsverzeichnisses weiterhin über external_directory zugelassen werden.

Beispielsweise erlaubt dies den Zugriff auf alles unter ~/projects/personal/:

{
  "$schema": "https://dropstone.io/schema/config.json",
  "permission": {
    "external_directory": {
      "~/projects/personal/**": "allow"
    }
  }
}

Alle hier zugelassenen Verzeichnisse erben die gleichen Standardwerte wie der aktuelle Arbeitsbereich. Da read standardmäßig allow ist, sind Lesevorgänge auch für Einträge unter external_directory zulässig, sofern nicht anders überschrieben. Fügen Sie explizite Regeln hinzu, wenn ein Tool in diesen Pfaden eingeschränkt werden soll, z. B. um Bearbeitungen zu blockieren und Lesevorgänge zu behalten:

{
  "$schema": "https://dropstone.io/schema/config.json",
  "permission": {
    "external_directory": {
      "~/projects/personal/**": "allow"
    },
    "edit": {
      "~/projects/personal/**": "deny"
    }
  }
}

Halten Sie die Liste auf vertrauenswürdige Pfade konzentriert und schichten Sie nach Bedarf zusätzliche Allow- oder Deny-Regeln für andere Tools ein (z. B. bash).


Verfügbare Berechtigungen

Dropstone-Berechtigungen werden nach Tool-Namen plus ein paar Sicherheitsvorkehrungen verschlüsselt:

  • read: Datei lesen (entspricht dem Dateipfad)
  • edit: alle Dateiänderungen (umfasst edit, write, patch)
  • glob: Datei-Globbing (entspricht dem Glob-Muster)
  • grep: Inhaltssuche (entspricht dem Regex-Muster)
  • bash: Shell-Befehle ausführen (entspricht geparsten Befehlen wie git status --porcelain)
  • task: Subagenten starten (entspricht dem Subagenten-Typ)
  • skill: Skill laden (entspricht dem Skill-Namen)
  • lsp: LSP-Abfragen ausführen (derzeit nicht granular)
  • question: Benutzer während der Ausführung Fragen stellen
  • webfetch: URL abrufen (entspricht der URL)
  • websearch: Web-Suche (entspricht der Abfrage)
  • external_directory: wird ausgelöst, wenn ein Tool Pfade außerhalb des Projekt-Arbeitsverzeichnisses berührt
  • doom_loop: wird ausgelöst, wenn derselbe Tool-Aufruf 3-mal mit identischer Eingabe wiederholt wird

Standardwerte

Wenn Sie nichts angeben, startet Dropstone mit permissiven Standardwerten:

  • Die meisten Berechtigungen standardmäßig auf "allow".
  • doom_loop und external_directory standardmäßig auf "ask".
  • read ist "allow", aber .env-Dateien werden standardmäßig verweigert:
{
  "permission": {
    "read": {
      "*": "allow",
      "*.env": "deny",
      "*.env.*": "deny",
      "*.env.example": "allow"
    }
  }
}

Was „Ask" bewirkt

Wenn Dropstone zur Genehmigung auffordert, bietet die Benutzeroberfläche drei Ergebnisse:

  • once: nur diese Anfrage genehmigen
  • always: zukünftige Anfragen genehmigen, die den vorgeschlagenen Mustern entsprechen (für den Rest der aktuellen Dropstone-Sitzung)
  • reject: die Anfrage verweigern

Der Satz von Mustern, die always genehmigen würde, wird vom Tool bereitgestellt (z. B. bash-Genehmigungen setzen typischerweise ein sicheres Befehlspräfix wie git status* auf die Whitelist).


Agenten

Sie können Berechtigungen pro Agent überschreiben. Agent-Berechtigungen werden mit der globalen Konfiguration zusammengeführt, und Agent-Regeln haben Vorrang. Erfahren Sie mehr über Agent-Berechtigungen.

Note:

Beziehen Sie sich auf den Abschnitt Granulare Regeln (Objekt-Syntax) oben für detailliertere Beispiele zum Musterabgleich.

{
  "$schema": "https://dropstone.io/schema/config.json",
  "permission": {
    "bash": {
      "*": "ask",
      "git *": "allow",
      "git commit *": "deny",
      "git push *": "deny",
      "grep *": "allow"
    }
  },
  "agent": {
    "build": {
      "permission": {
        "bash": {
          "*": "ask",
          "git *": "allow",
          "git commit *": "ask",
          "git push *": "deny",
          "grep *": "allow"
        }
      }
    }
  }
}

Sie können Agent-Berechtigungen auch in Markdown konfigurieren:

---
description: Code review without edits
mode: subagent
permission:
  edit: deny
  bash: ask
  webfetch: deny
---

Only analyze code and suggest changes.

Tipp:

Verwenden Sie Musterabgleich für Befehle mit Argumenten. "grep *" erlaubt grep pattern file.txt, während "grep" allein es blockieren würde. Befehle wie git status funktionieren für Standardverhalten, erfordern aber explizite Berechtigung (wie "git status *"), wenn Argumente übergeben werden.

Strg+I