#vscode

Il problema che Agent Plugins 1.0 prova a risolvereChi lavora quotidianamente con #GitHub #Copilot conosce bene la frammentazione degli ultimi due anni: skill scritte per VS Code che non funzionano su Copilot CLI, configurazioni #MCP duplicate tra client diversi, agenti custom da ricostruire da zero ogni volta che si cambia strumento. Con Agent Plugins 1.0, annunciato a metà agosto 2026, GitHub prova a chiudere questa frammentazione introducendo uno standard aperto — non un formato proprietario — per pacchettizzare skill e server MCP in un plugin installabile una sola volta e utilizzabile su più superfici: VS Code, Copilot CLI, Copilot SDK, l’app Copilot e il coding agent #cloud.

È un cambio di prospettiva interessante anche per chi non #usa Copilot come strumento principale: la specifica Agent Plugins non è un’invenzione isolata, ma converge con formati simili già visti in altri ecosistemi (Claude, OpenPlugin), e questo la rende rilevante per chiunque costruisca strumenti per agenti AI, non solo per i team Microsoft/GitHub.

Anatomia di un Agent PluginUn plugin conforme allo standard 1.0 è una directory con una struttura riconoscibile. Il file centrale è plugin.json, che dichiara esplicitamente lo schema a cui aderisce:

{
"$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
"name": "my-dev-tools",
"description": "Utility per lo sviluppo React",
"version": "1.2.0"
}I soli campi obbligatori sono $schema e name; tutto il resto (version, description, author, homepage, repository, license, keywords) è opzionale ma consigliato per la pubblicazione su un marketplace.

Attorno al manifest, la struttura tipica di un plugin più completo è questa:

my-testing-plugin/
plugin.json # Metadati del plugin
skills/
test-runner/
SKILL.md # Istruzioni della skill
run-tests.sh # Script di supporto
agents/
test-reviewer.agent.md # Agente custom (client-specific)
hooks/
hooks.json # Configurazione hook (client-specific)
scripts/
validate-tests.sh
.mcp.json # Definizione dei server MCPLa distinzione più importante per chi progetta un plugin è tra componenti portabili e componenti client-specific:

Portabili (parte dello standard 1.0): server MCP (integrazioni con tool esterni) e skill, cioè istruzioni, script e risorse caricate on-demand dall’agente.

Client-specific (solo VS Code, ad esempio): agenti custom con personalità e configurazione tool dedicata, hook che eseguono comandi shell in punti precisi del ciclo di vita dell’agente, e slash command richiamabili in chat con /.

Questa separazione è la vera innovazione pratica: uno stesso plugin può portare le sue skill e i suoi server MCP ovunque, mentre le personalizzazioni specifiche di un client restano lì dove hanno senso, senza rompere la compatibilità altrove.

Configurare i server MCP dentro un pluginI server MCP si dichiarano in .mcp.json (o mcp.json), con variabili d’ambiente che il runtime dell’agente risolve automaticamente al momento del caricamento:

{
"mcpServers": {
"plugin-database": {
"command": "${PLUGIN_ROOT}/servers/db-server",
"args": ["--config", "${PLUGIN_ROOT}/config.json"],
"env": {
"DB_PATH": "${PLUGIN_ROOT}/data"
}
}
}
}La variabile ${PLUGIN_ROOT} punta sempre alla directory del plugin installato, indipendentemente da dove l’utente finale lo abbia scaricato — un dettaglio che elimina un’intera classe di bug legati a percorsi assoluti hardcoded nei plugin distribuiti da terze parti.

Hook: automazioni sul ciclo di vita dell’agentePer i client che supportano questa estensione (il formato è compatibile con la sintassi già nota da Claude), gli hook permettono di agganciare comandi shell a eventi specifici, ad esempio dopo l’uso di un tool:

{
"hooks": {
"PostToolUse": [
{
"type": "command",
"command": "${PLUGIN_ROOT}/scripts/format.sh"
}
]
}
}Un caso d’uso concreto: formattare automaticamente il codice generato dall’agente subito dopo ogni modifica a un file, senza dover ricordare di lanciare il linter manualmente.

Migrare un plugin Copilot esistenteChi ha già plugin Copilot “vecchio formato” non deve riscrivere nulla da zero. GitHub descrive un percorso di migrazione minimo:

Aggiungere il campo $schema al plugin.json esistente, puntandolo allo schema Agent Plugins 1.0.

Mantenere le skill dove sono già, sotto skills/.

Spostare i file specifici di Copilot (agenti, comandi, regole, hook, canvas) dentro una directory dedicata com.github.copilot/, così da separarli chiaramente dalla parte portabile.

I plugin GitHub Copilot esistenti restano comunque supportati senza obbligo di migrazione: è un aggiornamento incrementale, non un breaking change forzato.

Governance aziendale: managed-settings.jsonPer i team enterprise, probabilmente l’aspetto più rilevante non è la portabilità in sé ma il controllo centralizzato che ne deriva. Il file managed-settings.json permette di definire una baseline aziendale su cosa è installabile:

{
"extraKnownMarketplaces": {
"company-tools": {
"source": { "source": "github", "repo": "vostra-org/plugin-marketplace" }
}
},
"enabledPlugins": {
"code-formatter@company-tools": true
}
}Tre leve principali:

enabledPlugins — installa automaticamente o blocca esplicitamente plugin specifici per tutti gli utenti gestiti.

extraKnownMarketplaces — aggiunge marketplace interni oltre a quelli pubblici di default.

strictKnownMarketplaces — se attivato, limita l’installazione ai soli marketplace esplicitamente autorizzati, impedendo l’uso di sorgenti non gestite.

Le impostazioni enterprise agiscono come baseline additiva: i team possono comunque aggiungere plugin approvati sopra la configurazione centrale, senza però poter aggirare i blocchi imposti a livello organizzativo. Per chi gestisce flotte di sviluppatori con policy di sicurezza stringenti, è la differenza tra “confidare che ognuno installi solo cose sicure” e avere un controllo verificabile.

Dove si installano i pluginIl canale di scoperta di default è l’Awesome Copilot marketplace, disponibile fin da subito in VS Code, Copilot CLI e nell’app Copilot. Per plugin locali o in sviluppo, VS Code offre una registrazione esplicita via impostazioni:

"chat.pluginLocations": {
"/percorso/al/mio-plugin": true,
"/percorso/a/un-altro-plugin": false
}Un dettaglio utile in fase di debug: se un plugin non viene rilevato, vale la pena controllare che chat.plugins.enabled sia attivo, che il nome nel manifest sia in kebab-case (obbligatorio per lo standard 1.0), e — per problemi di installazione persistenti — ripulire la cache locale in ~/.config/Code/agentPlugins/ su #Linux.

ConclusioneAgent Plugins 1.0 non introduce funzionalità radicalmente nuove rispetto a quello che skill e server MCP già facevano singolarmente: il suo valore è nella standardizzazione del confezionamento e nella governance che ne deriva. Per un team che sviluppa strumenti interni per i propri agenti AI — che siano skill per il debug, integrazioni con sistemi proprietari via MCP, o automazioni sul ciclo di vita dell’agente — poter scrivere il plugin una sola volta e vederlo funzionare su CLI, editor e SDK senza riscritture è un risparmio di manutenzione concreto, non solo un dettaglio architetturale. Vale la pena tenerlo d’occhio anche per chi non usa Copilot: essendo uno standard aperto, è probabile che altri agent tool ne adottino la compatibilità nei prossimi mesi.

Fonte: Agent Plugins 1.0 in VS Code, Copilot CLI, and the Copilot app — GitHub Changelog

Claude Swap gestisce via CLI più abbonamenti/account https://gioxx.org/2026/07/29/claude-swap

#ai #claude #cli #github #opensource #python #script #software #terminale #vscode

Il sandbox non basta più: come Cursor, Codex, Gemini CLI e Antigravity sono stati bypassatiPer mesi il messaggio rassicurante degli editor e delle CLI potenziate da AI è stato semplice: l’agente lavora dentro un sandbox, quindi anche se un prompt injection lo convince a fare qualcosa di malevolo, il danno resta confinato al workspace. Il team di ricerca di Pillar Security ha appena dimostrato, in una serie di sette advisory pubblicate come “The Week of Sandbox Escapes”, che questa assunzione è sbagliata per almeno quattro strumenti molto usati da sviluppatori e sistemisti: Cursor, OpenAI Codex CLI, Google Gemini CLI e Antigravity.

La cosa interessante, e preoccupante, è che in nessuno dei casi l’agente ha attaccato direttamente il confine del sandbox. Ha semplicemente scritto un file che uno strumento fidato, esterno al sandbox, ha poi eseguito, caricato o scansionato per conto proprio.

Il vero confine non è il processo dell’agenteIl modello mentale comune è: “dentro il workspace l’agente può fare quello che vuole, fuori è protetto”. Pillar mostra che questo confine ha in realtà tre livelli distinti:

Esecuzione diretta: cosa può lanciare il processo dell’agente

Scrittura nel workspace: quali file l’agente può creare o modificare

Fiducia dell’host: cosa fanno i componenti non sandboxati con quei file

È il terzo livello a rompersi sistematicamente. Editor e CLI moderni sono pieni di automazioni che girano fuori dal sandbox: estensioni Python che scoprono interpreti, integrazioni Git che scansionano repository, VS Code che carica task file, hook engine che eseguono comandi al lifecycle, Docker Desktop che espone un socket locale privilegiato. Un agente sandboxato può rispettare ogni singola regola che gli è stata imposta e comunque condizionare l’input che questi componenti consumeranno.

Le quattro classi di vulnerabilitàI ricercatori raggruppano i sette bug in quattro pattern ricorrenti:

1. Sandbox a denylist che non tengono il passo del sistema operativoIl caso più chiaro è la sandbox Seatbelt di Antigravity su macOS: un profilo “allow by default” deve ricordarsi di bloccare ogni singola funzionalità pericolosa del sistema operativo. Come scrive Pillar, “non è un sandbox, è una lista di cose che qualcuno si è ricordato di bloccare, sempre corta di una voce”.

2. Configurazioni di progetto che sono a tutti gli effetti codice eseguibileDiversi bug non sono breakout classici: l’agente ha scritto file che era autorizzato a scrivere. Il problema è nato dopo, quando l’host ha trattato quei file come configurazione fidata. È il caso dell’hook .claude in Cursor, diventato esecuzione di comandi non sandboxata (ora CVE-2026-48124, corretto nella 3.0.0), o del task config .vscode che Antigravity ha usato per aggirare la sua Secure Mode.

3. Allowlist di comandi “sicuri” per nome, non per invocazioneIn Codex CLI, un comando come git show era considerato sicuro perché il nome suggerisce sola lettura. Ma Git ha decine di flag che cambiano completamente il comportamento: possono scrivere file, caricare configurazioni, invocare hook. La domanda giusta, scrivono i ricercatori, non è “git show è sicuro?” ma “quale invocazione esatta viene eseguita, con quali argomenti, in quale directory, contro quale configurazione?”. OpenAI ha corretto il bug nella v0.95.0 e pagato una bounty per severità alta.

4. Demoni locali privilegiati fuori dal sandboxIl bug più trasversale riguarda il socket Docker: un demone locale privilegiato raggiungibile da Codex, Cursor e Gemini CLI contemporaneamente, che diventava un ambiente di esecuzione non sandboxato. Sandboxare il processo dell’agente non serve a nulla se lascia aperto un demone con accesso pieno all’host: il confine si sposta semplicemente sull’API del demone.

Come si arriva all’exploit: il ruolo del prompt injectionIn tutti i casi il vettore d’ingresso è un’istruzione malevola nascosta in un README, in una issue, in una dipendenza o in un diff, che l’agente legge come input “normale” durante il suo lavoro. Da lì, l’istruzione si trasforma in un’azione locale sulla macchina dello sviluppatore, senza che l’utente abbia mai approvato esplicitamente nulla di sospetto: dal punto di vista dell’agente, ha semplicemente scritto un file di configurazione plausibile in un progetto.

Google ha classificato le due vulnerabilità di Antigravity come “Other valid security vulnerabilities”, applicando un downgrade perché richiedono ingegneria sociale o che l’utente si fidi di un repository con prompt injection indiretto — pur riconoscendo, nelle parole dei ricercatori, che uno dei report era “di qualità eccezionale”.

Cosa chiedere ai vendor (e cosa verificare in azienda)Per chi gestisce endpoint di sviluppo con strumenti agentici, Pillar suggerisce di andare oltre la domanda “ha un sandbox?” e porsi domande più operative:

Cosa può scrivere l’agente, esattamente?

Quali componenti dell’host si fidano di quei file?

Quali demoni locali privilegiati sono raggiungibili dall’agente?

Quali comandi saltano l’approvazione, e perché?

La policy valuta il nome del comando o l’invocazione e i suoi effetti reali?

Il prodotto distingue file creati dall’utente da file creati dall’agente?

Che telemetria esiste quando un componente fidato esegue qualcosa scritto dall’agente?

Sul piano pratico, per chi amministra postazioni di sviluppo con Cursor, Codex CLI, Gemini CLI o Antigravity: aggiornate immediatamente alle versioni patchate (Cursor 3.0.0+, Codex CLI 0.95.0+), verificate che l’accesso al socket Docker dagli strumenti AI sia effettivamente ristretto quando non necessario, e trattate le configurazioni di progetto generate o modificabili da un agente (hook, task VS Code, config Git non standard) come superficie di attacco da rivedere in code review, non come dettagli innocui.

ConclusioneIl punto centrale della ricerca di Pillar non è la lista dei singoli bug, quasi tutti già corretti, ma il pattern che li accomuna: gli agenti di coding sono diventati attori endpoint a tutti gli effetti, con accesso a codice sorgente, chiavi SSH, token cloud e sessioni browser, e processano di routine input non fidato (README, issue, dipendenze, diff). Un sandbox che protegge solo il processo dell’agente, ignorando cosa scrive e chi si fida di quello che scrive, non è un confine di sicurezza reale. Per chi introduce questi strumenti in azienda, la domanda da porsi non è più “abbiamo attivato il sandbox”, ma “sappiamo tracciare ogni volta che un componente fidato dell’host esegue qualcosa che l’agente ha scritto”.

Fonte: Pillar Security, “The Week of Sandbox Escapes” e BleepingComputer.