Vai al contenuto principale

Documentation Index

Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt

Use this file to discover all available pages before exploring further.

Il sistema di autorizzazioni controlla quali azioni l’agente può eseguire senza chiedere la tua approvazione. Puoi pre-approvare le azioni sicure, bloccare quelle pericolose e richiedere sempre una conferma per le operazioni sensibili.

Comportamento predefinito delle autorizzazioni

Devin CLI utilizza un sistema di autorizzazioni a livelli per bilanciare potenza e sicurezza. Il comportamento predefinito dipende dalla modalità corrente:
Tipo di strumentoEsempioNormaleAccetta modificheBypassAutonomous (sandbox)
Sola letturaLettura di file, grep, globNoNoNoNo
FetchRichieste HTTPNoNo
Comandi BashEsecuzione della shellNoNo
Modifiche ai file tramite edit/writeModifica/scrittura di fileNo (nel workspace)No
In modalità Normale (quella predefinita), le operazioni in sola lettura vengono approvate automaticamente, mentre le scritture e i comandi della shell richiedono la tua approvazione esplicita. Ogni volta che approvi un’azione, puoi scegliere di consentirla una sola volta, per la sessione oppure in modo permanente per il progetto. In modalità Accetta modifiche, le modifiche ai file all’interno del workspace vengono approvate automaticamente, ma i comandi della shell e le scritture al di fuori del workspace continuano a richiedere conferma. In modalità Bypass, tutte le chiamate agli strumenti vengono approvate automaticamente senza richiesta di conferma. In modalità Autonomous, i comandi della shell e i recuperi di rete vengono approvati automaticamente perché il sandbox a livello di sistema operativo limita ciò con cui possono interagire. Le modifiche dirette ai file tramite gli strumenti edit/write continuano a richiedere conferma, perché questi strumenti operano al di fuori del sandbox. La modalità Autonomous è disponibile solo quando il sandbox a livello di sistema operativo è attivo.
Le modalità Bypass e Autonomous non fanno override delle autorizzazioni a livello di organizzazione. Le regole di negazione e richiesta imposte dagli admin e configurate tramite Team Settings restano attive indipendentemente dalla modalità di autorizzazione dell’utente. Per i dettagli, vedi Precedenza.

Modalità Autonomous

Autonomous è la modalità di autorizzazione associata al flag --sandbox. In pratica, corrisponde più o meno a “Accetta modifiche nel workspace corrente” con in più la possibilità di eseguire qualsiasi comando della shell, il tutto confinato nel sandbox a livello di sistema operativo. Quando il sandbox è attivo:
  • È l’unica modalità di autorizzazione disponibile. Nelle sessioni sandbox, Normal, Accept Edits e Bypass sono nascosti. La modalità Plan rimane disponibile.
  • I comandi della shell e i fetch vengono approvati automaticamente invece di richiedere conferma, perché il sandbox limita ciò che possono leggere, scrivere e raggiungere tramite la rete.
  • Le modifiche dirette ai file tramite gli strumenti edit e write continuano a richiedere conferma. Questi strumenti vengono eseguiti all’interno del processo CLI anziché nel sandbox, quindi non possono esserne vincolati. Concedere un ambito Write(...) al prompt espande dinamicamente il sandbox, così i comandi della shell successivi possono scrivere in quella posizione.
  • Gli ambiti concessi nel corso della sessione espandono dinamicamente il sandbox per i comandi successivi.
devin --sandbox --permission-mode autonomous
Usa Bypass quando vuoi un’esecuzione senza restrizioni e senza isolamento a livello di sistema operativo; usa --sandbox (che seleziona Autonomous) quando vuoi un’esecuzione senza supervisione con limiti imposti dal sistema operativo sull’accesso al filesystem e alla rete. Consulta il riferimento della configurazione della sandbox per i dettagli sulle radici leggibili/scrivibili e sul filtraggio dei domini, e Team Settings → Applicazione sandbox per i controlli Enterprise.

Come funzionano le autorizzazioni

Quando l’agente richiama uno strumento, il sistema di autorizzazioni controlla le tue regole in ordine di priorità:
  1. Regole di deny — Controllate per prime. Se c’è una corrispondenza, l’azione viene bloccata immediatamente.
  2. Regole di ask — Controllate per seconde. Se c’è una corrispondenza, ti viene sempre chiesta conferma (ha la precedenza su qualsiasi regola di autorizzazione).
  3. Regole di autorizzazione — Controllate per ultime. Se c’è una corrispondenza, l’azione procede senza chiedere conferma.
  4. Predefinito — Se nessuna regola corrisponde, ti viene chiesta l’approvazione.
Poiché le regole di deny vengono controllate prima di quelle di ask, e quelle di ask prima di quelle di autorizzazione, una regola di deny ha sempre la precedenza. Se lo stesso ambito corrisponde sia a una regola di deny sia a una regola di ask, prevale la regola di deny.

Configurazione

Aggiungi le autorizzazioni alla sezione permissions del file di configurazione:
Su Windows, il percorso del file di configurazione dell’utente è %APPDATA%\devin\config.json (in genere C:\Users\<you>\AppData\Roaming\devin\config.json) anziché ~/.config/devin/config.json. Per maggiori dettagli, consulta File di configurazione.
// .devin/config.json
{
  "permissions": {
    "allow": [
      "Read(src/**)",
      "Exec(npm run)"
    ],
    "deny": [
      "Exec(rm)"
    ]
  }
}

Sintassi delle autorizzazioni

Esistono due tipi di matcher di autorizzazione: basati sull’ambito (controllano quali percorsi/comandi/URL sono accessibili) e basati sugli strumenti (controllano quali strumenti possono essere utilizzati).

Autorizzazioni basate sull’ambito

Read(glob)

Controlla l’accesso in lettura ai file. Il pattern glob corrisponde ai percorsi dei file.
"allow": [
  "Read(src/**)",           // Tutti i file in src/
  "Read(~/.config/**)",     // File di configurazione nella home
  "Read(/tmp/**)"           // Directory temporanea
]
I percorsi di directory corrispondono automaticamente a tutti i file al loro interno.
Controlla l’accesso in scrittura e modifica dei file.
"allow": [
  "Write(src/**)",          // Può scrivere ovunque in src/
  "Write(tests/**)"         // Può scrivere nei file di test
],
"deny": [
  "Write(*.lock)",          // Non può modificare i file lock
  "Write(.env*)"            // Non può modificare i file env
]
Controlla l’esecuzione dei comandi shell. Corrisponde ai comandi che iniziano con il prefisso specificato.
"allow": [
  "Exec(git)",              // git, git status, git commit...
  "Exec(npm run)",          // npm run test, npm run build...
  "Exec(python)"            // python, python script.py...
],
"deny": [
  "Exec(rm)",               // Blocca rm, rm -rf, ecc.
  "Exec(sudo)"              // Blocca i comandi sudo
]
Exec(git) corrisponde a “git”, “git status”, “git commit -m ‘msg’” ma NON a “gitk” o “github-cli”. Il prefisso deve corrispondere a una parola completa.
Controlla l’accesso HTTP fetch tramite pattern URL.
"allow": [
  "Fetch(https://api.github.com/*)",    // API di GitHub
  "Fetch(https://*.example.com/*)",     // Tutti i sottodomini di example.com
  "Fetch(domain:npmjs.org)"             // Qualsiasi URL su npmjs.org
]
I pattern URL seguono lo standard WHATWG URL Pattern. La forma abbreviata domain: corrisponde a qualsiasi percorso sul dominio esatto.

Autorizzazioni per strumento

Usa il nome dello strumento per controllare interi strumenti:
{
  "permissions": {
    "deny": [
      "edit",       // Blocca tutte le modifiche ai file
      "exec"        // Blocca l'esecuzione di tutti i comandi
    ],
    "allow": [
      "read",       // Consenti tutte le letture di file
      "grep",       // Consenti tutte le ricerche
      "glob"        // Consenti la ricerca di tutti i file
    ]
  }
}
Nomi degli strumenti disponibili: read, edit, grep, glob, exec

Autorizzazioni per gli strumenti MCP

Controlla l’accesso agli strumenti del server MCP:
{
  "permissions": {
    "allow": [
      "mcp__github__list_issues",     // Strumento specifico su server specifico
      "mcp__github__*",               // Tutti gli strumenti sul server github
      "mcp__*"                        // Tutti gli strumenti MCP
    ],
    "deny": [
      "mcp__github__delete_repo"      // Blocca uno strumento pericoloso specifico
    ]
  }
}
PatternCorrispondenze
mcp__server__toolUno strumento specifico
mcp__server__*Tutti gli strumenti di un server
mcp__*Tutti gli strumenti MCP ovunque

Pattern di percorso

I pattern glob in Read() e Write() supportano:
PatternSignificato
*Qualsiasi sequenza di caratteri in un singolo segmento del percorso
**Qualsiasi sequenza di caratteri attraverso più segmenti del percorso (ricorsivo)
~Espansione della home directory
Esempi:
"allow": [
  "Read(**)",                    // Tutti i file ovunque
  "Read(src/**/*.ts)",           // Tutti i file TypeScript in src/
  "Write(~/projects/myapp/**)"   // Scrittura in un progetto specifico
]
Usa un prefisso di percorso assoluto (ad es. Read(/**)) quando vuoi includere tutti i file del sistema. Un semplice Read(**) senza una / iniziale viene interpretato in relazione alla directory di lavoro corrente, quindi corrisponde solo ai file in quella directory, non ai file accessibili altrove tramite percorsi assoluti.

Opzioni di persistenza

Quando l’agente richiede un’autorizzazione durante una sessione, puoi scegliere come salvare la decisione:
OpzioneDove viene salvataCondivisa con il team?
Consenti una voltaNon salvataNo
Consenti per la sessioneSolo in memoriaNo
Consenti per il progetto.devin/config.json
Consenti per il progetto (locale).devin/config.local.jsonNo
Consenti globalmente~/.config/devin/config.json (%APPDATA%\devin\config.json in Windows)No

Autorizzazioni a livello di server MCP

Quando viene richiesta un’autorizzazione per uno specifico strumento MCP (ad es. list_issues sul server Figma), il prompt di autorizzazione offre anche opzioni più ampie a livello di server:
OpzioneEffetto
Consenti questo strumento (questa sessione)Concede l’accesso allo strumento specifico per la sessione corrente
Consenti sempre questo strumentoSalva nella configurazione l’autorizzazione per lo strumento specifico
Consenti tutti gli strumenti su questo server (questa sessione)Concede l’accesso a tutti gli strumenti del server per la sessione corrente
Consenti sempre gli strumenti su questo serverSalva nella configurazione l’accesso a tutti gli strumenti del server
Questo ti consente di concedere rapidamente l’accesso completo a un server MCP attendibile senza dover approvare ogni singolo strumento.

Precedenza

Quando più fonti di autorizzazione definiscono delle regole, vengono combinate secondo questo ordine di precedenza (dalla più alta alla più bassa):
  1. Settings dell’organizzazione/del team (se Enterprise)
  2. Autorizzazioni concesse a livello di sessione (approvazioni interattive)
  3. Configurazione locale del progetto (.devin/config.local.json)
  4. Configurazione del progetto (.devin/config.json)
  5. Configurazione utente (~/.config/devin/config.json; %APPDATA%\devin\config.json su Windows)
I deny a livello di organizzazione non possono essere sovrascritti dalla configurazione del progetto o dell’utente. Questo garantisce l’applicazione dei criteri Enterprise.

Esempi

Configurazione minima per lo sviluppo

Consenti le comuni operazioni di sola lettura, chiedi conferma per tutto il resto:
{
  "permissions": {
    "allow": [
      "Read(**)",
      "Exec(git status)",
      "Exec(git diff)",
      "Exec(git log)"
    ]
  }
}

Attendibilità completa per un progetto

Approva automaticamente la maggior parte delle operazioni nel progetto:
{
  "permissions": {
    "allow": [
      "Read(**)",
      "Write(src/**)",
      "Write(tests/**)",
      "Exec(npm)",
      "Exec(git)",
      "Exec(node)"
    ],
    "deny": [
      "Exec(rm -rf)",
      "Exec(sudo)",
      "Write(.env*)"
    ]
  }
}

Enterprise con restrizioni rigide

Limita l’accesso a specifiche operazioni sicure e richiedi sempre conferma per le operazioni di scrittura:
{
  "permissions": {
    "allow": [
      "Read(src/**)",
      "Exec(git status)",
      "Exec(git diff)",
      "Exec(npm run lint)"
    ],
    "deny": [
      "Exec(rm)",
      "Exec(sudo)",
      "Write(.env*)"
    ],
    "ask": [
      "Write(**)",
      "exec"
    ]
  }
}
In questo esempio, le scritture in .env* vengono negate direttamente, tutte le altre scritture richiedono sempre conferma all’utente e solo alcuni comandi in sola lettura vengono approvati automaticamente. Poiché deny viene verificato prima di ask, il deny di .env* ha la precedenza sulla regola ask Write(**).