Claude Code GitHub Actions: review e correzioni dal repository

Il vantaggio concreto è che cambia chi deve restare operativo. Prima, uno sviluppatore doveva aprire il repository, avviare Claude, riportare il risultato su GitHub e tenere attiva la sessione locale. Con un’Action, chi mantiene il progetto lascia una richiesta ben delimitata e torna a leggere un commento o una proposta di modifica. Il lavoro può partire anche fuori dall’orario di quello sviluppatore; resta comunque il tempo necessario per verificarne il risultato.

Questa guida si basa sulla documentazione corrente di Anthropic, verificata il 15 ottobre 2026. Il workflow qui sotto è una configurazione iniziale volutamente limitata: non implica che qualsiasi issue si possa risolvere senza supervisione.

Un assistente a disposizione del repository

La GitHub App è il badge di accesso, il workflow la scheda di lavoro e il runner una postazione temporanea. Un workflow è il file di configurazione che indica a GitHub quando avviare il lavoro; il runner è la macchina che lo esegue.

L’azione può rispondere alle menzioni nelle issue e nelle pull request. Se invece si fornisce un prompt, diventa un job automatico. Per un piccolo team, le richieste esplicite sono il modo più semplice per individuare le attività utili prima di pagare una revisione per ogni modifica. Utilizzo dell’azione.

Come configurare Claude Code GitHub Actions

Per l’installazione guidata serve l’accesso amministratore al repository. Dopo aver installato la GitHub CLI, autenticarla con gh auth login, aprire claude nel repository ed eseguire /install-github-app. Scegliere i workflow e l’autenticazione tramite chiave API o abbonamento, quindi creare e integrare la PR con il workflow predisposto. L’installazione avviene in locale; i job successivi vengono eseguiti su GitHub. Configurazione rapida ufficiale.

La procedura manuale porta allo stesso risultato:

1. Installare la Claude GitHub App sul repository scelto.
2. Aprire Settings → Secrets and variables → Actions nel repository e aggiungere uno dei secret di autenticazione della tabella qui sotto.
3. Copiare l’esempio funzionante di Anthropic in .github/workflows/claude.yml, scegliere l’input di autenticazione corrispondente e integrare il file.
4. Lasciare un commento con @claude e una richiesta precisa.

Sono i passaggi della procedura manuale ufficiale, con la scelta della credenziale resa esplicita. Guida alla configurazione dell’azione.

Per usare l’abbonamento, eseguire claude setup-token in locale e salvare l’output come secret. Anthropic documenta questa opzione per i piani Pro, Max, Team ed Enterprise. Il token generato dura un anno: è quindi opportuno assegnare a qualcuno la responsabilità del rinnovo. Autenticazione tramite token.

La fatturazione dipende dalla credenziale: le esecuzioni con chiave API vengono fatturate come utilizzo API; quelle con token OAuth consumano invece l’abbonamento Claude. L’uso dei runner GitHub Actions viene conteggiato separatamente. Il token di un abbonamento appartiene alla persona che lo ha generato; Anthropic consiglia una chiave API per i secret condivisi tra più repository. Autenticazione e costi.

La configurazione predefinita con l’app non richiede un token di accesso personale GitHub. L’accesso a GitHub e l’autenticazione su Claude sono distinti: il primo viene fornito dall’app, la seconda dal secret scelto. Input di autenticazione.

Partire da un workflow limitato, attivato dalle menzioni

Questo profilo è pensato per i repository di team fidati e per piccole modifiche ai file. Può leggere e modificare file ed effettuare commit tramite l’API di GitHub. Claude non dispone di uno strumento shell, quindi con questo profilo non può eseguire i comandi di test. L’esecuzione dei test resta affidata alla normale CI, cioè ai controlli automatici sulle modifiche proposte.

Salvare questa configurazione come .github/workflows/claude.yml. I riferimenti alle azioni, actions/checkout@v6 e anthropics/claude-code-action@v1, compaiono nell’esempio corrente di Anthropic. Il limite di cinque turni e il timeout di quindici minuti sono scelte iniziali di questa guida, non valori predefiniti di Anthropic. Workflow ufficiale.

name: Claude on request
on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]

jobs:
  claude:
    if: contains(github.event.comment.body, '@claude')
    runs-on: ubuntu-latest
    timeout-minutes: 15
    concurrency:
      group: claude-small-team
      cancel-in-progress: false
    permissions:
      contents: write
      issues: write
      pull-requests: write
      id-token: write
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          use_commit_signing: true
          claude_args: |
            --max-turns 5
            --tools "Read,Glob,Grep,Edit,Write"
            --disallowedTools "Bash,WebFetch,WebSearch"

Per utilizzare l’abbonamento, sostituire la riga anthropic_api_key con claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}. Indicare un solo metodo. Mantenere id-token: write, richiesto dall’autenticazione predefinita tramite GitHub App. Workflow e autenticazione ufficiali, riferimento degli input.

Ogni controllo ha una funzione diversa:

• --tools seleziona gli strumenti integrati che Claude può usare. Read, Glob e Grep servono a esaminare i file; Edit e Write a modificarli. Non limita gli strumenti MCP, collegati separatamente, che l’azione usa per comunicare con GitHub.
• --allowedTools autorizza l’uso degli strumenti indicati senza chiedere conferma. Non è un elenco completo degli unici strumenti consentiti. In questo esempio, la riga esplicita --disallowedTools vieta gli strumenti shell e web.
• --max-turns limita le iterazioni di lavoro dell’agente. Non impone un tetto ai token o alla spesa in dollari; raggiungere il limite può interrompere l’esecuzione con un errore e lasciare il lavoro incompleto. Riferimento della CLI.

use_commit_signing: true fa passare i commit dall’API di GitHub. È questo che permette al profilo di salvare le modifiche senza dare a Claude comandi git da eseguire nella shell. Non serve un secret aggiuntivo per la firma. Gli strumenti GitHub dell’azione restano disponibili: questo profilo può quindi scrivere nel repository. Firma dei commit, implementazione dell’azione.

Il gruppo di concorrenza fisso consente un solo job di questo workflow in esecuzione per repository. Con il comportamento predefinito della coda, una nuova richiesta in attesa può sostituirne una precedente ancora in attesa: non è una coda persistente di attività. Il timeout limita il tempo complessivo del job, inclusa la preparazione dell’ambiente. Concorrenza in GitHub, sintassi dei workflow.

Provare con @claude review this PR for missing permission checks; report findings without changing files. Per una issue, provare con @claude fix the null handling described above, change only the parser and its regression test, and state which checks were not run.

Per impostazione predefinita, chi attiva l’azione deve avere accesso in scrittura al repository e i bot sono bloccati. Per la correzione di una issue, il risultato atteso è un branch e un link che consente a una persona di creare la PR. Esplicitare questa distinzione nelle istruzioni del team. Sicurezza dell’azione.

Attivare le review automatiche dopo la fase di prova

Per le review automatiche delle PR, selezionare il workflow di revisione durante la configurazione con /install-github-app. Il plugin per la code review usa --comment e l’autorizzazione allo strumento di commento riportata sotto per pubblicare le segnalazioni. Esempio ufficiale di revisione.

In quel workflow di revisione separato, gli input dell’azione includono:

plugin_marketplaces: "https://github.com/anthropics/claude-code.git"
plugins: "code-review@claude-code-plugins"
prompt: "/code-review:code-review --comment ${{ github.repository }}/pull/${{ github.event.pull_request.number }}"
claude_args: >-
  --max-turns 5
  --allowedTools "mcp__github_inline_comment__create_inline_comment"

Usare questi input nel workflow ufficiale pull_request, non in quello attivato dalle menzioni mostrato sopra. Mantenere il checkout, l’autenticazione e i permessi del job previsti dall’esempio, aggiungere un timeout al job ed escludere le PR provenienti da fork con if: github.event.pull_request.head.repo.full_name == github.repository. Considerare il limite di turni un’impostazione per la fase di prova: una revisione che esaurisce i turni è incompleta. La skill di revisione documentata esclude inoltre alcune PR, tra cui quelle in bozza.

Distinguere l’accesso dell’app dai limiti degli strumenti

All’inizio, installare l’app solo sui repository selezionati. L’app ufficiale Claude condivide i permessi tra diverse funzionalità di Claude e GitHub non consente di accettarne solo una parte. Un blocco YAML permissions ridotto non restringe l’accesso concesso all’app durante l’installazione. Modello dei permessi dell’app.

Se i permessi richiesti dall’installazione sono troppo ampi, seguire la procedura per un’app personalizzata con accesso a Contents, Issues e Pull requests. Servono i secret APP_ID e APP_PRIVATE_KEY, oltre a un passaggio che genera un token dell’app e lo passa come github_token. Per i team pronti a eliminare le chiavi API statiche di Claude, la guida alla configurazione documenta anche la federazione delle identità dei carichi di lavoro, che scambia l’identità del job GitHub con un accesso API di breve durata. Configurazione dell’app personalizzata e della federazione.

Aggiungere un CLAUDE.md conciso con le priorità di revisione, le aree in cui sono consentite modifiche e le prove da allegare a una correzione. Le istruzioni orientano il lavoro; i permessi del repository e le restrizioni sugli strumenti fanno rispettare i limiti di accesso. Prima di attivare esecuzioni senza supervisione, controllare gli eventuali hook configurati, cioè i comandi eseguiti automaticamente negli eventi del ciclo di vita, e i server di strumenti aggiuntivi. Istruzioni di progetto. La nostra recensione di Claude Code aiuta a valutarlo nel complesso, mentre la guida ai comandi slash spiega i comandi usati durante la configurazione.

Sei attività da affidargli, in ordine di priorità

Conviene partire dalle richieste facili da descrivere e dai risultati facili da verificare. Quelli che seguono sono workflow proposti, non risparmi misurati né garanzie.

Il profilo iniziale non può installare dipendenze né eseguire una suite di test. Se l’attività lo richiede, aggiungere un profilo di esecuzione per codice fidato, sottoposto a una revisione separata, con autorizzazioni per comandi specifici e limiti propri. Anche un comando di test consentito esegue codice del repository: un nome rassicurante non rende sicuro quel codice.

Risolvere questi problemi prima di aggiungere altri trigger

Le PR da fork possono non avere accesso ai secret. Normalmente GitHub non rende disponibili i secret nelle esecuzioni pull_request e pull_request_review_comment attivate da un fork. In questi job, una credenziale Claude vuota riflette la separazione tra contesti fidati e non fidati. Non passare a pull_request_target eseguendo il codice del fork solo per ottenere i secret. Anche un job issue_comment attivato da un responsabile del progetto può avere accesso ai secret: fidarsi di chi commenta non significa potersi fidare dei file della PR. Indicazioni di GitHub sulla sicurezza dei fork.

Limitare gli strumenti non neutralizza il codice di avvio del progetto. L’azione ripristina alcune configurazioni di Claude dal branch di base, ma script e altri file del progetto possono comunque provenire dalla PR. Controllare gli hook e la configurazione dei server di strumenti, oltre agli strumenti consentiti a Claude. Confini di fiducia dell’azione.

Il tempo dei runner resta un vincolo separato. I runner standard ospitati da GitHub sono gratuiti per i repository pubblici. I repository privati hanno quote incluse nel piano e costi per l’utilizzo eccedente; esaurire la quota senza un metodo di pagamento può fermare i job. Controllare la pagina di utilizzo di Actions insieme ai consumi di Claude. Fatturazione di GitHub Actions.

I limiti di utilizzo possono interrompere un workflow corretto. I limiti API fissano tetti al numero di richieste e ai token di input e output elaborati ogni minuto; i token sono le porzioni di testo trattate dal modello. In caso di 429 con retry-after, attendere prima di riprovare e ridurre i job simultanei. Un 429 dovuto al tetto di spesa del livello di utilizzo, senza quell’header, richiede di intervenire sulla fatturazione o sui limiti, non di riavviare ripetutamente il job. L’autenticazione tramite abbonamento resta soggetta ai limiti di utilizzo del piano. Limiti API, limiti di utilizzo di Claude.

Un bot che non risponde e una CI che non parte sono problemi diversi. Se il bot tace, verificare che il workflow esista nel branch predefinito, che Actions sia abilitato, che il secret corrisponda al suo input e che l’autore del commento abbia accesso in scrittura. Usare la menzione completa @claude. Se non parte la CI successiva, controllare che qualcuno non abbia sostituito l’autenticazione dell’app con github_token: ${{ secrets.GITHUB_TOKEN }}: GitHub sopprime molti eventi creati da quel token e alcuni workflow delle PR richiedono un’approvazione. Comportamento del token GitHub.

Due opportunità da sviluppare attorno a questo workflow

L’opportunità più promettente è un servizio gestito di configurazione delle review per piccoli team. Il cliente è un responsabile tecnico che cerca segnalazioni utili, responsabilità chiare e limiti operativi prevedibili. Le stime DataForSEO per le ricerche in inglese negli Stati Uniti, recuperate il 15 ottobre 2026, attribuiscono ad “ai code review” 1,300 ricerche mensili. È un segnale di interesse, non un conteggio di clienti. Una prima versione vendibile potrebbe configurare un repository, tradurne le priorità di revisione in istruzioni, valutare le segnalazioni sulle PR passate e fornire un report periodico su consumi ed errori. Il rischio è la stanchezza da falsi positivi: il lavoro che mantiene valore nel tempo consiste nel preservare la qualità delle review mentre il codice cambia. Un semplice involucro attorno a un prompt generico offre pochi motivi per restare clienti.

Un’agenzia potrebbe acquistare un pacchetto riutilizzabile di regole per le review nei repository dei clienti. Nello stesso mercato, DataForSEO stima 590 ricerche mensili per “ai code review tools” e 140 per “github ai code review”. Il prodotto minimo potrebbe combinare un workflow riutilizzabile, modelli di istruzioni specifici per cliente, un registro dei responsabili delle credenziali e controlli sui limiti mancanti. Potrebbe aiutare un’agenzia a mantenere configurazioni coerenti nei passaggi di consegne. Il limite è che permessi e ambienti di test cambiano da cliente a cliente: per restare utile, un modello richiede manutenzione e valutazione. Il pubblico di queste query si sovrappone, quindi non sommare i volumi per stimare le dimensioni del mercato.

Scegliere dove eseguire il lavoro in base all’attività

Scegliere GitHub Actions quando il lavoro nasce da un evento del repository e il team vuole gestire configurazione, permessi e log insieme alla CI. Scegliere una sessione cloud per un’attività occasionale da avviare e guidare dal browser mentre il portatile è chiuso. Scegliere una routine pianificata per un’attività ricorrente salvata, come un controllo notturno del backlog, quando si preferisce affidare pianificazione e configurazione a Claude invece di mantenere un workflow YAML. Le routine supportano anche trigger GitHub e API: la sola necessità di pianificare un’attività non obbliga a usare Actions. Le routine restano in research preview. Sessioni cloud, routine.

Lunedì, far installare l’app all’amministratore del repository e integrare il workflow con i limiti previsti. Affidargli un bug noto e una richiesta di revisione mirata, poi confrontare il risultato con il giudizio del team. Ampliare i trigger solo quando i risultati giustificano l’attenzione e i consumi richiesti.

Per far configurare e mantenere questo workflow per il proprio team, richiedere supporto per l’automazione con l’AI.