Berechtigungen

Dropstone verwendet die permission-Konfiguration, um zu entscheiden, ob eine bestimmte Aktion automatisch ausgeführt, Sie dazu aufgefordert werden oder blockiert werden soll.

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

Aktionen

Jede Berechtigungsregel wird zu einer der folgenden Optionen aufgelöst:

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

Konfiguration

Sie können Berechtigungen global (mit *) festlegen und bestimmte 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 (Objektsyntax)

Für die 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 besteht darin, die Catch-all-Regel "*" zuerst und spezifischere Regeln danach zu setzen.

Platzhalter

Berechtigungsmuster verwenden einfachen Platzhalterabgleich:

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

Home-Verzeichnis-Erweiterung

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 zu erlauben, die Pfade außerhalb des Arbeitsverzeichnisses berühren, in dem Dropstone gestartet wurde. Dies gilt für jedes Tool, das einen Pfad als Eingabe akzeptiert (z. B. read, edit, glob, grep und viele bash-Befehle).

Die Home-Erweiterung (wie ~/...) betrifft 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 erlaubt werden.

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

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

Jedes hier erlaubte Verzeichnis erbt dieselben Standardwerte wie der aktuelle Arbeitsbereich. Da read standardmäßig auf allow gesetzt ist, sind Lesezugriffe auch für Einträge unter external_directory erlaubt, sofern nicht überschrieben. Fügen Sie explizite Regeln hinzu, wenn ein Tool in diesen Pfaden eingeschränkt werden soll, z. B. um Bearbeitungen zu blockieren, während Lesezugriffe erlaubt bleiben:

{
  "$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 fokussiert und fügen Sie bei Bedarf zusätzliche Erlaubnis- oder Verweigerungsregeln für andere Tools (z. B. bash) hinzu.

Verfügbare Berechtigungen

Dropstone-Berechtigungen sind nach Tool-Namen sowie einigen Sicherheitsvorkehrungen benannt:

• read: Lesen einer Datei (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: Ausführen von Shell-Befehlen (entspricht geparsten Befehlen wie git status --porcelain)
• task: Starten von Unteragenten (entspricht dem Unteragententyp)
• skill: Laden einer Fähigkeit (entspricht dem Fähigkeitsnamen)
• lsp: Ausführen von LSP-Abfragen (derzeit nicht granular)
• question: Fragen an den Benutzer während der Ausführung
• webfetch: Abrufen einer URL (entspricht der URL)
• websearch: Websuche (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 dreimal mit identischer Eingabe wiederholt wird

Standardwerte

Wenn Sie nichts angeben, fragt der Standard-build-Agent vor allem nach. Genehmigung ist der Standard, nicht die Ausnahme:

{
  "permission": {
    "*": "ask",
    "read": {
      "*": "ask",
      "*.env": "ask",
      "*.env.*": "ask",
      "*.env.example": "ask"
    },
    "external_directory": { "*": "ask" },
    "question": "deny",
    "plan_enter": "deny",
    "plan_exit": "deny",
    "mode_switch": "deny"
  }
}

Verzeichnisse, die Sie bereits genehmigt haben, werden für den Rest der Sitzung als "allow" zu external_directory hinzugefügt.

Ihre Konfiguration wird über diesen Standardwerten zusammengeführt, und Ihre Regeln gewinnen. Sie ersetzt sie nicht: Wenn Sie edit auf "allow" setzen, bleibt read auf "ask". Benennen Sie daher jede Berechtigung, die Sie ändern möchten.

Der accept all-Agent startet stattdessen mit "*": "allow", wobei external_directory vollständig erlaubt ist. Lesezugriffe auf .env und .env.* fragen weiterhin nach, mit der Begründung, dass die automatische Genehmigung eines Laufs nicht dasselbe ist wie die Zustimmung zur Herausgabe von Geheimnissen.

Headless- und Servermodus

Interaktiv ist "ask" harmlos: Sie werden aufgefordert und genehmigen. Unter dropstone serve, in CI oder überall sonst ohne Person an der Tastatur gibt es niemanden, den man fragen könnte, sodass der Aufruf bei "status": "running" bleibt und die Anfrage hängt, anstatt fehlzuschlagen. Es gibt kein Timeout und keinen Fehler, der abgefangen werden könnte.

Da der build-Agent vor allem fragt, ist dies das Standardergebnis und kein Randfall. Eine Teilkonfiguration rettet Sie auch nicht: Wenn Sie edit erlauben, bleibt read auf "ask", und der Lauf hängt beim ersten Öffnen einer Datei durch den Agenten.

Zwei Möglichkeiten, das zu beheben. Entweder führen Sie den accept all-Agenten aus, der mit "*": "allow" startet:

curl -X POST ".../session/$SID/message" -d '{ "agent": "accept all", ... }'

Oder bleiben Sie bei build und geben Sie die vollständige Whitelist an, wobei Sie standardmäßig verweigern, damit ein in einer späteren Version hinzugefügtes Tool Ihre Läufe nicht stillschweigend zum Hängen bringt:

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

Grenzen Sie es auf das ein, was die Aufgabe tatsächlich benötigt. Ein Agent, der nur liest und berichtet, hat keinen Grund, edit oder bash zu halten.

Beachten Sie, dass accept all weiterhin vor dem Lesen von .env und .env.* fragt. Wenn ein unbeaufsichtigter Lauf eine dieser Dateien lesen muss, erlauben Sie sie explizit und gehen Sie bewusst damit um.

Was "Ask" bewirkt

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

• 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 ablehnen

Die Menge der Muster, die always genehmigen würde, wird vom Tool bereitgestellt (z. B. whitelisten Bash-Genehmigungen typischerweise ein sicheres Befehlspräfix wie git status*).

Agenten

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

{
  "$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 Agentenberechtigungen auch in Markdown konfigurieren:

---
description: Code-Review ohne Bearbeitungen
mode: subagent
permission:
  edit: deny
  bash: ask
  webfetch: deny
---

Nur Code analysieren und Änderungen vorschlagen.