Copilot CLI: installazione, prezzi e primi passi nel terminale

Come installare GitHub Copilot CLI e accedere

Installa il pacchetto npm stabile di GitHub, @github/copilot: richiede Node.js 22 o successivo. Su Windows, GitHub richiede anche PowerShell v6 o successivo. Se usi Copilot tramite la tua organizzazione, l'amministratore deve abilitare la policy di Copilot CLI. Requisiti di installazione.

Esegui questo comando nel terminale:

npm install -g @github/copilot

Se nel file ~/.npmrc è impostato ignore-scripts=true, GitHub propone questa alternativa: npm_config_ignore_scripts=false npm install -g @github/copilot. Gli altri metodi documentati sono winget install GitHub.Copilot su Windows, brew install --cask copilot-cli su macOS o Linux e curl -fsSL https://gh.io/copilot-install | bash su macOS o Linux. Il requisito di Node riguarda l'installazione tramite npm. Comandi di installazione di GitHub.

Spostati nel repository su cui vuoi lavorare e avvia copilot. Conferma che consideri attendibile la cartella, per la sessione in corso oppure anche per quelle future. Se non hai ancora effettuato l'accesso, quando richiesto digita /login all'interno di Copilot. Primo avvio.

Seleziona GitHub.com oppure il nome host della tua istanza GitHub Enterprise Cloud con residenza dei dati. Su un computer locale scegli l'accesso tramite browser; negli ambienti remoti o senza interfaccia grafica viene normalmente proposto prima il flusso con codice dispositivo. Completa l'autorizzazione nel browser, autorizza le organizzazioni interessate se usano SAML SSO e approva l'applicazione GitHub Copilot CLI. Una volta completato l'accesso, torna al terminale. Puoi avviare l'autenticazione anche dalla shell con copilot login. Istruzioni per l'autenticazione.

Se la CLI usa l'account sbagliato, controlla se sono impostate le variabili COPILOT_GITHUB_TOKEN, GH_TOKEN e GITHUB_TOKEN: i token esportati esplicitamente hanno la precedenza sull'accesso salvato. Per l'automazione, GitHub supporta un token con autorizzazioni granulari per un account personale, con il permesso di account Copilot Requests. I personal access token classici non sono supportati. Autenticazione e precedenza dei token.

Primi passi: capire il repository, correggere i test e aprire una PR

Parti da una domanda, passa a una modifica che puoi verificare e infine apri una pull request. Immagina la CLI come uno sviluppatore al tuo banco di lavoro: può esaminare il progetto e usare gli strumenti, mentre sei tu a decidere quali azioni autorizzare.

La tabella distingue i comandi da eseguire nella shell dall'input da inserire in una sessione interattiva di copilot. Tutti i comandi e i prompt riportati qui compaiono nella documentazione di GitHub. Ogni interazione con un modello consuma crediti AI; GitHub non indica un costo fisso in crediti per queste attività. Come viene conteggiato l'uso della CLI.

Capire il repository prima di modificarlo

Uno sviluppatore che entra in un progetto sconosciuto può partire dal comando della tabella dedicato alla spiegazione del repository. Nell'esempio di GitHub viene selezionato Claude Haiku 4.5: -p invia un solo prompt e poi termina l'esecuzione, -s elimina l'output aggiuntivo e --model sceglie il modello. Se quel modello non è disponibile per il tuo piano o per le policy applicate, avvia una sessione interattiva e usa /model per selezionarne uno accessibile. Gli account Free e Student usano la selezione Auto. Esempio di uso programmatico, accesso ai modelli.

Usa la spiegazione per individuare i punti di ingresso del progetto e la configurazione dei test, poi controlla personalmente quei file. Ottieni così una mappa iniziale concreta, da verificare e approfondire, senza dover esplorare le directory in modo dispersivo.

Correggere un test con un risultato verificabile

Chi mantiene un progetto con un test che fallisce può eseguire il comando di test effettivamente usato dal repository, fornire a Copilot l'output dell'errore e poi inserire il prompt interattivo della tabella. GitHub propone quel testo nel proprio flusso di sviluppo guidato dai test, dopo aver creato e rivisto test che falliscono. Se l'errore esiste già, fornisci lo stesso contesto necessario: quale test fallisce e quale comportamento deve essere preservato. Prima di accettare la modifica, esamina il diff ed esegui di nuovo il test pertinente. Flusso di lavoro di GitHub per i test.

Per un test che fallisce già in CI, cioè nei controlli automatici associati a una pull request esistente, GitHub propone /pr fix ci focus on test failures. Il comando analizza i log, applica correzioni e può effettuare il push delle modifiche: va quindi trattato come un flusso diverso dalla correzione di un test locale. Richiede una PR già aperta per il branch corrente. Correggere gli errori in CI.

Aprire una pull request dopo aver controllato le modifiche

Chi guida una startup e deve rilasciare una piccola correzione può usare /pr create dal branch di lavoro, dopo aver esaminato le modifiche e averle registrate in un commit. Devi trovarti in un repository Git ospitato su GitHub. Copilot effettua il push dei commit locali e crea la PR, seguendo il template del repository per titolo e descrizione. Se esiste già una PR per quel branch, il comando la aggiorna. Creare una pull request.

In questo modo consegni al team un lavoro pronto per la revisione attraverso il flusso GitHub che usa già. La responsabilità di ciò che contiene il branch resta tua.

Quali permessi chiede Copilot prima di eseguire i comandi?

Considerare attendibile una cartella e autorizzare uno strumento sono due decisioni distinte. Quando un'azione richiede approvazione, puoi consentirla una sola volta, autorizzare lo strumento per la sessione in corso oppure rifiutare e fornire un feedback. L'approvazione per la sessione riguarda lo strumento con le sue opzioni. Richieste di approvazione.

Le operazioni di sola lettura possono essere eseguite automaticamente; le azioni potenzialmente distruttive, la scrittura e l'accesso agli URL richiedono un'approvazione, salvo che sia già stata concessa. Alcune richieste permettono di salvare l'autorizzazione per il repository o la directory. I domini URL autorizzati in modo permanente restano consentiti anche nelle sessioni successive. Permessi salvati.

GitHub mostra questo esempio di permessi preconfigurati:

copilot --allow-tool='shell(git:*)' --deny-tool='shell(git push)'

La configurazione consente i comandi Git ma vieta il push. Le regole di divieto hanno la precedenza sulle regole di autorizzazione e sulle approvazioni salvate. /reset-allowed-tools cancella le approvazioni della sessione e quelle salvate per gli strumenti nella posizione corrente, ripristinando i permessi impostati all'avvio. Regole di autorizzazione e divieto.

--allow-all-tools autorizza tutti gli strumenti disponibili. --allow-all o --yolo autorizzano anche tutti i percorsi e gli URL. GitHub raccomanda di usare autorizzazioni così ampie in un ambiente isolato. Per le prime attività, mantieni il normale flusso di approvazione. Opzioni di autorizzazione estesa.

In quali piani è inclusa la CLI e come si paga l'utilizzo?

La CLI è inclusa in tutti i piani Copilot: Free, Student, Pro, Pro+, Max, Business ed Enterprise. Non serve aggiungere un abbonamento separato per la CLI alla licenza Copilot che hai già. Ecco i prezzi mensili e le dotazioni attuali riportati nella pagina dei piani di GitHub. Piani Copilot.

La dotazione flex è variabile: i totali attuali non sono quindi una garanzia di capacità permanente. Un credito AI equivale a $0.01 USD. Il consumo dipende dai prezzi del modello scelto e dai token di input, output e cache. Chat e CLI attingono alla stessa dotazione. Nei piani a pagamento, i completamenti del codice e i suggerimenti per la modifica successiva restano illimitati e non consumano crediti AI. Fatturazione dei piani individuali.

Per chi è già abbonato a Pro, il costo dell'abbonamento resta di $10 al mese; il lavoro dei modelli nel terminale attinge alla dotazione attuale di 1,500 crediti, condivisa con le altre attività. È questo il calcolo economico utile: prova l'accesso che hai già e valuta se la dotazione comune basta per il tuo lavoro. Gli utenti con un piano individuale a pagamento possono impostare un budget per l'utilizzo aggiuntivo, passare a un piano superiore oppure attendere il rinnovo mensile dei crediti. La tabella pubblica dei prezzi non prevede l'acquisto di crediti aggiuntivi per Free. Dotazioni individuali, limiti di acquisto del piano Free.

Nei piani Business ed Enterprise, i crediti confluiscono in un fondo comune a livello dell'entità di fatturazione. L'utilizzo aggiuntivo a pagamento è abilitato per impostazione predefinita e gli amministratori possono disattivarlo. Il budget di un utente o un limite di spesa aziendale può bloccare l'accesso anche quando resta disponibile un'altra dotazione. GitHub raccomanda CLI 1.0.48 o successiva per visualizzare correttamente fatturazione e utilizzo. Fatturazione delle organizzazioni.

Al termine di un'attività, controlla /usage per vedere i crediti consumati nella sessione e l'uso dei token del modello. In una sessione interattiva puoi impostare /limits set max-ai-credits NUMBER, sostituendo NUMBER con la dotazione che vuoi assegnare. Il minimo è di 30 crediti. La funzione è in anteprima pubblica e applica un limite flessibile: una risposta già in corso viene completata e può superarlo leggermente. Visualizzazione dell'utilizzo, limiti di sessione.

Quali modelli puoi usare con Copilot CLI?

Usa /model all'interno di Copilot per vedere le opzioni disponibili, oppure --model quando lo avvii dalla shell. La tabella attuale di GitHub relativa ai client indica questi modelli come supportati dalla CLI; il tuo piano e le policy dell'amministratore possono limitarne l'accesso. Modelli supportati.

La tabella separata di GitHub dedicata alla modalità Auto della CLI include anche GPT-6.1 Sol. Free e Student usano esclusivamente Auto. La disponibilità cambia nel tempo: controlla il selettore per conoscere le opzioni attualmente accessibili al tuo account. Disponibilità di Auto e dei modelli per piano.

Aggiungere istruzioni di progetto e strumenti MCP

Definisci le regole operative del repository prima di chiedere modifiche ricorrenti. Le istruzioni personalizzate sono file Markdown che Copilot include nel contesto. Inserisci comandi di build, comandi di test e convenzioni valide per tutto il progetto in .github/copilot-instructions.md. Per le regole che riguardano percorsi specifici, usa .github/instructions/**/*.instructions.md con i pattern applyTo. Istruzioni personalizzate.

La CLI rileva anche AGENTS.md, CLAUDE.md, .claude/CLAUDE.md e GEMINI.md. Le preferenze valide per l'utente possono essere salvate in ~/.copilot/copilot-instructions.md oppure ~/.copilot/instructions/**/*.instructions.md. Le istruzioni applicabili si combinano; GitHub non definisce un ordine generale di precedenza tra loro. Mantienile coerenti e usa /instructions per esaminare o disabilitare i file rilevati. Rilevamento e combinazione delle istruzioni.

MCP, Model Context Protocol, collega un agente a strumenti e dati esterni. Puoi immaginarlo come il collegamento di un servizio al banco di lavoro. Il server MCP di GitHub è già integrato. Per aggiungerne un altro, usa /mcp add, passa da un campo all'altro con Tab e salva con Ctrl+S. I server locali o stdio avviano un processo; quelli HTTP si collegano a un endpoint remoto. È supportato anche il precedente trasporto SSE. Aggiungere server MCP.

L'esempio di GitHub da terminale è copilot mcp add --transport http sentry https://mcp.sentry.dev/mcp. La configurazione utente si trova in ~/.copilot/mcp-config.json; per quella di progetto puoi usare .mcp.json oppure .github/mcp.json. La guida dedicata a MCP specifica che le policy configurate per il registro e la lista dei server consentiti dell'organizzazione si applicano anche alla CLI. Esempio da terminale, configurazione e policy.

Quando scegliere la CLI, l'IDE o un altro agente?

Il mio consiglio: parti da Copilot CLI se lavori già nel terminale e hai una licenza Copilot. Scegli l'estensione per l'IDE quando vuoi lavorare accanto al file che stai modificando, esaminare visivamente le modifiche e restare nell'editor. Il nostro confronto tra Cursor e GitHub Copilot aiuta a scegliere in questo caso.

Oltre alle prime attività, ci sono altre possibilità utili:

• Chi mantiene un progetto e prepara una revisione può chiedere una code review del branch di lavoro, approfondire i risultati e poi passare il diff a un revisore umano. Ne ricava una checklist mirata per la revisione, a condizione che i rilievi siano confermati dalla verifica. GitHub documenta i flussi di revisione locale. Indicazioni per la revisione.
• Uno sviluppatore che risponde ai commenti su una PR può usare /pr fix feedback, esaminare le modifiche proposte e approvare i push risultanti. Questo permette di tenere insieme le modifiche richieste e la relativa discussione. Il comando può rispondere ai thread di revisione affrontati e contrassegnarli come risolti: controllane quindi l'ambito prima di approvarlo. Gestire i commenti di revisione.

Valuta un altro agente da terminale se ti serve una dotazione diversa nell'abbonamento, un diverso accordo con il fornitore o un diverso controllo sull'agente stesso. Per la scelta d'acquisto, consulta il nostro confronto tra le alternative a Claude Code e i costi degli agenti da terminale. Prima, però, verifica se i modelli offerti da Copilot soddisfano già le tue esigenze: GitHub documenta anche l'uso di un fornitore scelto dall'utente, inclusi modelli locali compatibili. Questa opzione richiede una configurazione separata del fornitore, oltre al supporto per tool calling e streaming; è una configurazione diversa da quella che usa la dotazione Copilot. Usare un modello proprio.

Cosa potrebbe offrire un piccolo team?

Un pacchetto per orientarsi in un repository è l'opportunità iniziale più solida. Gli sviluppatori cercano “how to understand a new codebase” e “ai tool to understand codebase.” Un team potrebbe vendere ai responsabili tecnici un pacchetto mantenuto nel tempo, con note sull'architettura, istruzioni di build verificate e attività di inserimento ben delimitate. La versione minima utile dovrebbe coprire il repository del cliente e mostrare il flusso di spiegazione, test e PR. Il limite è chiaro: i prompt generici si copiano facilmente; il cliente pagherebbe per una conoscenza del progetto tenuta aggiornata.

Un flusso per preparare le revisioni è un'altra possibilità. Le ricerche “ai code review tools” e “ai powered code review platform” indicano questa esigenza. Un team potrebbe combinare istruzioni di progetto e contesto delle issue collegate per produrre un pacchetto di revisione con modifiche, evidenze dei test e domande ancora aperte. Il cliente sarebbe un responsabile di team che vuole standardizzare il passaggio del lavoro ai revisori. Il limite: i rilievi generati vanno convalidati e il flusso deve giustificare il proprio ruolo accanto alle funzioni di revisione già offerte da GitHub. Sono possibilità di prodotto, non risultati dimostrati.

Quali limiti tenere presenti?

La CLI può produrre una modifica plausibile ma sbagliata. Le indicazioni di GitHub sull'uso responsabile avvertono che l'output generato può essere inesatto o incompleto e invitano a verificare il codice e i comandi della CLI. Eseguire i test pertinenti con esito positivo ed esaminare il diff restano parte del lavoro. Uso responsabile.

L'attendibilità di una cartella non garantisce l'isolamento. GitHub descrive come euristico il meccanismo che delimita i permessi sulle directory e non garantisce la protezione di ogni file esterno a quelle attendibili. Avvia la CLI nel repository su cui intendi lavorare. Per applicare restrizioni più strette, /sandbox enable abilita il sandboxing locale degli strumenti; le sandbox locali e cloud di GitHub sono in anteprima pubblica. Directory attendibili e sandboxing.

Restano validi i limiti di accesso e di spesa. Un modello presente nella documentazione può non essere disponibile nel tuo piano o essere disabilitato da una policy. L'uso della CLI condivide i crediti con le altre attività di Copilot e il limite di sessione in anteprima può essere superato leggermente. I budget dell'organizzazione possono interrompere l'utilizzo senza un passaggio automatico a un modello meno costoso. Accesso ai modelli, limiti di sessione, effetti dei budget.

Nella prossima sessione di lavoro, scegli un test che fallisce davvero, su un branch che puoi esaminare. Fatti spiegare il codice pertinente, approva le richieste degli strumenti per la correzione, esegui di nuovo il test, controlla /usage e poi apri la PR. Avrai elementi concreti per valutare sia l'utilità del flusso di lavoro sia il consumo.

Se vuoi un flusso di lavoro per il repository costruito attorno ai controlli e agli strumenti collegati del tuo team, realizziamo automazioni AI.