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

# Gestire i mod per la vostra organizzazione

> Controllare i mod di Claude Code con impostazioni gestite: bloccare i mod installati dagli utenti, consentire solo i vostri, esaminare cosa può fare un mod e applicare la politica con il vostro mod.

Un [mod](/docs/it/plugins/mods/overview) è un plugin che esegue codice all'interno di Claude Code con i permessi dell'utente che lo ha installato. I mod non sono sandboxed. Attraverso le [impostazioni gestite](/docs/it/managed-settings), voi decidete se i mod vengono eseguiti sulle macchine dei vostri utenti, quali e in quale ordine. Potete anche installare un mod vostro che osserva o rifiuta quello che fanno gli altri mod.

Questa pagina è per la persona che distribuisce le impostazioni gestite per Claude Code, sia come file, tramite MDM, che dalla console di amministrazione di claude.ai. I mod sono attivati per impostazione predefinita in Claude Code v2.1.287 e versioni successive. Iniziate con la sezione che corrisponde a quello che siete venuti a fare:

* **Tenere fuori i mod propri degli utenti, con o senza mod vostri**: [Impedire il caricamento dei mod installati dagli utenti](#stop-user-installed-mods-from-loading)
* **Vedere cosa ottengono i vostri utenti quando non cambiate nulla**: [Sapere cosa accade per impostazione predefinita](#know-what-happens-by-default)
* **Lasciare i mod attivi con altri limiti**: [Scegliere quanto consentire](#choose-how-much-to-allow)

<Note>
  Questi casi sono trattati in altre pagine:

  * **Non avete mai distribuito impostazioni gestite prima**: iniziate con [Distribuire impostazioni gestite](/docs/it/managed-settings)
  * **Volete controllare quali plugin gli utenti possono installare**: vedere [Gestire i plugin per la vostra organizzazione](/docs/it/plugins/org)
</Note>

<h2 id="stop-user-installed-mods-from-loading">
  Impedire il caricamento dei mod installati dagli utenti
</h2>

Per impedire il caricamento di ogni mod che i vostri utenti portano, impostate l'opzione `allowManagedModsOnly` sulla [guardia incorporata](#know-what-happens-by-default), un mod di politica che Claude Code carica prima di ogni mod che un utente installa. L'opzione va nelle impostazioni gestite sotto `pluginConfigs`, con chiave `cc-plugin-sec-default@builtin`:

```json managed-settings.json theme={null}
{
  "pluginConfigs": {
    "cc-plugin-sec-default@builtin": {
      "options": {
        "allowManagedModsOnly": true
      }
    }
  }
}
```

Con l'opzione impostata nelle impostazioni gestite:

* **Nessun mod che un utente porta viene caricato**: questo copre un mod in un plugin che l'utente ha installato, un mod caricato con `--plugin-dir`, e un mod [che Claude ha scritto durante una sessione](/docs/it/plugins/mods/create#ask-claude-for-a-mod)
* **I mod della vostra organizzazione continuano a caricarsi**: un mod che [conta come della vostra organizzazione](#install-your-organizations-mods) non viene controllato. Ogni altro mod conta come di un utente e non viene caricato. Questo include un mod in un plugin che abilitate da un marketplace GitHub o altro remoto, e uno che la vostra organizzazione attiva per i suoi membri su claude.ai. Se nessuno conta come vostro, nessun mod installato viene caricato.
* **Gli utenti non possono annullarlo**: la guardia legge l'opzione solo dalle impostazioni gestite, quindi la stessa voce in un file di impostazioni utente, progetto o locale, o in un file passato con `--settings`, non cambia nulla
* **Un file o una politica MDM copre ogni provider**: quando consegnate l'opzione come file o tramite MDM, funziona allo stesso modo su Amazon Bedrock, Agent Platform di Google Cloud e Microsoft Foundry. Per la consegna dalla console di amministrazione di claude.ai, vedere [Disponibilità della piattaforma](/docs/it/server-managed-settings#platform-availability)
* **Le altre personalizzazioni degli utenti continuano a funzionare**: i loro [hook nei file di impostazioni](/docs/it/hooks), le righe di stato e `/goal` non sono interessati
* **I mod incorporati continuano a funzionare**: i mod incorporati in Claude Code, come il supporto `AGENTS.md`, hanno ciascuno [il loro interruttore](/docs/it/plugins/mods/overview#mods-built-into-claude-code)

Per confermare l'opzione sulla macchina di un utente, avviate Claude Code lì con `--plugin-dir` e il percorso di una directory che contiene un mod, come `claude --plugin-dir ./first-mod`. Gli hook del mod non vengono eseguiti, e la trascrizione e il log di debug hanno il [messaggio della guardia](/docs/it/plugins/mods/troubleshoot#messages-from-the-built-in-guard), che nomina il mod e `allowManagedModsOnly`. Se il mod viene caricato, vedere [Verificare che una politica sia in vigore](/docs/it/managed-settings#check-that-a-policy-is-in-force) e le [regole che decidono se un'opzione ha effetto](#set-options-on-the-built-in-guard).

Se avete impostato `CLAUDE_CODE_ENABLE_FUNCTION_HOOKS` a `0` durante l'accesso anticipato, sostituirlo con questa opzione. Claude Code v2.1.287 e versioni successive ignora la variabile a qualsiasi valore, quindi uno `0` lì lascia i mod attivi.

<h2 id="know-what-happens-by-default">
  Sapere cosa accade per impostazione predefinita
</h2>

Senza impostazioni mod proprie, questo è quello che i vostri utenti ottengono:

* **I mod sono attivi.** Un utente può installare un plugin che contiene un mod da qualsiasi marketplace che le vostre impostazioni di plugin consentono, o caricarne uno da una directory con `--plugin-dir`.
* **Una guardia incorporata viene eseguita per prima.** Claude Code carica un mod incorporato denominato `sec-default@builtin` prima di ogni mod che un utente installa. Gli utenti non possono disattivarla. `/plugin` e il log di debug la elencano come `cc-plugin-sec-default`. La guardia viene caricata quando una di queste è vera:

  * La macchina ha impostazioni gestite
  * L'utente è connesso a Claude Code con un piano Team o Enterprise

  Un utente che si autentica con una chiave API, o tramite Amazon Bedrock, Agent Platform di Google Cloud, o Microsoft Foundry, ottiene la guardia solo su una macchina che ha impostazioni gestite.
* **La guardia protegge quello che gestite.** Un mod di un utente non può cambiare quello che i vostri hook gestiti ricevono o decidono, il prompt di sistema, il vostro `CLAUDE.md` gestito e altre istruzioni gestite, quello che qualsiasi mod legge come impostazioni, o gli strumenti e le descrizioni dei vostri server MCP gestiti.
* **Tutto il resto è consentito.** La guardia non aggiunge altre restrizioni. Un mod di un utente può comunque leggere e scrivere file, avviare processi, fare richieste di rete, riscrivere chiamate di strumenti e prompt, negare una chiamata di strumento, approvare una che altrimenti richiederebbe un prompt, e disegnare nell'interfaccia, tutto con i permessi di quell'utente.
* **Le regole di negazione e i vostri hook gestiti hanno la precedenza.** Dove la guardia viene caricata, un mod di un utente non può approvare una chiamata che una regola `deny` rifiuta, indipendentemente da quale file di impostazioni contiene la regola. Un blocco da un hook `PreToolUse` nelle impostazioni gestite è definitivo anche. Entrambi si applicano alle chiamate di strumenti di Claude. Nessuno si applica alle chiamate proprie di un mod [`$.fs` e `$.process`](/docs/it/plugins/mods/api#reach-files-processes-and-the-network): con `Read(.env)` negato, un mod può comunque leggere quel file con `$.fs.read` o avviare un programma che lo fa. Per limitare quelle chiamate, impedire al mod di caricarsi o agganciare la chiamata in un [mod di politica](#enforce-a-policy-with-a-mod-of-your-own).
* **Altri controlli di permesso possono essere ignorati.** Un mod di un utente che approva le chiamate di strumenti può approvare una chiamata che una regola `ask` richiederebbe un prompt, o che un hook `PreToolUse` al di fuori delle impostazioni gestite ha bloccato. In modalità automatica, una chiamata che il mod approva viene eseguita senza un controllo del classificatore.

La fonte della guardia è pubblica nella [directory `mods/sec-default` del repository di Claude Code](https://github.com/anthropics/claude-code/tree/main/mods/sec-default).

<h3 id="know-which-controls-still-apply">
  Sapere quali controlli si applicano ancora
</h3>

I mod non sostituiscono i controlli che avete già:

* **Gli hook di impostazioni continuano a funzionare.** Gli hook di comando, HTTP, prompt e agente nei file di impostazioni e nel `hooks/hooks.json` dei plugin vengono eseguiti come prima, insieme ai mod. Nulla di loro è deprecato.
* **Le regole di negazione hanno la precedenza dove la guardia viene caricata.** Un mod di un utente non può approvare una chiamata che una regola `deny` rifiuta, a meno che non impostiate [`allowModsToOverrideDenyRules`](#set-options-on-the-built-in-guard).
* **Gli hook gestiti vengono eseguiti per primi.** Un hook `PreToolUse` nelle impostazioni gestite viene eseguito prima che qualsiasi mod veda la chiamata di strumento, e il suo blocco è definitivo. Se un mod poi riscrive la chiamata, i vostri hook gestiti vengono eseguiti di nuovo sulla chiamata riscritta, quindi un blocco si applica comunque. Gli hook `PreToolUse` da altri file di impostazioni e dai plugin vengono eseguiti dopo l'ultimo mod, quindi un mod che restituisce il suo proprio risultato al posto di eseguire lo strumento impedisce a quelli di funzionare. Vedere [L'ordine in cui i mod vengono eseguiti](/docs/it/plugins/mods/events#the-order-mods-run-in).
* **La politica di rete copre `$.http.fetch`.** Se la vostra organizzazione disattiva il recupero web, o il traffico di rete non essenziale è disattivato per la sessione, Claude Code rifiuta una richiesta di rete che un mod fa con `$.http.fetch`. La politica non copre un programma che il mod avvia con `$.process.run`. Quel programma raggiunge la rete con l'accesso proprio dell'utente.
* **I controlli dei plugin coprono i mod.** Un mod è un plugin, quindi le [impostazioni che limitano quello che gli utenti possono installare](/docs/it/plugins/org#restrict-what-users-can-install), come `strictKnownMarketplaces`, decidono se può essere installato affatto.
* **I mod non possono cambiare il prompt di permesso.** Un mod può ridisegnare gran parte dell'interfaccia di Claude Code, ma non il prompt di permesso, quindi non può cambiare quello che un prompt mostra. Un mod può comunque approvare o negare una chiamata di strumento prima che il prompt appaia, come [Sapere cosa accade per impostazione predefinita](#know-what-happens-by-default) descrive.
* **I prompt di fiducia vengono per primi.** In una sessione interattiva in una directory che l'utente non ha ancora fiducia, nessun mod viene caricato finché non rispondono al prompt di fiducia.
* **`--safe-mode` disattiva i mod installati, inclusi i vostri.** Avviate una sessione con `claude --safe-mode` per verificare se un mod ha causato un problema.

Nessuno di questi controlli sandboxes un mod. Un mod che consentite viene eseguito come l'utente, con l'accesso dell'utente a file, processi e la rete.

<h2 id="decide-whether-to-leave-mods-on">
  Decidere se lasciare i mod attivi
</h2>

Un mod può fare più di altre parti di un plugin perché viene eseguito all'interno di Claude Code. Vede ogni prompt e chiamata di strumento, può cambiarli, e può consentire o negare una chiamata di strumento prima che un prompt di permesso appaia.

Quello che un utente può caricare come mod dipende dai controlli dei plugin che avete già:

| I vostri controlli di plugin oggi | Quello che un utente può caricare come mod |
| :- | :- |
| Nessuno | Un mod da qualsiasi marketplace, da qualsiasi directory con `--plugin-dir`, o che Claude scrive durante una sessione |
| Una lista di consentiti del marketplace | Un mod dai marketplace che consentite, o da qualsiasi directory con `--plugin-dir`. Un mod che Claude scrive durante una sessione viene caricato solo quando la lista di consentiti [include `skills-dir`](/docs/it/plugins/org#keep-skills-directory-plugins-loading). |
| Una lista di consentiti del marketplace e `disableSideloadFlags` | Un mod dai marketplace che consentite |

[Gestire i plugin per la vostra organizzazione](/docs/it/plugins/org) elenca ogni modo in cui un plugin viene caricato e l'impostazione che controlla ciascuno.

Per controllare i mod in un marketplace prima che i vostri utenti li installino, vedere [Esaminare cosa può fare un mod](#review-what-a-mod-can-do). Per tenere fuori i mod degli utenti finché non lo avete fatto, vedere [Impedire il caricamento dei mod installati dagli utenti](#stop-user-installed-mods-from-loading).

<h3 id="review-what-a-mod-can-do">
  Esaminare cosa può fare un mod
</h3>

Potete vedere cosa un mod è in grado di fare senza eseguirlo. Nel vostro shell, eseguite `claude plugin validate` sulla directory del plugin:

```bash theme={null}
claude plugin validate ./some-mod
```

Due righe nell'output descrivono il codice del mod:

```text theme={null}
  ❯ ./register.js hooks: session.start, tool.call, ui.render{component=Pane}
  ❯ ./register.js calls: $.fs.read, $.http.fetch, $.store.set, $.ui.open
```

La riga `hooks:` elenca gli eventi che il mod riceve. La riga `calls:` elenca i metodi dell'API dei mod che il suo codice chiama. L'[API dei mod](/docs/it/plugins/mods/api), scritta `$` nel codice di un mod, è come un mod raggiunge file, processi e la rete. Claude Code rifiuta di caricare un mod che usa l'API dei mod in un modo che questo comando non può leggere.

Guardate la riga `calls:` per questi:

| Chiamata | Cosa significa |
| :- | :- |
| `$.fs.read`, `$.fs.write` | Legge o scrive file ovunque l'utente possa |
| `$.process.run`, `$.process.spawn` | Avvia programmi come l'utente |
| `$.http.fetch` | Fa richieste di rete |
| `$.env.get`, `$.settings.read` | Legge variabili di ambiente e impostazioni, che possono contenere chiavi API. Una riga `env reads:` nell'output nomina ogni variabile. |
| `$.env.set` | Imposta una variabile di ambiente per Claude Code e per ogni comando e server MCP che avvia dopo, che può cambiare quello che quei programmi eseguono. Una riga `env writes:` nomina ogni variabile. |
| `$.mcp.call` | Chiama uno strumento su un server MCP connesso, secondo le regole di permesso della sessione |
| `$.model.complete` | Usa il piano o la chiave API dell'utente per le chiamate di modello |
| `$.prompt.submit` | Invia un prompt, e può inviarlo come le proprie parole dell'utente |
| `$.session.send` | Invia un messaggio che un'altra sessione o subagent di Claude legge |

Nella riga `hooks:`, [`tool.call`](/docs/it/plugins/mods/reference#tools) e [`prompt.submit`](/docs/it/plugins/mods/reference#prompts-and-what-claude-reads) significano che il mod vede ogni chiamata di strumento e ogni prompt, e può cambiarli. [`session.append`](/docs/it/plugins/mods/reference#session) significa che il mod può riscrivere ogni riga della conversazione prima che sia archiviata. [`ui.render{component=AskUserQuestion}`](/docs/it/plugins/mods/interface#change-what-claude-code-already-draws) significa che il mod può ridisegnare il dialogo che Claude usa per chiedere all'utente una domanda. `tool.check` significa che il mod può approvare o negare una chiamata di strumento prima che un prompt di permesso appaia. [Sapere cosa accade per impostazione predefinita](#know-what-happens-by-default) elenca quale dei vostri regole e hook ha la precedenza sulla sua risposta.

<h2 id="choose-how-much-to-allow">
  Scegliere quanto consentire
</h2>

Le politiche dei mod vanno da nessun mod installato affatto a qualsiasi mod che un utente sceglie, con il vostro mod che controlla gli altri, e ognuna è poche impostazioni gestite. Trovate la politica che volete nella prima colonna e impostate quello che la seconda colonna nomina. [Distribuire impostazioni gestite](/docs/it/managed-settings) copre dove vivono le impostazioni gestite.

| Quello che volete | Impostazioni |
| :- | :- |
| Nessun mod installato, con hook intatti | Impostate [`allowManagedModsOnly`](#set-options-on-the-built-in-guard) e non distribuite mod vostri |
| Nessun mod installato e nessun hook affatto, inclusi i vostri hook gestiti | Impostate `disableAllHooks` a `true` |
| Solo i mod della vostra organizzazione | Impostate l'opzione [`allowManagedModsOnly`](#stop-user-installed-mods-from-loading) della guardia, e [installate i vostri mod](#install-your-organizations-mods) in modo che contino come vostri |
| Qualsiasi mod dai marketplace che approvate | Mantenete le vostre [restrizioni del marketplace](/docs/it/plugins/org#restrict-what-users-can-install), e impostate `disableSideloadFlags` a `true` |
| Qualsiasi mod, con il vostro mod che controlla gli altri | [Installate il vostro mod](#install-your-organizations-mods), e elencatelo con `sec-default@builtin` in `prependPlugins` |

Quello che ogni impostazione fa:

* **`allowManagedModsOnly`**: un'opzione sulla guardia incorporata. I mod propri degli utenti non vengono caricati, e i loro hook di impostazioni, righe di stato e `/goal` continuano a funzionare. [Impedire il caricamento dei mod installati dagli utenti](#stop-user-installed-mods-from-loading) elenca quello che copre.
* **`allowManagedHooksOnly`**: un'impostazione più ampia. Solo i [mod della vostra organizzazione](#install-your-organizations-mods) e i mod incorporati in Claude Code vengono caricati. Un mod che un utente ha installato da solo non lo fa. L'impostazione blocca anche gli hook nei file di impostazioni propri degli utenti. Leggete [Quello che viene eseguito sotto `allowManagedHooksOnly`](/docs/it/settings-reference#what-runs-under-allowmanagedhooksonly) prima di impostarla.
* **`disableAllHooks`**: l'impostazione più ampia. Nelle impostazioni gestite, ferma i mod in ogni plugin installato, incluso il vostro, e disattiva ogni hook nei file di impostazioni, quindi un hook `PreToolUse` nelle vostre impostazioni gestite non blocca più nulla. Le righe di stato personalizzate e `/goal` smettono di funzionare anche. Leggete [`disableAllHooks`](/docs/it/settings-reference#disableallhooks) prima di impostarla.
* **`disableSideloadFlags`**: rifiuta `--plugin-dir` e `--plugin-url` all'avvio, quindi nessuno carica un mod da una directory, e impedisce ai mod che Claude scrive durante una sessione di caricarsi. L'impostazione rifiuta anche `--agents` e `--mcp-config`. Leggete [`disableSideloadFlags`](/docs/it/settings-reference#disablesideloadflags) prima di impostarla.

I mod incorporati in Claude Code, come il supporto `AGENTS.md`, non sono interessati da queste impostazioni. Ognuno ha [il suo interruttore](/docs/it/plugins/mods/overview#mods-built-into-claude-code).

Un utente il cui mod non è stato caricato trova il motivo nel suo log di debug. [Messaggi di rifiuto](/docs/it/plugins/mods/troubleshoot#refusal-messages) elenca le righe per `allowManagedHooksOnly` e `disableAllHooks`, e [Messaggi dalla guardia incorporata](/docs/it/plugins/mods/troubleshoot#messages-from-the-built-in-guard) ha la riga per `allowManagedModsOnly`.

<h3 id="set-options-on-the-built-in-guard">
  Impostare le opzioni sulla guardia incorporata
</h3>

La guardia incorporata accetta due opzioni. Impostatele nelle impostazioni gestite sotto `pluginConfigs`, con chiave `cc-plugin-sec-default@builtin`, come l'esempio in [Impedire il caricamento dei mod installati dagli utenti](#stop-user-installed-mods-from-loading) fa.

La tabella dà quello che i vostri utenti ottengono con ogni opzione non impostata e con essa impostata a `true`:

| Opzione | Non impostata | `true` |
| :- | :- | :- |
| `allowManagedModsOnly` | I mod propri degli utenti vengono caricati | Solo i [mod della vostra organizzazione](#install-your-organizations-mods), e i mod incorporati in Claude Code, vengono caricati. Claude Code rifiuta ogni altro mod, incluso uno che un utente ha installato o nominato con `--plugin-dir`. |
| `allowModsToOverrideDenyRules` | Le regole di negazione hanno la precedenza sui mod degli utenti | Un mod di un utente che approva le chiamate di strumenti può approvare una chiamata che una regola `deny` rifiuta |

Queste regole decidono se un'opzione ha effetto:

* **L'id ha una sola ortografia qui**: Claude Code legge le opzioni solo sotto `cc-plugin-sec-default@builtin`. `prependPlugins` accetta anche `sec-default@builtin`, e `pluginConfigs` no.
* **Solo le impostazioni gestite contano**: la stessa voce in un file di impostazioni utente, progetto o locale, o in un file passato con `--settings`, né imposta un'opzione né ne allenta una
* **La guardia deve caricarsi**: se impostate `prependPlugins`, [nominate la guardia nella lista](#install-your-organizations-mods). Dove la guardia non viene caricata, nessuna opzione si applica.
* **La guardia fallisce chiusa**: se la guardia non può leggere le impostazioni gestite, rifiuta ogni mod di un utente al caricamento. Se non può controllare le regole di negazione per una chiamata che un mod di un utente ha approvato, rifiuta la chiamata.

I [messaggi dalla guardia incorporata](/docs/it/plugins/mods/troubleshoot#messages-from-the-built-in-guard) sono quello che i vostri utenti vedono quando una delle due opzioni si applica.

<h2 id="run-your-organization’s-own-mods">
  Eseguire i mod propri della vostra organizzazione
</h2>

Potete distribuire mod vostri a ogni utente, scegliere dove vengono eseguiti rispetto ai mod degli utenti, e usarne uno per applicare una politica.

<h3 id="install-your-organizations-mods">
  Installare i mod della vostra organizzazione e impostare l'ordine
</h3>

I mod della vostra organizzazione vengono caricati dove i mod degli utenti non lo fanno e possono essere eseguiti prima di loro, quindi Claude Code deve essere in grado di dire che un mod viene da voi. Lo tratta come della vostra organizzazione solo quando tutti questi sono veri:

* Le impostazioni gestite `enabledPlugins` impostano il plugin del mod a `true`
* Le impostazioni gestite nominano il [marketplace](/docs/it/plugins/create-marketplace) del plugin come una directory sulla macchina dell'utente, per percorso assoluto. Una voce `extraKnownMarketplaces` fa questo e registra il marketplace per l'utente anche.
* Il marketplace elenca il plugin per un percorso relativo, quindi Claude Code lo [carica in place](/docs/it/plugins/loading#in-place-and-copied-plugins) da quella directory

Per soddisfarli, fate in modo che la vostra gestione dei dispositivi copi la directory del marketplace allo stesso percorso su ogni macchina. Rendete la directory e ogni directory sopra di essa scrivibile solo da un amministratore, come il file di impostazioni gestite. Chiunque possa scrivere lì può riscrivere il vostro mod. Le impostazioni gestite che consegnate dalla console di amministrazione di claude.ai possono portare le chiavi, ma non possono mettere la directory su una macchina.

La directory contiene il manifesto del marketplace e il plugin:

```text theme={null}
/opt/acme/claude-plugins/
├── .claude-plugin/
│   └── marketplace.json
└── plugins/
    └── acme-guard/
        ├── .claude-plugin/
        │   └── plugin.json
        └── hooks/
            ├── hooks.json
            └── register.js
```

Il manifesto elenca il plugin per il suo percorso relativo a quella directory:

```json /opt/acme/claude-plugins/.claude-plugin/marketplace.json theme={null}
{
  "name": "acme-tools",
  "owner": { "name": "Acme" },
  "plugins": [
    { "name": "acme-guard", "source": "./plugins/acme-guard", "description": "Acme policy mod" }
  ]
}
```

Un plugin che Claude Code copia nella sua cache conta come di un utente, anche quando le impostazioni gestite `enabledPlugins` lo abilitano. Questo copre ogni plugin da una fonte GitHub, git, URL o npm. Il suo mod viene eseguito tra i mod degli utenti, `prependPlugins` e `appendPlugins` lo saltano, e non viene caricato sotto `allowManagedModsOnly` o `allowManagedHooksOnly`. Il log di debug dell'utente ha una riga che inizia con l'id del plugin e `is enabled by managed settings, but`.

Claude Code genera un evento ogni volta che sta per agire, come eseguire uno strumento, e lo passa a ogni mod a turno. Un mod che conta come vostro [viene eseguito prima dei mod degli utenti](/docs/it/plugins/mods/events#the-order-mods-run-in) anche quando non lo elencate da nessuna parte. Per impostare il suo posto, elencate il suo id in una di due impostazioni. L'id è il nome del plugin, `@`, e il nome del marketplace, come `acme-guard@acme-tools`.

* **`prependPlugins`**: il vostro mod vede ogni evento prima di qualsiasi mod di un utente e ogni risultato dopo. Può cambiare l'evento, rifiutarlo, o saltare i mod degli utenti.
* **`appendPlugins`**: il vostro mod viene eseguito dopo ogni mod di un utente, quindi vede solo gli eventi che quei mod passano, nella forma che li passano

Questo esempio dichiara il marketplace `acme-tools` a `/opt/acme/claude-plugins`, abilita `acme-guard` da esso, e esegue quel mod per primo, con la guardia incorporata dopo:

```json managed-settings.json theme={null}
{
  "extraKnownMarketplaces": {
    "acme-tools": {
      "source": { "source": "directory", "path": "/opt/acme/claude-plugins" }
    }
  },
  "enabledPlugins": { "acme-guard@acme-tools": true },
  "prependPlugins": ["acme-guard@acme-tools", "sec-default@builtin"]
}
```

Ogni chiave fa un lavoro:

* **`extraKnownMarketplaces`**: nomina la directory che contiene il marketplace `acme-tools`. `path` è il percorso assoluto della directory che contiene `.claude-plugin/marketplace.json`.
* **`enabledPlugins`**: attiva `acme-guard` per ogni utente che riceve queste impostazioni gestite
* **`prependPlugins`**: mette `acme-guard` per primo e la guardia incorporata per secondo, entrambi prima di qualsiasi mod che un utente installa. Claude Code segue l'ordine che elencate.

Per confermare che la macchina di un utente ha ricevuto le impostazioni, vedere [Verificare che una politica sia in vigore](/docs/it/managed-settings#check-that-a-policy-is-in-force).

Per confermare dove il mod viene eseguito, avviate una sessione su quella macchina con `claude --debug` e cercate nel [log di debug](/docs/it/plugins/mods/troubleshoot#read-the-debug-log) l'id del mod:

* **`hooks module acme-guard@acme-tools loaded`, con `tier prepend`**: il mod conta come della vostra organizzazione e viene eseguito per primo
* **La stessa riga con `tier user`**: Claude Code lo tratta come un mod di un utente. Una seconda riga, `prependPlugins names acme-guard@acme-tools, which is not an enabled managed plugin with a hooks module; skipped`, dice che la lista lo ha saltato.

Queste regole decidono quali id nelle due liste hanno effetto:

* **La lista sostituisce il valore predefinito**: quando impostate `prependPlugins` nelle impostazioni gestite, nominate `sec-default@builtin` in essa per mantenere la guardia incorporata. La guardia è incorporata e non ha bisogno di una voce `enabledPlugins`.
* **I vostri id devono contare come vostri**: nelle impostazioni gestite, Claude Code salta un id il cui plugin non soddisfa le tre condizioni per un mod di un'organizzazione
* **I repository non possono impostarli**: Claude Code legge entrambe le impostazioni dalle impostazioni gestite e mai da un file di impostazioni di un repository. Un utente può impostarli in `~/.claude/settings.json` per ordinare i loro mod propri solo su una macchina senza impostazioni gestite, e solo quando non sono connessi con un piano Team o Enterprise. Ovunque altro, Claude Code ignora entrambe le chiavi nelle impostazioni dell'utente. Una lista lì né aggiunge né rimuove la guardia incorporata.

<h3 id="enforce-a-policy-with-a-mod-of-your-own">
  Applicare una politica con un mod vostro
</h3>

Per tenere fuori ogni mod di un utente, non avete bisogno di un mod vostro. Impostate [`allowManagedModsOnly`](#stop-user-installed-mods-from-loading). Scrivete un mod di politica quando volete ammettere alcuni mod degli utenti e rifiutarne altri, o per registrare quello che i mod fanno.

Ogni volta che un altro mod sta per caricarsi, il vostro mod riceve la lista che `claude plugin validate` stampa, in un evento denominato [`plugin.register`](/docs/it/plugins/mods/reference#other-mods). Un mod in `prependPlugins` può leggere quella lista e rifiutare il mod. Può anche [agganciare qualsiasi chiamata dell'API dei mod per nome](/docs/it/plugins/mods/api#reach-files-processes-and-the-network) per registrare o rifiutare quella chiamata per ogni altro mod. Il nome è il metodo senza il `$.`, quindi un aggancio su `fs.write` vede ogni chiamata `$.fs.write`.

Questo mod di politica rifiuta qualsiasi mod di un utente il cui codice proprio chiama `$.process.run` o `$.process.spawn`. Mantiene anche un log di audit, scrivendo ogni chiamata di strumento e ogni file che un mod scrive nel log di debug. Poiché viene eseguito per primo, il log registra quello che è stato richiesto, prima che qualsiasi mod di un utente lo cambi. Salvate come `acme-guard/hooks/register.js`:

```javascript acme-guard/hooks/register.js theme={null}
// I metodi che nessun mod di un utente può chiamare, ognuno scritto namespace.method
const BLOCKED_CALLS = ['process.run', 'process.spawn']

export function register(on) {
  // Viene eseguito ogni volta che un altro mod sta per caricarsi
  on('plugin.register', async ($, e, next) => {
    // Mantieni le chiamate in quel mod il cui codice è sulla lista bloccata
    const blocked = e.uses.calls.filter((call) => BLOCKED_CALLS.includes(call))
    if (e.tier === 'user' && blocked.length > 0) {
      // Restituire refuse impedisce al mod di caricarsi, e il testo è il motivo
      return { refuse: 'Acme policy: mods may not call ' + blocked.join(', ') }
    }
    // Lascia caricare ogni altro mod
    return next(e)
  })

  // Registra ogni chiamata di strumento, poi lasciala andare avanti invariata
  on('tool.call', async ($, e, next) => {
    $.ui.log('audit tool.call ' + e.tool, { to: 'debug' })
    return next(e)
  })

  // Registra quale mod ha scritto un file, poi il percorso, tra virgolette perché il mod lo ha scelto
  on('fs.write', async ($, e, next) => {
    $.ui.log('audit fs.write by ' + next.origin.plugin + ' ' + JSON.stringify(e.path), { to: 'debug' })
    return next(e)
  })
}
```

Il file registra tre hook:

* **`plugin.register`**: decide se un altro mod viene caricato. Rifiuta un mod di un utente che chiama un metodo bloccato e passa ogni altro mod.
* **`tool.call`**: scrive una riga come `audit tool.call Bash` nel log di debug per ogni chiamata di strumento, e non cambia nulla
* **`fs.write`**: scrive una riga come `audit fs.write by reader "/tmp/notes.md"` per ogni chiamata `$.fs.write` che un altro mod fa, e non cambia nulla. Il nome del mod viene per primo e il percorso è tra virgolette, quindi un percorso che un mod sceglie non può passare per un altro campo della riga.

L'hook `plugin.register` legge due campi dell'evento:

* **`e.tier`**: dove il mod verrebbe eseguito, uno di `prepend`, `user`, `append`, o `builtin`. Ogni mod che una persona installa è `user`.
* **`e.uses.calls`**: i metodi dell'API dei mod che il mod chiama, ognuno scritto `namespace.method` come `process.run`, senza il `$.` che `claude plugin validate` stampa

Quando un utente installa un mod che chiama `$.process.run`, il mod non viene caricato, e il suo log di debug ha una riga che termina con `refused by acme-guard:` e il vostro motivo. Il rifiuto raggiunge anche la trascrizione in una [sessione che ricarica a caldo una directory di plugin](/docs/it/plugins/mods/troubleshoot#find-out-why-a-mod-does-nothing). Per bloccare una chiamata senza rifiutare l'intero mod, restituite `{ deny: 'your reason' }` da un aggancio sul nome di quella chiamata.

Per inviare le righe di audit da qualche parte diversa dal log di debug, chiamate `$.http.fetch` dagli stessi hook.

Una sessione può funzionare senza il vostro mod. Se il thread di lavoro che esegue i mod installati [si arresta tre volte](/docs/it/plugins/mods/troubleshoot#mods-that-run-in-the-hooks-worker-are-off-for-this-session), Claude Code scarica ogni mod che non è incorporato, incluso il vostro, finché l'utente non esegue `/reload-plugins` o non avvia una nuova sessione. E un utente che avvia Claude Code con `--safe-mode` viene eseguito senza mod installati, incluso il vostro.

[Creare un mod](/docs/it/plugins/mods/create) copre i file che un mod ha bisogno. [Testare un mod che giudica altri mod](/docs/it/plugins/mods/test#test-a-mod-that-judges-other-mods) ha un file di test per questo mod di politica.

<h4 id="refuse-mods-when-your-check-fails">
  Rifiutare i mod quando il vostro controllo fallisce
</h4>

Se il vostro hook `plugin.register` genera un'eccezione o supera il suo limite di tempo, Claude Code salta l'hook, quindi il controllo fallisce aperto e il mod che stava controllando viene caricato. Per fallire chiuso e rifiutare i mod degli utenti, spostate il controllo in una funzione denominata e aggiungete un gestore `.catch` che restituisce il rifiuto. Questa versione del file mostra solo l'hook `plugin.register`, quindi mantenete i due hook di audit dalla prima versione in `register`:

```javascript acme-guard/hooks/register.js theme={null}
const BLOCKED_CALLS = ['process.run', 'process.spawn']

// Lo stesso controllo di prima, spostato in una funzione propria
async function checkMod($, e, next) {
  const blocked = e.uses.calls.filter((call) => BLOCKED_CALLS.includes(call))
  if (e.tier === 'user' && blocked.length > 0) {
    return { refuse: 'Acme policy: mods may not call ' + blocked.join(', ') }
  }
  return next(e)
}

export function register(on) {
  // Il gestore viene eseguito solo quando checkMod genera un'eccezione o supera il suo limite di tempo
  on('plugin.register', checkMod).catch(async ($, e, next) => {
    // Lascia caricare i mod della vostra organizzazione e i mod incorporati
    if (e.tier !== 'user') return next(e)
    // Rifiuta il mod dell'utente che non poteva essere controllato
    return { refuse: 'Acme policy check failed, so this mod was not loaded' }
  })
}
```

Con il gestore in place, un mod che stava per essere controllato quando il controllo ha generato un'eccezione o ha superato il tempo limite non viene caricato, e la riga di rifiuto porta il secondo motivo, come in `refused by acme-guard: Acme policy check failed, so this mod was not loaded`. Il gestore passa ogni mod al di fuori del tier `user` a `next(e)`, quindi un controllo fallito non ferma i mod che la vostra organizzazione elenca. [Gestire un hook che fallisce](/docs/it/plugins/mods/events#handle-a-hook-that-fails) copre `.catch` per altri eventi.

<h2 id="next-steps">
  Prossimi passi
</h2>

* [Sicurezza dei plugin](/docs/it/plugins/security): quello che qualsiasi plugin può fare sulla macchina di un utente, e come esaminarne uno prima che sia installato
* [Panoramica dei mod](/docs/it/plugins/mods/overview): cosa è un mod e come si confronta con hook, skills e server MCP
* [L'ordine in cui i mod vengono eseguiti](/docs/it/plugins/mods/events#the-order-mods-run-in): come `prependPlugins` e `appendPlugins` si adattano ai mod degli utenti
* [Impostazioni e variabili di ambiente](/docs/it/plugins/mods/reference#settings-and-environment-variables): ogni impostazione nominata su questa pagina in una tabella