Permissions

Dropstone usa la configurazione permission per decidere se una determinata azione debba essere eseguita automaticamente, richiedere una conferma, o essere bloccata.

La configurazione legacy tools di tipo booleano è deprecata; è stata integrata in permission. La vecchia configurazione tools è ancora supportata per compatibilità con le versioni precedenti.

Azioni

Ogni regola di permesso si risolve in uno dei seguenti valori:

• "allow": esegui senza approvazione
• "ask": chiedi approvazione
• "deny": blocca l'azione

Configurazione

Puoi impostare i permessi a livello globale (con *) e sovrascrivere strumenti specifici.

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

Puoi anche impostare tutti i permessi in una volta:

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

Regole Granulari (Sintassi a Oggetto)

Per la maggior parte dei permessi, puoi usare un oggetto per applicare azioni diverse in base all'input dello strumento.

{
  "$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"
    }
  }
}

Le regole vengono valutate tramite corrispondenza di pattern, con l'ultima regola corrispondente che vince. Un pattern comune è mettere la regola catch-all "*" per prima, e le regole più specifiche dopo.

Wildcard

I pattern di permesso usano una semplice corrispondenza con wildcard:

• * corrisponde a zero o più caratteri qualsiasi
• ? corrisponde esattamente a un carattere
• Tutti gli altri caratteri corrispondono letteralmente

Espansione della Directory Home

Puoi usare ~ o $HOME all'inizio di un pattern per fare riferimento alla tua directory home. Questo è particolarmente utile per le regole external_directory.

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

Directory Esterne

Usa external_directory per consentire chiamate a strumenti che toccano percorsi al di fuori della directory di lavoro in cui è stato avviato Dropstone. Questo si applica a qualsiasi strumento che accetta un percorso come input (ad esempio read, edit, glob, grep e molti comandi bash).

L'espansione della home (come ~/...) influisce solo su come viene scritto un pattern. Non rende un percorso esterno parte del workspace corrente, quindi i percorsi al di fuori della directory di lavoro devono comunque essere consentiti tramite external_directory.

Ad esempio, questo consente l'accesso a tutto ciò che si trova sotto ~/projects/personal/:

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

Qualsiasi directory consentita qui eredita le stesse impostazioni predefinite del workspace corrente. Poiché read è predefinito su allow, le letture sono consentite anche per le voci sotto external_directory a meno che non vengano sovrascritte. Aggiungi regole esplicite quando uno strumento deve essere limitato in questi percorsi, come bloccare le modifiche mantenendo le letture:

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

Mantieni l'elenco concentrato su percorsi attendibili e aggiungi regole extra di consenso o diniego come necessario per altri strumenti (ad esempio bash).

Permessi Disponibili

I permessi di Dropstone sono indicizzati per nome dello strumento, più un paio di protezioni di sicurezza:

• read: lettura di un file (corrisponde al percorso del file)
• edit: tutte le modifiche ai file (copre edit, write, patch)
• glob: globbing dei file (corrisponde al pattern glob)
• grep: ricerca di contenuti (corrisponde al pattern regex)
• bash: esecuzione di comandi shell (corrisponde a comandi analizzati come git status --porcelain)
• task: avvio di subagent (corrisponde al tipo di subagent)
• skill: caricamento di una skill (corrisponde al nome della skill)
• lsp: esecuzione di query LSP (attualmente non granulare)
• question: fare domande all'utente durante l'esecuzione
• webfetch: recupero di un URL (corrisponde all'URL)
• websearch: ricerca web (corrisponde alla query)
• external_directory: attivato quando uno strumento tocca percorsi al di fuori della directory di lavoro del progetto
• doom_loop: attivato quando la stessa chiamata a uno strumento si ripete 3 volte con input identico

Predefiniti

Se non specifichi nulla, l'agente build predefinito chiede prima di ogni cosa. L'approvazione è il default, non un'eccezione:

{
  "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"
  }
}

Le directory che hai già approvato vengono aggiunte a external_directory come "allow" per il resto della sessione.

La tua configurazione viene unita sopra questi predefiniti, e le tue regole vincono. Non li sostituisce: impostare edit su "allow" lascia read su "ask", quindi nomina ogni permesso che intendi modificare.

L'agente accept all parte invece da "*": "allow", con external_directory completamente consentito. Le letture di .env e .env.* chiedono comunque conferma, con il ragionamento che approvare automaticamente un'esecuzione non equivale a dare il consenso alla consegna di segreti.

Modalità headless e server

In modalità interattiva, "ask" è innocuo: ricevi una richiesta e approvi. Sotto dropstone serve, in CI, o ovunque non ci sia una persona alla tastiera, non c'è nessuno a cui chiedere, quindi la chiamata rimane su "status": "running" e la richiesta resta in sospeso invece di fallire. Non c'è timeout né errore da catturare.

Poiché l'agente build chiede prima di ogni cosa, questo è il risultato predefinito piuttosto che un caso limite. Una configurazione parziale non ti salva nemmeno: consentire edit lascia read su "ask", e l'esecuzione si blocca la prima volta che l'agente apre un file.

Due modi per risolvere. O esegui l'agente accept all, che parte da "*": "allow":

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

Oppure resta su build e dichiara l'allowlist completa, negando per impostazione predefinita così uno strumento aggiunto in una versione successiva non può iniziare silenziosamente a bloccare le tue esecuzioni:

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

Restringilo a ciò di cui il lavoro ha realmente bisogno. Un agente che legge e riporta soltanto non ha motivo di avere edit o bash.

Nota che accept all chiede comunque prima di leggere .env e .env.*. Se un'esecuzione non presidiata deve leggerne uno, consentilo esplicitamente e sii deliberato al riguardo.

Cosa fa "Ask"

Quando Dropstone richiede approvazione, l'interfaccia offre tre risultati:

• once: approva solo questa richiesta
• always: approva le richieste future che corrispondono ai pattern suggeriti (per il resto della sessione corrente di Dropstone)
• reject: nega la richiesta

L'insieme di pattern che always approverebbe è fornito dallo strumento (ad esempio, le approvazioni bash tipicamente mettono in whitelist un prefisso di comando sicuro come git status*).

Agenti

Puoi sovrascrivere i permessi per singolo agente. I permessi dell'agente vengono uniti alla configurazione globale, e le regole dell'agente hanno precedenza. Scopri di più sui permessi degli agenti.

{
  "$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"
        }
      }
    }
  }
}

Puoi anche configurare i permessi degli agenti in Markdown:

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

Only analyze code and suggest changes.