> ## 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

> Controlla cosa può fare l'agente con regole di autorizzazione granulari

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 richiesta) oppure resta in attesa della tua approvazione (**Richiesta**) in quella modalità:

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

In **modalità Normal** (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à Accept Edits**, 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](#autonomous-mode) è attivo.

<Warning>
  Le modalità 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="autonomous-mode">
  ### Modalità Autonomous
</div>

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.

```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 leggibili/scrivibili 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, 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.

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

***

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

<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>
  I deny a livello di organizzazione non possono essere sovrascritti 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 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(**)`.
</Tip>