I plugin di Devin e la pagina Customize

Cosa sono i plugin?

Un plugin raggruppa skills — e facoltativamente regole, hooks, server MCP e subagent — così da poter essere installato e riutilizzato come unità. Consulta il riferimento ai plugin per il formato dei file e per sapere cosa può includere un plugin. I plugin sono il livello di personalizzazione condiviso tra le sessioni cloud Devin, la Devin CLI e Devin Desktop: installa un plugin una volta sola e le sue skill diventano disponibili come comandi /<plugin>:<skill> ovunque utilizzi Devin. I plugin possono essere installati a tre livelli:

Ambito	Chi lo installa	Chi lo riceve
Personal	Tu	Le tue sessioni — cloud, CLI e Desktop, su ogni dispositivo in cui hai effettuato l’accesso
Organizzazione	Org admin	Le sessioni cloud di quell’organizzazione, oltre alla CLI e a Desktop per i membri che la hanno come organizzazione primaria
Enterprise	Enterprise admin	Tutti gli utenti di ogni organizzazione dell’Enterprise

Questa pagina descrive il lato web app: la pagina Customize, l’installazione in ciascun ambito, l’indicizzazione, gli MCP e i manifest gestiti che stanno alla base di tutto.

La pagina Customize

I plugin si trovano nella pagina Customize, raggiungibile dalla voce Customize nella sidebar (ha sostituito le precedenti pagine Settings → Plugins, Settings → Marketplace e Settings → Connections → server MCP; i vecchi collegamenti vengono reindirizzati). Contiene cinque tab:

Plugins — tutto ciò che è installato, raggruppato per ambito, più Browse marketplace per installarne altri.
Skills — le skill che Devin carica su richiesta, provenienti dai plugin installati e dalle tue repository.
MCPs — i server MCP che mettono a disposizione di Devin strumenti oltre a quelli built-in. Vedi MCPs di seguito.
Hooks — comandi eseguiti automaticamente in determinati momenti di una session.
Rules — indicazioni permanenti che Devin segue in ogni session.

Usa i tab degli ambiti per scegliere Personal, organizzazione o Enterprise, in base al tuo livello di accesso. Ogni ambito mostra il proprio contenuto effettivo: ciò che si applica realmente dopo l’applicazione della governance. Per modificare i contenuti a livello di repository (skill, regole e plugin dichiarati nel file .devin/config.json di una repo), modifica i file della repository. Chi può modificare cosa:

Personal — chiunque, per il proprio ambito.
organizzazione — i membri con accesso alle settings dell’organizzazione.
Enterprise — i membri con accesso alle enterprise settings.

Clicca su un plugin per aprire il relativo pannello di dettaglio: le sue skill, MCP, hook, regole e subagent; il ref tracciato o lo SHA bloccato e il percorso; in quali ambiti è installato e cosa lo richiede; le sue autorizzazioni; e — se ne hai i diritti — le azioni per connettere i suoi MCP, modificare ciò che richiede, disinstallarlo oppure (per un plugin caricato) fare delete.

Installazione dei plugin

Dal marketplace

Clicca su Browse marketplace nella tab Plugins. Il marketplace è un unico elenco che combina il marketplace ufficiale di Devin (CognitionAI/devin-marketplace, in genere un plugin per ogni integration come Linear, Notion, Datadog o Snowflake) con i plugin aggiunti dalla tua organizzazione o dalla tua Enterprise. Ogni scheda propone un menu di installazione con tutti gli ambiti in cui hai permessi di scrittura e indica dove il plugin è già installato (“Installed for me”, “Installed at organization”, …). Alla prima installazione di un plugin, Devin mostra un avviso di sicurezza: l’installazione consente a Devin di eseguire le regole, gli hooks e le skills del plugin (e, nel caso di un plugin con server MCP, di accedere a dati esterni tramite essi); procedi quindi solo se ritieni il plugin attendibile e ne hai verificato la sorgente. I plugin del marketplace ufficiale sono contrassegnati come tali. Al termine dell’installazione, un toast conferma l’ambito e — se il plugin include un server MCP che richiede credenziali o autorizzazione — propone Connect MCP per completare subito la configurazione. Gli Enterprise admins possono nascondere il marketplace ufficiale per tutte le org (interruttore Show official marketplace plugins) e stabilire quali server MCP del marketplace sono visibili alle organizzazioni tramite Marketplace availability.

Da un repository, da un file `.zip` o dall’editor

Il menu Add plugin nella tab Plugins supporta altre tre sorgenti, ciascuna installabile in qualsiasi ambito su cui hai permessi di scrittura:

Dove si trova	Come aggiungerlo
Git repo (public o private)	From repository — inserisci `owner/repo` o un git URL, più una sottodirectory se il plugin si trova in una sottocartella. Funziona con qualsiasi repo private che Devin può raggiungere tramite la tua integrazione Git.
Non in un repo	Upload .zip — un bundle di plugin caricato viene archiviato con l’ambito e installato per tutti coloro che ne fanno parte.
Non esiste ancora	Create plugin — un editor di file con le tab Preview/Source e Version history (ogni salvataggio è una versione ripristinabile).

I plugin caricati e quelli creati possono essere modificati in un secondo momento dal relativo pannello di dettaglio. Eliminandone uno, i relativi file vengono rimossi definitivamente: non ne esiste nessun’altra copia. Non inserire secret nei file dei plugin; usa invece i riferimenti ai secret.

Dalla CLI

devin plugins install <source> aggiunge il plugin al tuo ambito personale per impostazione predefinita, così ti segue nelle sessioni cloud e sugli altri tuoi dispositivi. Usa --local per installarlo solo sulla macchina corrente. Consulta i comandi della CLI.

Lascia fare a Devin

In una sessione cloud puoi chiedere a Devin di salvare qualcosa come skill, rule, hook o MCP server personale, oppure di installare un plugin al posto tuo. Devin propone la modifica sotto forma di scheda che puoi approvare o rifiutare; le modifiche approvate vengono aggiunte al tuo ambito personale e si applicano alle sessioni future.

Come i plugin raggiungono le sessioni (sync cloud ↔ locale)

Ogni ambito si basa su un managed manifest archiviato in Devin Cloud (vedi Il manifest). L’installazione, da qualunque punto avvenga, scrive quel manifest, e ogni funzionalità lo legge:

Le sessioni cloud recuperano i manifest enterprise, organization e personal all’avvio e installano i plugin risultanti sulla machine della session, insieme ai plugin dichiarati dalle repo che clonano.
La Devin CLI e Devin Desktop recuperano gli stessi manifest quando hai effettuato l’accesso: così un plugin installato dal web compare sul tuo laptop, e devin plugins install eseguito sul laptop si riflette nella tua prossima sessione cloud. I plugin provenienti da repo private vengono recuperati con le tue credenziali git locali, quindi devi avere accesso tu stesso alla repo. Un enterprise può disattivare completamente i plugin della CLI (Devin CLI plugins nelle enterprise settings).
Gli utenti singoli (senza organizzazione) hanno solo un ambito personale.

Le session in esecuzione mantengono ciò che hanno caricato all’avvio; le modifiche hanno effetto dalla session successiva. L’installazione dei plugin e l’authentication MCP sono passaggi distinti. Collega gli MCP cloud da Customize → MCPs; per il server OAuth di un plugin in esecuzione nella CLI, usa devin mcp login. Il sync di un plugin non implica che ogni dispositivo condivida le stesse credenziali.

Indicizzazione

Devin mantiene un indice dei plugin di ogni ambito: clona la sorgente di ciascun plugin, ne legge il manifest e i contenuti, risolve le dipendenze e applica la governance. La pagina Customize mostra il risultato dell’indicizzazione — i plugin, le relative skill, MCP, hook e regole, oltre a tutto ciò che è bloccato da una policy — mentre la riga di stato indica quando ciascun ambito è stato indicizzato l’ultima volta.

Che cosa la attiva — l’installazione, la rimozione o la modifica di un plugin mette automaticamente in coda una reindicizzazione. Usa Plugin settings → Reindex plugins per aggiornare l’indice dopo aver inviato modifiche al repository sorgente di un plugin.
Durante l’esecuzione — un run può essere scheduled, queued, starting o indexing. Le reindicizzazioni frequenti vengono distanziate nel tempo e i salvataggi dei bundle caricati possono richiedere qualche istante prima di entrare in coda. Gli MCP dei plugin possono essere connessi una volta indicizzata la loro configurazione.
Risultati — apri Plugin settings (il menu a forma di ingranaggio) per vedere l’ora dell’ultima indicizzazione ed eventuali problemi. Un aggiornamento failed può lasciare visibile l’ultimo risultato riuscito: la presenza di un plugin nell’elenco non garantisce che l’ultimo aggiornamento sia andato a buon fine.
Accesso al repository — il contenuto dei plugin indicizzato da un repository viene mostrato solo in un’organizzazione che ha accesso a quel repository tramite la propria integrazione Git. In caso contrario, il contenuto dell’ambito viene trattenuto con l’avviso Plugin repos unauthorized; concedi l’accesso al repository in Settings → Repositories. La governance di un ambito trattenuto (i suoi forbid) resta comunque applicata.
Network policy — l’indicizzazione viene eseguita su una machine che eredita la network policy delle sessioni della tua organizzazione, quindi le sorgenti dei plugin devono essere raggiungibili in base a essa.

Le sessioni, invece, non attendono l’indice: recuperano e installano i plugin direttamente all’avvio.

Risolvere i problemi di indicizzazione

Apri Customize → Plugins nell’organizzazione in cui ti serve il plugin. Seleziona il relativo ambito Personal, Organization o Enterprise, quindi apri Plugin settings per leggere l’issue e il plugin o l’ambito a cui fa riferimento.
Se un run è pianificato, in coda, in avvio o in fase di indicizzazione, attendi che termini. Se il plugin non è mai stato indicizzato, oppure la sua sorgente è cambiata dall’ultima indicizzazione, scegli Reindex plugins.
In caso di run fallito o contenuto mancante, applica la soluzione corrispondente indicata sotto. Salva o esegui il commit della correzione, quindi scegli Reindex plugins e verifica di nuovo il risultato. Le modifiche a un manifest condiviso o alle autorizzazioni dei repository possono richiedere l’intervento di un admin.

Messaggio o sintomo	Cosa fare
Plugin repos unauthorized	Chiedi a un admin di concedere all’organizzazione interessata l’accesso a ogni repository indicato nell’issue, da Settings → Repositories. Un plugin enterprise può richiedere che l’accesso al repository venga concesso a più organizzazioni. Aggiungere il plugin a un manifest non concede l’accesso al repository.
Plugin source could not be cloned o Repository unavailable	Verifica l’URL del repository, il branch o il tag e il commit bloccato. Conferma che l’organizzazione disponga dell’autorizzazione di lettura sul repository, anche se compare già nell’elenco dei repository. Controlla la network policy se l’host Git non è raggiungibile. Esegui una nuova indicizzazione dopo aver corretto l’accesso o il riferimento alla sorgente.
No plugin manifest found	Verifica che la sorgente punti alla directory del plugin. Un plugin contenuto in una sottocartella richiede che tale sottodirectory sia indicata nel riferimento alla sorgente. Includi un manifest supportato nella posizione prevista.
Plugin manifest malformed, Skill malformed, MCP config malformed o un altro asset malformato	Apri il collegamento Learn more dell’issue relativo al formato pertinente. Correggi il file indicato nel repository sorgente o nell’editor del plugin caricato. Verifica i campi del manifest, il frontmatter delle skill, la MCP configuration e i percorsi relativi al plugin root.
Conflicting version pins	Esamina i manifest che richiedono il plugin. Allinea i rispettivi valori `sha`, oppure lascia che sia l’ambito con authority superiore a fornire il blocco. Vedi conflitti e dipendenze. La sola reindicizzazione non è in grado di risolvere blocchi contraddittori.
Plugin source not pinned	Si tratta di un avviso, non di un errore di indicizzazione. Il plugin segue un branch o un tag. Bloccalo su un commit se ti serve una versione fissa.
Could not load plugin contents o Indexed content unavailable	Scegli Reindex plugins per ricostruire il contenuto indicizzato. Se invece la pagina mostra Couldn’t load your configuration, usa Try again per riprovare a caricarla.
Installed but blocked	Leggi quale ambito vieta il plugin e chiedi al responsabile della policy di esaminarlo. Un ambito inferiore non può fare override di quella policy; vedi Governance.

Una volta completata l’indicizzazione, apri i dettagli del plugin e conferma che compaiano le skill, le regole, gli hook o gli MCP previsti. Se un MCP richiede ancora l’autorizzazione, completa la connessione. Per utilizzare il contenuto modificato del plugin, avvia una nuova session. Per un’installazione CLI non aggiornata, usa devin plugins update; una reindicizzazione da Customize aggiorna l’elenco sul web. Un’installazione effettuata con --local resta su quel dispositivo. Se l’indicizzazione continua a fallire, oppure un run rimane in coda o in fase di indicizzazione senza avanzare, contatta il supporto. Includi l’organizzazione e l’ambito, la sorgente e il ref del plugin, l’ora dell’ultima indicizzazione, l’errore esatto e uno screenshot dell’issue.

MCP

I server MCP si gestiscono nella tab MCPs di Customize, per gli stessi tre ambiti. La tab contiene due tipi di voci:

From plugins — server MCP dichiarati da un plugin installato. Le impostazioni di connessione (URL, transport, credenziali richieste) appartengono al plugin e sono mostrate in sola lettura; puoi comunque abilitarlo, disabilitarlo, connetterlo o disinstallarlo. La maggior parte dei plugin ufficiali del marketplace consiste in un singolo server MCP più, facoltativamente, delle skill.
Standalone — server MCP installati autonomamente: server personalizzati (Add custom MCP) e server installati dal precedente MCP marketplace, ancora raggiungibile dalla tab.

Connessione. Un MCP di un plugin che richiede una API key apre un pannello Connect con i relativi secret pronti da compilare; uno che usa OAuth apre il flusso di autorizzazione del provider; uno che non richiede né l’una né l’altro è pronto appena il plugin viene installato. Puoi connetterti dal toast di installazione, dal pannello dei dettagli del plugin o dalla riga dell’MCP. Connessioni condivise vs. per singolo member. Per un MCP OAuth installato nell’ambito organizzazione o enterprise, l’impostazione Access del server determina come viene condivisa la connessione: l’accesso organizzazione prevede un’unica connessione condivisa per tutti nell’ambito — usa un service account, non un login personale — mentre l’accesso Personal richiede che ogni member autorizzi il proprio account. Per i server senza accesso per singolo member, installa il plugin (o l’MCP) nell’ambito personale quando ogni member necessita di credenziali proprie. Se i member stanno connettendo lo stesso MCP del marketplace uno alla volta, un admin può installarlo una sola volta per l’organizzazione: i plugin che lo dichiarano useranno quella connessione. MCP enterprise. Gli enterprise admin configurano un server una sola volta — incluso un bundle di CA certificate private per il traffico MCP instradato attraverso la rete del cliente — e scelgono quali organizzazioni lo ricevono. L’installazione dello stesso server da parte di un’organizzazione fa override su quella enterprise. Per i tipi di transport, i campi dei server personalizzati e le note di setup per singolo server, consulta server MCP.

Il manifest

Dietro ogni ambito c’è un managed manifest — un documento JSON composto da tre elenchi. L’interfaccia Customize lo modifica al posto tuo; Plugin settings (icona a ingranaggio) → Edit manifest nella scheda Plugins lo espone direttamente:

{
  "requiredPlugins": ["acme/review-tools"],
  "optionalPlugins": [],
  "forbiddenPlugins": ["sketchy-org/bad-plugin", "acme/*"]
}

requiredPlugins — installati per tutti nel relativo ambito (in modo ricorsivo, inclusi eventuali plugin da cui dipendono). L’installazione dalla UI aggiunge una voce qui.
optionalPlugins — una allow-list che approva i plugin senza installarli automaticamente; usata per definire eccezioni a un elemento vietato.
forbiddenPlugins — una deny-list di identificatori di plugin o pattern glob.

Il manifest viene memorizzato testualmente; l’agente verifica la sorgente completa al momento dell’installazione. Consulta il riferimento ai plugin per le forme di sorgente che ogni voce può assumere e la semantica completa di dipendenze e governance.

Governance

I tre elenchi costituiscono il linguaggio delle policy a ogni livello — enterprise, organizzazione, repository (.devin/config.json) e personale — e prevale sempre il livello di autorità più alto: un enterprise può rendere obbligatorio un plugin che nessuna organizzazione, repo o utente può rimuovere, e vietarne uno che nessun livello inferiore può reintrodurre. Un plugin bloccato da una policy compare sotto Installed but blocked nella tab Plugins e le sue skill vengono ignorate all’avvio della sessione, con un avviso che indica chi ne ha imposto il divieto. Per limitare un enterprise a un insieme approvato, vieta "*" ed elenca i plugin approvati (e le loro dipendenze) in requiredPlugins/optionalPlugins; consulta Set up your plugin ecosystem per un esempio pratico e inheritance and levels per le regole complete.

Ambito ed ereditarietà

Gli account standalone hanno un manifest a livello di account (indicato come Organization in Customize) oltre al manifest personale di ciascun membro.
Le enterprise hanno un manifest enterprise ereditato da tutte le organizzazioni figlie, un manifest per organizzazione collocato al livello sottostante e, ancora più in basso, i manifest personali.

Come vengono distribuiti gli aggiornamenti

Le modifiche al manifest (installazioni, rimozioni, modifiche al manifest) si applicano alla sessione successiva, su ogni funzionalità.
Le modifiche ai contenuti del plugin — quando viene eseguito un merge nel branch seguito da un plugin, questo raggiunge automaticamente le nuove sessioni (le sessioni cloud lo recuperano all’avvio; la CLI si aggiorna con devin plugins update). Customize mostra i nuovi contenuti dopo il successivo run di indicizzazione: clicca Reindex plugins per recuperarli immediatamente.
Le sessioni già in esecuzione mantengono ciò che hanno caricato all’avvio: gli aggiornamenti non modificano mai una sessione mentre è in corso.

Bloccare un plugin

Un plugin indicato come "owner/repo" (o con un ref) segue un branch o un tag, quindi lo stesso manifest può risolversi in contenuti diversi nel tempo. Customize segnala queste voci come Plugin source not pinned. Per vincolare un plugin a un contenuto esatto, usa la forma a oggetto con uno sha:

{
  "requiredPlugins": [
    { "source": "github", "repo": "acme/review-tools", "sha": "3f2a9c1d8e4b7a6f5c0d1e2f3a4b5c6d7e8f9a0b" }
  ]
}

Un plugin bloccato non cambia mai finché non modifichi lo SHA. ref (un branch o un tag) e sha si escludono a vicenda: una entry non può impostarli entrambi. Gli stessi campi funzionano con le forme sorgente url e git-subdir. I plugin caricati sono sempre bloccati al contenuto che hai caricato. Se due ambiti bloccano lo stesso plugin su SHA diversi, l’index segnala un conflitto di blocco.

Variabili d’ambiente dei plugin

Aggiungi env a una voce requiredPlugins o optionalPlugins per configurare gli hook di comando nelle sessioni cloud. Per le credenziali, fai riferimento a Devin Secrets; gli altri valori possono essere stringhe letterali.

{
  "requiredPlugins": [
    {
      "source": "github",
      "repo": "acme/review-tools",
      "env": {
        "API_KEY": "secret:org:REVIEW_API_KEY",
        "REVIEW_MODE": "strict"
      }
    }
  ]
}

Avvia una nuova sessione cloud per applicare le modifiche. Le dipendenze richiedono una voce dedicata nel manifest e env.

Riferimenti supportati

secret:org:NAME
secret:enterprise:NAME
secret:personal:NAME
secret:session:NAME
secret:repo:owner/repo:NAME

Il secret deve essere disponibile nella sessione. Per un secret chiave-valore esistente, aggiungi /ENTRY, ad esempio secret:org:AWS_CREDS/ACCESS_KEY_ID. Le configurazioni MCP dei plugin fanno riferimento ai secret come ${NAME}; i membri forniscono i valori dalla scheda dei dettagli del server e qualsiasi valore letterale scritto nella configurazione viene rimosso.

Scopri di più

Plugins reference — formato dei file dei plugin, manifest, semantica di governance, comandi CLI
Set up your plugin ecosystem — crea e gestisci il tuo repo di plugin
Guida rapida: marketplace del team — da zero a un repo di plugin condiviso
Skills — le procedure SKILL.md incluse nei plugin
Server MCP — transport, server personalizzati, configurazione per singolo server

Introduzione

Guide fondamentali

Introduzione a Devin

Lavorare con Devin

Guide sul prodotto

Integrazioni

Admin

Note di rilascio

I plugin di Devin e la pagina Customize

Cosa sono i plugin?

La pagina Customize

Installazione dei plugin

Dal marketplace

Da un repository, da un file `.zip` o dall’editor

Dalla CLI

Lascia fare a Devin

Come i plugin raggiungono le sessioni (sync cloud ↔ locale)

Indicizzazione

Risolvere i problemi di indicizzazione

MCP

Il manifest

Governance

Ambito ed ereditarietà

Come vengono distribuiti gli aggiornamenti

Bloccare un plugin

Variabili d’ambiente dei plugin

Riferimenti supportati

Scopri di più

​Cosa sono i plugin?

​La pagina Customize

​Installazione dei plugin

​Dal marketplace

​Da un repository, da un file .zip o dall’editor

​Dalla CLI

​Lascia fare a Devin

​Come i plugin raggiungono le sessioni (sync cloud ↔ locale)

​Indicizzazione

​Risolvere i problemi di indicizzazione

​MCP

​Il manifest

​Governance

​Ambito ed ereditarietà

​Come vengono distribuiti gli aggiornamenti

​Bloccare un plugin

​Variabili d’ambiente dei plugin

​Riferimenti supportati

​Scopri di più

Cosa sono i plugin?

La pagina Customize

Installazione dei plugin

Dal marketplace

Da un repository, da un file `.zip` o dall’editor

Dalla CLI

Lascia fare a Devin

Come i plugin raggiungono le sessioni (sync cloud ↔ locale)

Indicizzazione

Risolvere i problemi di indicizzazione

MCP

Il manifest

Governance

Ambito ed ereditarietà

Come vengono distribuiti gli aggiornamenti

Bloccare un plugin

Variabili d’ambiente dei plugin

Riferimenti supportati

Scopri di più