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.
Le impostazioni a livello di team consentono agli amministratori Enterprise di controllare l’utilizzo di Devin CLI all’interno della loro organizzazione.
- Gli amministratori di Devin Enterprise possono gestire queste impostazioni nella dashboard Devin per i clienti, in Settings → Enterprise → Windsurf (
app.devin.ai/org/{orgName}/settings/windsurf). Questa funzionalità è self-service per gli amministratori con accesso alle impostazioni Enterprise.
- Gli amministratori di Windsurf Enterprise possono gestire queste impostazioni nella dashboard di Windsurf all’indirizzo https://windsurf.com/team/cli-settings.
Solo le impostazioni specifiche di Devin CLI presenti in queste pagine si applicano a Devin CLI. Le impostazioni generali del team di Windsurf si applicano a Windsurf e non necessariamente a Devin CLI, a meno che non siano elencate anche nella pagina delle impostazioni di Devin CLI.
- Consentire solo modelli specifici — Limitare gli utenti a un elenco selezionato di modelli approvati
- Consentire tutti i modelli — Dare agli utenti accesso a tutti i modelli disponibili
Fai clic su Configure per gestire l’accesso ai modelli per ogni categoria.
Puoi anche bloccare un modello predefinito a livello di team che Devin CLI userà per le nuove sessioni. È la stessa impostazione che Windsurf usa per il suo modello predefinito, quindi configurandola una sola volta si applica a entrambe le interfacce.
- Se non è impostato alcun modello predefinito del team, Devin CLI usa il proprio modello predefinito integrato.
- Se il modello predefinito bloccato non è presente nell’elenco dei modelli consentiti sopra, Devin CLI torna al modello predefinito integrato: l’allowlist ha sempre la precedenza.
- I singoli utenti possono comunque cambiare modello durante una sessione; questa impostazione controlla solo il modello iniziale per le nuove sessioni.
Gli amministratori Enterprise possono configurare il modello predefinito dalla pagina Windsurf Team Settings, dalla pagina Devin CLI Settings o dalla pagina delle impostazioni di Devin Enterprise accessibile ai clienti all’indirizzo app.devin.ai/org/{orgName}/settings/windsurf.
Abilita la ricerca sul Web
- Attiva/disattiva — Abilita o disabilita completamente l’uso dei server MCP
- Server MCP consentiti — Specifica a quali server MCP gli utenti possono connettersi. Se non viene aggiunto alcun server, per impostazione predefinita tutti i server sono consentiti. Fai clic su Aggiungi server per limitare l’accesso a server specifici.
Autorizzazioni del terminale
{
"deny": [
"exec"
],
"ask": [],
"allow": [
"Read(~/my-repository/**)"
]
}
deny — Azioni completamente bloccate (ha la priorità più alta)ask — Azioni che richiedono sempre l’approvazione dell’utenteallow — Azioni approvate automaticamente senza richiesta
Le autorizzazioni possono essere basate sull’ambito o basate sullo strumento:
| Tipo | Formato | Esempio |
|---|
| Lettura file | Read(/path) | Read(~/sensitive/**) |
| Scrittura file | Write(/path) | Write(.env*) |
| Esecuzione comandi | Exec(cmd) | Exec(rm), Exec(sudo) |
| Richiesta HTTP | Fetch(url) | Fetch(https://internal.api/*) |
| Basato sullo strumento | Nome dello strumento | read, edit, exec |
Usa regole deny imposte dal team per impedire determinate azioni in tutta l’organizzazione, ad esempio bloccando l’accesso a directory sensibili o a comandi pericolosi come rm -rf o sudo.
applicazione della sandbox
Modalità di applicazione della sandbox
--sandbox per tutta la tua organizzazione:
- Optional (predefinito) — Gli utenti scelgono se specificare
--sandbox. Nessuna applicazione.
- Required — Il flag
--sandbox viene imposto a tutti gli utenti, anche se non lo specificano sulla riga di comando. Tutte le sessioni CLI vengono eseguite con il sandboxing del file system a livello di sistema operativo, che applica gli ambiti di autorizzazione di lettura/scrittura.
Una futura modalità Strict potrebbe bloccare completamente la configurazione della sandbox, impedendo agli utenti di modificarne le impostazioni.
Quando la sandbox è attiva:
- I percorsi scrivibili sono derivati dagli ambiti di autorizzazione
Write(...) concessi, oltre che dalla directory del workspace
- I percorsi leggibili sono derivati dagli ambiti
Read(...) concessi (i percorsi predefiniti della piattaforma, come /usr/bin, sono sempre leggibili)
- Gli ambiti concessi durante la sessione espandono dinamicamente la sandbox per i comandi successivi
Se la risoluzione della sandbox non riesce (ad es. perché gli strumenti di sandboxing non sono disponibili sulla piattaforma dell’utente), la CLI si rifiuterà di avviarsi invece di essere eseguita senza sandbox. Questo comportamento fail-closed si applica sia quando la sandbox è abilitata tramite questa impostazione del team, sia quando l’utente specifica direttamente --sandbox, garantendo che l’obiettivo di sicurezza non venga mai aggirato silenziosamente.Quando l’applicazione è imposta a livello Enterprise, gli utenti vedranno un errore che indica di contattare l’amministratore del team. Quando invece è avviata dall’utente, l’errore suggerisce di eseguire senza --sandbox per procedere senza isolamento a livello di sistema operativo.Cause comuni del mancato completamento della risoluzione della sandbox:
- Windows: il sandboxing a livello di sistema operativo non è attualmente supportato su Windows. Le sessioni su Windows non si avvieranno quando viene specificato
--sandbox o quando l’applicazione della sandbox è Required, anche quando la CLI viene eseguita come server ACP all’interno di un IDE (ad es. Windsurf).
- Linux: il sandboxing richiede che
bubblewrap (bwrap) e socat siano installati. Se mancano, l’avvio della sessione non riesce e vengono mostrate le istruzioni di installazione.
- Errori negli ambiti di autorizzazione: percorsi non validi negli ambiti di autorizzazione che non possono essere risolti.
Assicurati che tutte le macchine di destinazione siano predisposte prima di impostare la modalità di applicazione della sandbox su Required per tutta la tua organizzazione. Se alcuni utenti usano Windows, non potranno eseguire la CLI finché il sandboxing a livello di sistema operativo non sarà supportato su Windows o finché il criterio non verrà riportato a Optional.
-
Allowlist di domini — Quando è impostata, solo i domini presenti in questo elenco sono raggiungibili tramite il proxy di rete della sandbox. Questo elenco è autoritativo: sostituisce completamente qualsiasi
allowed_domains configurato dagli utenti nella loro configurazione sandbox. Gli utenti non possono aggiungere altri domini per aggirare le restrizioni dell’amministratore.
-
Denylist di domini — Domini che vengono sempre bloccati. I domini negati di Enterprise sono additivi: vengono uniti ai
denied_domains locali dell’utente, rendendo l’elenco risultante più restrittivo.
Consulta il riferimento della configurazione sandbox per la sintassi dei pattern di dominio (ad es. *.example.com, **.example.com).
Come interagiscono gli elenchi di domini di Enterprise e dell’utente:
| Scenario | Configurazione Enterprise | Configurazione utente | Risultato effettivo |
|---|
| L’amministratore imposta un’allowlist | allowed_domains: ["github.com"] | allowed_domains: ["npmjs.org"] | È consentito solo github.com (Enterprise sostituisce l’elenco dell’utente) |
| L’amministratore imposta una denylist | denied_domains: ["evil.com"] | denied_domains: ["risky.io"] | Sia evil.com sia risky.io vengono bloccati (elenchi uniti) |
| Nessuna allowlist dell’amministratore | allowed_domains: [] | allowed_domains: ["github.com"] | Viene usata l’allowlist dell’utente |
Poiché i denied_domains locali dell’utente vengono mantenuti e uniti in modo additivo, un utente potrebbe negare un dominio che compare nell’allowlist di Enterprise. Questo è intenzionale: l’effetto combinato è sempre più restrittivo, mai meno. Se ciò causa problemi di accesso, l’utente deve rimuovere la voce in conflitto dalla propria configurazione locale.
Combina l’applicazione della sandbox con regole di negazione delle autorizzazioni del team (ad es. Write(/etc)) per impedire agli agenti di modificare directory sensibili sia a livello di autorizzazioni sia a livello di sistema operativo. Le regole di negazione delle autorizzazioni impediscono all’agente anche solo di tentare l’azione, mentre la sandbox fornisce un secondo livello di protezione a livello di sistema operativo.
Mostra “Install Devin CLI” nella command palette di Windsurf
Cmd+Shift+P su macOS o Ctrl+Shift+P su Windows/Linux) ed eseguire Install Devin CLI per aggiungere il binario devin al PATH.
Questa impostazione è disponibile con i piani Windsurf Enterprise e Devin Enterprise ed è disattivata per impostazione predefinita.
