Far girare Claude Code senza supervisione, senza pentirsene

Parti dalla macchina, non dai flag

Ogni protezione qui sotto è più semplice se l’agente gira su una macchina che non contiene nient’altro. Sul tuo portatile, “consenti tutto” vuol dire la tua email, il tuo password manager, le tue credenziali di produzione e le tue foto. Su una macchina dedicata con un solo repository e un solo token limitato, “consenti tutto” vuol dire quel repository e quel token. Secondo le indicazioni della stessa Anthropic, la modalità bypass va usata in un ambiente isolato. Metti l’agente in un ambiente così e il resto di questa pagina diventa più semplice.

Le modalità dei permessi di Claude Code

Claude Code ha quattro modalità. Scegline una per ogni task, non una per sempre.

• default. Chiede prima di modificare file ed eseguire comandi shell. Giusta per il lavoro interattivo. Sbagliata per la notte.
• acceptEdits. Modifica i file nella directory di lavoro senza chiedere. Chiede ancora prima dei comandi shell. Una buona via di mezzo per i refactoring in cui giudicano i test.
• plan. Legge e ragiona ma non cambia nulla. Usala per ottenere un piano da rivedere prima dell’esecuzione vera.
• bypassPermissions. Nessuna richiesta. È la modalità senza supervisione. Usala solo su una macchina isolata, con le regole deny qui sotto già attive.

Imposta la modalità all’avvio.

claude --permission-mode acceptEdits

Oppure rendila quella predefinita di un progetto nel suo file di impostazioni. Puoi fare commit del file, così tutto il team la condivide.

// .claude/settings.json
{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

Le regole deny valgono in ogni modalità

È la parte che quasi tutti trascurano. Le regole dei permessi si sommano alla modalità, e una regola deny blocca l’azione anche in modalità bypass. Per questo le regole deny sono la vera rete di sicurezza quando nessuno guarda. Le regole allow approvano in anticipo le cose a cui diresti sempre di sì. Così l’agente non si blocca su quelle.

// .claude/settings.json
{
  "permissions": {
    "allow": [
      "Bash(npm test:*)",
      "Bash(npm run lint:*)",
      "Bash(git add:*)",
      "Bash(git commit:*)",
      "Bash(git push origin HEAD:*)"
    ],
    "deny": [
      "Bash(git push:*--force*)",
      "Bash(git push origin main:*)",
      "Bash(rm -rf:*)",
      "Bash(curl:*)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(~/.ssh/**)"
    ]
  }
}

Leggi la lista deny come una policy, perché è proprio questo. Niente force push. Niente push su main. Niente cancellazioni ricorsive. Niente richieste in uscita inventate dall’agente. Niente lettura dei file con i segreti. Adattala al tuo progetto, ma tieni una lista deny su ogni macchina senza supervisione.

Hook per le regole che un pattern non può esprimere

Alcune regole dipendono dal contesto. Un hook esegue uno script prima di una chiamata a uno strumento e può approvarla, bloccarla o modificarla. Un hook comune blocca qualsiasi comando che nomina un hostname di produzione, qualunque sia il comando.

// .claude/settings.json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "./scripts/block-prod.sh" }
        ]
      }
    ]
  }
}

Lo script legge la chiamata dallo standard input ed esce con un codice diverso da zero per bloccarla. Tieni gli hook piccoli e noiosi. Un hook che può fallire senza che nessuno se ne accorga è peggio di nessun hook.

Git è la tua protezione migliore

Le impostazioni dentro l’agente sono un livello. Il repository è un secondo livello, e non gli importa quale agente sta girando.

• Proteggi main. Per il merge richiedi una pull request e una CI verde. Così un push sbagliato non può far entrare nulla.
• Un branch per task. L’agente parte da un branch nuovo e fa push solo di quel branch.
• Dai all’agente un token che può fare push dei branch e aprire pull request, e nient’altro. Niente scope admin. Niente scope di cancellazione. Un token GitHub fine-grained limitato a un solo repository fa proprio questo.
• Giudicano i test. Se la suite fallisce, la pull request resta rossa e la vedi al mattino.

Credenziali: il minimo, e separate

Non mettere mai una credenziale personale su una macchina senza supervisione. Crea un account o un token separato per l’agente, con lo scope più piccolo che gli permette di fare il task. Staging, non produzione. Sola lettura dove basta leggere. Se l’agente deve fare login a un servizio da un browser, usa un account di test. Ruota il token quando il progetto finisce.

Esecuzioni headless con un tetto

Per un task da script, la modalità print esegue un solo prompt e poi esce. Dalle un limite di turni, così un agente confuso non può girare in tondo tutta la notte.

claude -p "Fix the failing tests in packages/api and open a PR" \
  --permission-mode acceptEdits \
  --max-turns 60

Salva l’output in un file di log. Al mattino vuoi leggere cosa ha fatto, non indovinarlo.

Le stesse regole per Codex

Codex CLI separa due domande. Quando chiede l’approvazione, e cosa può toccare. Per un task senza supervisione dentro un solo repository, la combinazione è: non chiedere mai, e scrivere solo dentro il workspace.

codex -a never -s workspace-write exec "Fix the failing tests and commit"

Codex ha anche un flag che toglie sia le approvazioni sia la sandbox. Trattalo esattamente come la modalità bypass di Claude Code. Su una macchina isolata, o per niente.

La lista del mai

Qualunque strumento usi, un agente senza supervisione non deve poter fare nessuna di queste cose. Se il tuo setup ne consente una, correggilo prima della prima notte.

• Fare push su un branch protetto o force push ovunque.
• Leggere o inviare un segreto che non gli serviva per il task.
• Toccare dati di produzione, anche solo per leggerli.
• Spendere soldi. Niente console cloud, niente pagine di pagamento, niente account pubblicitari.
• Mandare messaggi a persone. Né email, né chat, né social.
• Cancellare qualsiasi cosa fuori dal working tree.