> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Autorizzazioni della Devin CLI

> Configura le regole di autorizzazione della Devin CLI per consentire, negare o richiedere conferma per comandi, accesso ai file e strumenti MCP con una precedenza prevedibile.

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.

***

<div id="default-permission-behavior">
  ## Comportamento predefinito delle autorizzazioni
</div>

Devin CLI utilizza un sistema di autorizzazioni a livelli per bilanciare potenza e sicurezza. Il comportamento predefinito dipende dalla [modalità](/it/cli/essential-commands#modes) 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](#smart-mode) 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](#autonomous-mode) è attivo.

<Warning>
  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](/it/cli/enterprise/team-settings) restano attive indipendentemente dalla modalità di autorizzazione dell'utente. Per i dettagli, vedi [Precedenza](#precedence).
</Warning>

<div id="smart-mode">
  ### Modalità Smart
</div>

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.

```bash theme={null}
/smart
# oppure
/mode smart
```

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

```bash theme={null}
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 |

<Note>
  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](#how-permissions-work). Anche le regole `deny` e `ask` a livello di organizzazione non sono interessate.
</Note>

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

<div id="autonomous-mode">
  ### Modalità Autonomous
</div>

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.

```bash theme={null}
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](/it/cli/reference/configuration/config-file#sandbox) per i dettagli sulle radici scrivibili, sulle regole deny e sul filtraggio dei domini, e [Team Settings → Applicazione sandbox](/it/cli/enterprise/team-settings#sandbox-enforcement) per i controlli Enterprise.

***

<div id="how-permissions-work">
  ## Come funzionano le autorizzazioni
</div>

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

1. **Regole di deny** — Se c'è una corrispondenza, l'azione viene bloccata immediatamente.
2. **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.
3. **Regole di autorizzazione** — Se c'è una corrispondenza, l'azione procede senza chiedere conferma.
4. **Predefinito** — Se nessuna regola corrisponde, ti viene chiesta l'approvazione.

<Note>
  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.
</Note>

<div id="specific-allow-rules">
  ### Regole di autorizzazione specifiche
</div>

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

```json theme={null}
{
  "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.

***

<div id="configuration">
  ## Configurazione
</div>

Aggiungi le autorizzazioni alla sezione `permissions` del file di configurazione:

<Note>
  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](/it/cli/reference/configuration/config-file#file-locations).
</Note>

<Tabs>
  <Tab title="Configurazione del progetto">
    ```json theme={null}
    // .devin/config.json
    {
      "permissions": {
        "allow": [
          "Read(src/**)",
          "Exec(npm run)"
        ],
        "deny": [
          "Exec(rm)"
        ]
      }
    }
    ```
  </Tab>

  <Tab title="Configurazione utente">
    ```json theme={null}
    // ~/.config/devin/config.json
    {
      "permissions": {
        "allow": [
          "Read(**)",
          "Exec(git)"
        ]
      }
    }
    ```
  </Tab>

  <Tab title="Override locale">
    ```json theme={null}
    // .devin/config.local.json
    {
      "permissions": {
        "allow": [
          "Exec(docker compose)"
        ]
      }
    }
    ```
  </Tab>
</Tabs>

***

<div id="permission-syntax">
  ## Sintassi delle autorizzazioni
</div>

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).

<div id="scope-based-permissions">
  ### Autorizzazioni basate sull'ambito
</div>

<AccordionGroup>
  <Accordion title="Read(glob)" icon="eye" defaultOpen>
    Controlla l'accesso in lettura ai file. Il pattern glob corrisponde ai percorsi dei file.

    ```json theme={null}
    "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.
  </Accordion>

  <Accordion title="Write(glob)" icon="pen">
    Controlla l'accesso in scrittura e modifica dei file.

    ```json theme={null}
    "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
    ]
    ```
  </Accordion>

  <Accordion title="Exec(prefix)" icon="terminal">
    Controlla l'esecuzione dei comandi shell. Corrisponde ai comandi che iniziano con il prefisso specificato.

    ```json theme={null}
    "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
    ]
    ```

    <Note>
      `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.
    </Note>
  </Accordion>

  <Accordion title="Fetch(pattern)" icon="globe">
    Controlla l'accesso HTTP fetch tramite pattern URL.

    ```json theme={null}
    "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](https://urlpattern.spec.whatwg.org/). La forma abbreviata `domain:` corrisponde a qualsiasi percorso sul dominio esatto.
  </Accordion>
</AccordionGroup>

<div id="tool-based-permissions">
  ### Autorizzazioni per strumento
</div>

Usa il nome dello strumento per controllare interi strumenti:

```json theme={null}
{
  "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`

<div id="mcp-tool-permissions">
  ### Autorizzazioni per gli strumenti MCP
</div>

Controlla l'accesso agli strumenti del server MCP:

```json theme={null}
{
  "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 |

***

<div id="path-patterns">
  ## Pattern di percorso
</div>

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:**

```json theme={null}
"allow": [
  "Read(**)",                    // Tutti i file ovunque
  "Read(src/**/*.ts)",           // Tutti i file TypeScript in src/
  "Write(~/projects/myapp/**)"   // Scrittura in un progetto specifico
]
```

<Note>
  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.
</Note>

***

<div id="persistence-options">
  ## Opzioni di persistenza
</div>

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.

<div id="editing-a-command-before-approving">
  ### Modificare un Command prima dell'approvazione
</div>

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 |

<div id="mcp-server-level-grants">
  ### Autorizzazioni a livello di server MCP
</div>

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.

***

<div id="precedence">
  ## Precedenza
</div>

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)

<Warning>
  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.
</Warning>

***

<div id="examples">
  ## Esempi
</div>

<div id="minimal-development-setup">
  ### Configurazione minima per lo sviluppo
</div>

Consenti le comuni operazioni di sola lettura, chiedi conferma per tutto il resto:

```json theme={null}
{
  "permissions": {
    "allow": [
      "Read(**)",
      "Exec(git status)",
      "Exec(git diff)",
      "Exec(git log)"
    ]
  }
}
```

<div id="full-trust-for-a-project">
  ### Attendibilità completa per un progetto
</div>

Approva automaticamente la maggior parte delle operazioni nel progetto:

```json theme={null}
{
  "permissions": {
    "allow": [
      "Read(**)",
      "Write(src/**)",
      "Write(tests/**)",
      "Exec(npm)",
      "Exec(git)",
      "Exec(node)"
    ],
    "deny": [
      "Exec(rm -rf)",
      "Exec(sudo)",
      "Write(.env*)"
    ]
  }
}
```

<div id="locked-down-enterprise">
  ### Enterprise con restrizioni rigide
</div>

Limita l'accesso a specifiche operazioni sicure e richiedi sempre conferma per le operazioni di scrittura:

```json theme={null}
{
  "permissions": {
    "allow": [
      "Read(src/**)",
      "Exec(git status)",
      "Exec(git diff)",
      "Exec(npm run lint)"
    ],
    "deny": [
      "Exec(rm)",
      "Exec(sudo)",
      "Write(.env*)"
    ],
    "ask": [
      "Write(**)",
      "exec"
    ]
  }
}
```

<Tip>
  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(**)`.
</Tip>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.