Il contesto di esecuzione non è uno soltanto

Valutare il contesto di esecuzione di un agente vuol dire rispondere a tre domande prima di configurare qualunque cosa: su quale macchina gira il loop, quale filesystem e quale rete vede, con quale identità scrive su GitHub. La risposta è diversa per ognuna delle quattro superfici, e confonderle è l’errore che pesa di più.

Il Copilot cloud agent lavora in un ambiente di sviluppo effimero alimentato da GitHub Actions: lì esplora il codice, applica modifiche, esegue test e linter. Il tipo di runner è una scelta di organizzazione, sotto Settings, poi Copilot, poi Cloud agent, alla voce Runner type: con lo standard GitHub runner l’agente usa ubuntu-latest, altrimenti si compilano Runner group name e Runner label per dirottarlo su runner più grandi o su runner self-hosted che vedono risorse interne. L’interruttore Allow repositories to customize the runner type decide se un singolo repository può sovrascrivere la scelta tramite il campo runs-on del job copilot-setup-steps nel file .github/workflows/copilot-setup-steps.yml.

Quello che l’agente “sa” dell’ambiente arriva dai valori configurati come Agents secrets and variables: sono esposti all’agente come variabili d’ambiente nel suo ambiente di sviluppo, quindi utilizzabili dagli script e dagli strumenti che lancia, incluso copilot-setup-steps.yml. Due eccezioni da ricordare: i nomi con prefisso COPILOT_MCP_ sono riservati ai server MCP, e l’agente non ha accesso ai secret e alle variabili di GitHub Actions, Codespaces o Dependabot.

Le altre tre superfici stanno altrove. La Copilot CLI gira sulla tua macchina, con il local sandbox che applica una filesystem policy ispezionabile con /sandbox policy e /sandbox status e modificabile con /sandbox config; il cloud sandbox, costruito su Azure Container Apps Sandboxes, è previsto per le sessioni interattive e non per l’uso programmatico. Il Copilot SDK gira nel processo che scrivi tu. I GitHub Agentic Workflows sono file Markdown in .github/workflows/ che gh aw compile trasforma in un file .lock.yml, eseguito poi come un normale workflow di Actions.

Scope: un solo repository, un solo branch

Il perimetro del cloud agent è volutamente strettissimo, e questa è la parte che l’esame verifica più volentieri. L’agente può applicare modifiche soltanto nel repository indicato quando si avvia il task, e può lavorare su un solo branch alla volta: ha la capacità di pushare su un singolo branch, di norma un branch con prefisso copilot/ creato da lui oppure il branch di una pull request già esistente. È così che si ottiene uno scope branch-based: non c’è una chiave da attivare, il confinamento è la modalità nativa, e quello che scegli è il punto di partenza del lavoro.

Sul lato amministrativo, per impostazione predefinita gli utenti con il cloud agent abilitato possono usarlo in tutti i repository, ma amministratori e proprietari possono escludere singoli repository e impedirne l’uso. Le Automations aggiungono un vincolo di ambiente: il repository deve essere private o internal, perché nei repository pubblici non sono disponibili.

Azioni autonome: che cosa gli è permesso creare da solo

Dentro quel perimetro l’autonomia è reale: l’agente automatizza la creazione del branch, la scrittura dei messaggi di commit e il push, e apre una pull request in draft per proporre il proprio lavoro. Da qui in avanti però la catena si interrompe di proposito. L’agente non può marcare le sue pull request come Ready for review, non può approvarle né farne il merge, e le pull request in bozza devono essere riviste e unite da una persona. Solo gli utenti con accesso in scrittura al repository possono metterlo al lavoro, e i workflow di Actions non partono finché il codice non è stato rivisto e qualcuno con accesso in scrittura non clicca Approve and run workflows nella merge box.

La confusione tipica da evitare è leggere “azioni autonome” come “merge autonomo”: la certificazione chiede di distinguere fra creare un branch e una pull request in bozza da solo (permesso) e pushare sul branch predefinito o approvare e unire (impedito). Chi progetta un flusso partendo dal presupposto che l’agente possa chiudere il cerchio da sé sta progettando qualcosa che non esiste.

Invocazione in CI e vincoli d’ambiente

Per far agire un agente dentro un workflow di Actions la strada diretta è la Copilot CLI, installata come pacchetto e lanciata in modalità non interattiva. Le domande interattive vanno soppresse, altrimenti il job resta appeso: il flag --yolo serve esattamente a questo ed è richiesto negli ambienti non interattivi come GitHub Actions.

permissions:
  contents: read
  copilot-requests: write
# ...
      - run: npm install -g @github/copilot
      - run: copilot --yolo -p "Summarize the changes in this commit"
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Attenzione a cosa concedi: --yolo è sinonimo di --allow-all ed equivale a --allow-all-tools --allow-all-paths --allow-all-urls. Se il contesto lo permette, restringi con --allow-tool, --deny-tool, --allow-url, aggiungi --no-ask-user e proteggi i valori sensibili nei log con --secret-env-vars. La documentazione consiglia comunque di preferire i GitHub Agentic Workflows all’invocazione diretta della CLI in uno step run, e segnala come più rischiosi i workflow che scattano su eventi di pull request provenienti da fork.

Il vincolo d’ambiente più visibile è il firewall del cloud agent, che per impostazione predefinita limita l’accesso a Internet consentendo però sempre gli host che Copilot usa per interagire con GitHub. A livello di organizzazione sia Enable firewall sia Recommended allowlist ammettono tre stati: Enabled, Disabled e “Let repositories decide”, che è il valore predefinito. In allowlist puoi inserire domini, e in quel caso passa il traffico verso il dominio indicato e i suoi sottodomini, oppure URL, e in quel caso passa solo lo schema e l’host indicati, limitatamente al percorso specificato e ai suoi discendenti. Quando una richiesta viene bloccata compare un avviso nel corpo della pull request, o in un commento se la pull request esiste già, e l’avviso mostra l’indirizzo bloccato e il comando che ha tentato la richiesta: è il primo posto dove guardare quando un agente “non riesce a installare le dipendenze” senza una ragione apparente.