Autorizzazioni della Devin CLI

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: Ogni cella mostra se quello strumento viene eseguito automaticamente (Auto, senza prompt) oppure resta in attesa della tua approvazione (Prompt) in quella modalità:

Tipo di strumento	Esempio	Normal	Accept Edits	Smart	Bypass	Autonomous (sandbox)
Sola lettura	Lettura di file, grep, glob	Auto	Auto	Auto	Auto	Auto
Fetch	Richieste HTTP	Prompt	Prompt	Auto quando valutato sicuro	Auto	Auto
Comandi Bash	Esecuzione della shell	Prompt	Prompt	Auto quando valutato sicuro	Auto	Auto
Modifiche ai file tramite `edit`/`write`	Modifica/scrittura di file	Prompt	Auto (nel workspace)	Auto (nel workspace)	Auto	Prompt

In modalità Normal (quella predefinita), le operazioni in sola lettura vengono approvate automaticamente, mentre le scritture e i comandi 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à Accept Edits, le modifiche ai file all’interno del workspace vengono approvate automaticamente, ma i comandi shell e le scritture al di fuori del workspace continuano a mostrare un prompt. In modalità Smart, le modifiche nel workspace vengono approvate automaticamente come in Accept Edits, mentre ogni altra azione viene valutata da un modello veloce che la esegue automaticamente solo quando è chiaramente sicura. Tutto il resto mostra un prompt come di consueto. Vedi Modalità Smart di seguito. In modalità Bypass, tutte le chiamate agli strumenti vengono approvate automaticamente senza prompt di conferma. In modalità Autonomous, i comandi shell e i fetch 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 mostrare un prompt, 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à Smart, Bypass e Autonomous non fanno override delle autorizzazioni a livello di organizzazione. Le regole di deny e ask imposte dagli admin e configurate tramite Team Settings restano attive indipendentemente dalla modalità di autorizzazione dell’utente. Per i dettagli, vedi Precedenza.

Modalità Smart

Smart si colloca tra Accept Edits e Bypass. Le modifiche ai file nel workspace vengono approvate automaticamente, esattamente come in Accept Edits. Per ogni altra azione — comandi shell, fetch web, strumenti MCP, scritture al di fuori del workspace — un modello rapido valuta se l’azione può essere eseguita senza supervisione. Se è chiaramente sicura, viene eseguita senza prompt; in caso contrario, oppure se il modello è incerto o non disponibile, viene visualizzato il normale prompt di approvazione.

/smart
# oppure
/mode smart

Puoi anche passare alla modalità Smart con Shift+Tab, selezionarla nel selettore della modalità o avviarla:

devin --permission-mode smart
# oppure
DEVIN_PERMISSION_MODE=smart devin

Il giudizio del modello si limita alle attività di sviluppo di routine: build, testing, linting, formattazione e ispezione del progetto. Alcune categorie non vengono mai approvate automaticamente in modalità Smart, indipendentemente dalla valutazione del modello:

Installazione di pacchetti (npm install, pip install, cargo install, brew install, …)
Operazioni git che modificano lo stato (i sottocomandi di sola lettura come git status restano idonei)
rm, sudo e altri comandi distruttivi o di escalation dei privilegi
kubectl delete e operazioni distruttive delle CLI cloud (aws, gcloud, az, terraform, …)
Qualsiasi operazione che legge o scrive file dotenv, materiale delle chiavi, configurazione Git o la configurazione dell’agent stesso

Smart si differenzia dalle modalità adiacenti per le azioni che delega:

	Accept Edits	Smart	Bypass
Modifiche ai file del workspace	Auto	Auto	Auto
Comandi shell e fetch	Chiedi sempre	Auto solo se il modello li ritiene sicuri	Sempre auto
Comandi ad alto rischio (installazioni, `rm`, `sudo`, operazioni `git` che modificano lo stato)	Chiedi sempre	Chiedi sempre	Sempre auto

Le tue regole hanno comunque la precedenza. Il giudizio di Smart si applica solo quando nessuna regola determina già l’esito: una regola deny blocca quindi l’azione e una regola ask richiede sempre conferma, esattamente come descritto in Come funzionano le autorizzazioni. Anche le regole deny e ask a livello di organizzazione non sono interessate.

La modalità Smart viene distribuita gradualmente, quindi potrebbe non essere ancora disponibile nel selettore delle modalità o nel ciclo Shift+Tab.

Modalità Autonomous

Autonomous è la modalità di autorizzazione associata al flag --sandbox. In pratica, corrisponde più o meno a “Accept Edits nel workspace corrente” con in più la possibilità di eseguire qualsiasi comando 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, Smart e Bypass sono nascosti. La modalità Plan rimane disponibile.
I comandi 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 shell successivi possono scrivere in quella posizione.
Gli ambiti Write(...) concessi nel corso della sessione espandono dinamicamente il sandbox per i comandi successivi. Le approvazioni Read(...) nel corso della sessione influenzano solo gli strumenti dell’agente; i percorsi nascosti dalle regole deny Read(...) rimangono nascosti per l’intera sessione.

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 scrivibili, sulle regole deny e sul filtraggio dei domini, e Team Settings → Applicazione sandbox per i controlli Enterprise.

Come funzionano le autorizzazioni

Quando l’agente richiama uno strumento, le regole corrispondenti allo stesso livello di configurazione vengono risolte come segue:

Regole di deny — Se c’è una corrispondenza, l’azione viene bloccata immediatamente.
Regole di ask — Se c’è una corrispondenza, ti viene chiesta conferma, a meno che non corrisponda anche una regola di autorizzazione per comandi o MCP altrettanto o più specifica.
Regole di autorizzazione — Se c’è una corrispondenza, l’azione procede senza chiedere conferma.
Predefinito — Se nessuna regola corrisponde, ti viene chiesta l’approvazione.

Una regola di deny ha sempre la precedenza. Una regola di autorizzazione non prevale mai su una regola di deny corrispondente, indipendentemente da quanto sia specifica.

Regole di autorizzazione specifiche

Allo stesso livello di configurazione, l’autorizzazione di un comando specifico può ritagliare un’eccezione all’interno di un ask più ampio. Ad esempio:

{
  "permissions": {
    "ask": ["exec"],
    "allow": ["Exec(git status)"]
  }
}

Con questa configurazione, git status viene eseguito senza richiedere conferma, mentre gli altri comandi continuano a richiederla. Lo stesso vale quando entrambe le regole usano ambiti di comando: un comando esatto è più specifico di un prefix e un prefix più lungo è più specifico di uno più corto. Le regole MCP seguono lo stesso principio: uno strumento specifico è più specifico di una regola valida per l’intero server, che a sua volta è più specifica di una regola che copre tutti gli strumenti MCP. Questa eccezione si applica solo all’interno dello stesso livello di configurazione. Un allow di livello inferiore non può fare override di un ask proveniente da un livello con precedenza maggiore, come le Settings dell’organizzazione. Inoltre non si applica ai glob di percorso di Read() o Write(): se un percorso corrisponde a una regola ask, Devin chiede conferma anche quando corrisponde anche un allow su un percorso più ristretto.

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.

Configurazione del progetto
Configurazione utente
Override locale

// .devin/config.json
{
  "permissions": {
    "allow": [
      "Read(src/**)",
      "Exec(npm run)"
    ],
    "deny": [
      "Exec(rm)"
    ]
  }
}

// ~/.config/devin/config.json
{
  "permissions": {
    "allow": [
      "Read(**)",
      "Exec(git)"
    ]
  }
}

// .devin/config.local.json
{
  "permissions": {
    "allow": [
      "Exec(docker compose)"
    ]
  }
}

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.

Write(glob)

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
]

Exec(prefix)

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.

Fetch(pattern)

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
    ]
  }
}

Pattern	Corrispondenze
`mcp__server__tool`	Uno 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:

Pattern	Significato
`*`	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:

Opzione	Dove viene salvata	Condivisa con il team?
Consenti una volta	Non salvata	No
Consenti per la sessione	Solo in memoria	No
Consenti per il progetto	`.devin/config.json`	Sì
Consenti per il progetto (locale)	`.devin/config.local.json`	No
Consenti globalmente	`~/.config/devin/config.json` (`%APPDATA%\devin\config.json` in Windows)	No

I prompt di Command offrono esplicitamente entrambi gli ambiti: “Sì, consenti sempre i comandi <cmd> in <project>” salva l’autorizzazione per il progetto corrente, mentre “Sì, consenti sempre i comandi <cmd> in tutti i progetti” la salva nella configurazione utente affinché si applichi ovunque. I prompt di recupero web per un URL o dominio specifico aggiungono un’opzione equivalente “Sì, consenti sempre tutti i recuperi web” che inserisce il recupero web nella whitelist in un unico passaggio.

Modificare un Command prima dell’approvazione

Le richieste di approvazione dei Command non prevedono solo una risposta sì/no. Oltre alle opzioni di approvazione, un prompt di Command offre:

Opzione	Effetto
Modifica comando	Apre il comando proposto per la modifica inline, consentendoti di modificarlo prima dell’esecuzione
Descrivi la modifica al comando	Riscrive il comando in base a una descrizione in linguaggio naturale di ciò che vuoi che faccia, consentendoti di rivederlo prima dell’esecuzione

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:

Opzione	Effetto
Consenti questo strumento (questa sessione)	Concede l’accesso allo strumento specifico per la sessione corrente
Consenti sempre questo strumento	Salva 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 server	Salva 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):

Settings dell’organizzazione/del team (se Enterprise)
Autorizzazioni concesse a livello di sessione (approvazioni interattive)
Configurazione locale del progetto (.devin/config.local.json)
Configurazione del progetto (.devin/config.json)
Configurazione utente (~/.config/devin/config.json; %APPDATA%\devin\config.json su Windows)

Le regole deny e ask a livello di organizzazione non possono essere sovrascritte 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 il comando specifico consente di fare l’override dell’ask più generico exec allo stesso livello di configurazione. Il deny di .env* ha comunque la precedenza sulla regola ask Write(**).

Per iniziare

Integrazioni dell'Editor

Estensibilità

Enterprise

Riferimento

Changelog

Autorizzazioni della Devin CLI

Comportamento predefinito delle autorizzazioni

Modalità Smart

Modalità Autonomous

Come funzionano le autorizzazioni

Regole di autorizzazione specifiche

Configurazione

Sintassi delle autorizzazioni

Autorizzazioni basate sull’ambito

Autorizzazioni per strumento

Autorizzazioni per gli strumenti MCP

Pattern di percorso

Opzioni di persistenza

Modificare un Command prima dell’approvazione

Autorizzazioni a livello di server MCP

Precedenza

Esempi

Configurazione minima per lo sviluppo

Attendibilità completa per un progetto

Enterprise con restrizioni rigide

​Comportamento predefinito delle autorizzazioni

​Modalità Smart

​Modalità Autonomous

​Come funzionano le autorizzazioni

​Regole di autorizzazione specifiche

​Configurazione

​Sintassi delle autorizzazioni

​Autorizzazioni basate sull’ambito

​Autorizzazioni per strumento

​Autorizzazioni per gli strumenti MCP

​Pattern di percorso

​Opzioni di persistenza

​Modificare un Command prima dell’approvazione

​Autorizzazioni a livello di server MCP

​Precedenza

​Esempi

​Configurazione minima per lo sviluppo

​Attendibilità completa per un progetto

​Enterprise con restrizioni rigide

Comportamento predefinito delle autorizzazioni

Modalità Smart

Modalità Autonomous

Come funzionano le autorizzazioni

Regole di autorizzazione specifiche

Configurazione

Sintassi delle autorizzazioni

Autorizzazioni basate sull’ambito

Autorizzazioni per strumento

Autorizzazioni per gli strumenti MCP

Pattern di percorso

Opzioni di persistenza

Modificare un Command prima dell’approvazione

Autorizzazioni a livello di server MCP

Precedenza

Esempi

Configurazione minima per lo sviluppo

Attendibilità completa per un progetto

Enterprise con restrizioni rigide