Per anni lo sviluppo di applicazioni desktop native su #Windows è stato percepito come un percorso lento: XAML da scrivere a mano, documentazione sparsa tra WPF, UWP e WinUI, e agenti AI generalisti che, interrogati su “come si fa in WinUI 3”, rispondono spesso con pattern deprecati presi da esempi UWP o WPF più vecchi e più numerosi nei dati di addestramento. Microsoft ha da poco pubblicato un flusso di lavoro end-to-end — VS Code, .NET 10 e un agente #Copilot specializzato — che promette di ridurre il percorso da “cartella vuota” ad app WinUI 3 pubblicabile a circa 30 minuti. Vale la pena capire cosa c’è davvero dietro, perché la parte interessante non è la demo, ma il modo in cui l’agente viene reso affidabile su un framework di nicchia.

Il problema: agenti AI e API deprecateLa documentazione ufficiale lo dice esplicitamente: senza un intervento mirato, un agente AI generico tende a suggerire pattern Windows obsoleti, perché nei dati di addestramento gli esempi WPF e UWP sono semplicemente più numerosi di quelli WinUI 3. La soluzione adottata non è un modello diverso, ma un plugin che inietta regole esplicite su WinUI 3 come istruzioni personalizzate, sovrascrivendo i comportamenti di default del modello. È un approccio replicabile anche in altri contesti: quando un framework è recente o di nicchia, spesso conviene irrigidire l’agente con conoscenza di dominio esplicita piuttosto che sperare che il modello “la sappia già”.

Gli strumenti coinvoltiL’intero flusso si basa su componenti gratuiti:

Visual Studio Code

.NET SDK 10 o successivo

Windows App Development CLI (winapp), il tool a riga di comando per scaffolding, packaging e testing

#GitHub CLI con estensione Copilot, che richiede un abbonamento GitHub Copilot (è sufficiente il piano gratuito)

Plugin agente WinUI (winui@awesome-copilot)

Estensione WinApp per VS Code

Su Windows l’installazione dei prerequisiti passa quasi interamente da winget:

winget install Microsoft.VisualStudioCode
winget install Microsoft.DotNet.SDK.10
winget install Microsoft.winappcli --source winget
dotnet new install Microsoft.WindowsAppSDK.WinUI.CSharp.Templates
winget install GitHub.cli

gh auth login
gh extension install github/gh-copilot
gh copilot plugin install winui@awesome-copilot

code --install-extension microsoft-winappcli.winapp
winapp --versionL’agente winui-dev e le sue otto skillIl cuore del sistema non è un singolo prompt, ma un pacchetto di otto skill specializzate che l’agente winui-dev orchestra in base al contesto:

winui-setup: verifica e installa i prerequisiti (SDK, template, Developer Mode)

winui-#dev-workflow: guida il ciclo scaffold → build → run → iterazione

winui-design: genera layout XAML con i controlli Fluent Design corretti

winui-code-#review: verifica il codice cercando anti-pattern specifici di WinUI 3

winui-ui-testing: genera test UI basati su Windows UI Automation

winui-packaging: guida su packaging MSIX, firma e pubblicazione in Store

winui-wpf-migration: mappa API WPF verso i corrispondenti WinUI 3

winui-session-report: riassume il lavoro svolto nella sessione

Un dettaglio rilevante per chi lavora già con più strumenti AI: il plugin non è legato a VS Code Copilot Chat. È installabile anche per GitHub Copilot CLI da terminale e, con un registro plugin diverso, per Claude Code:

GitHub Copilot CLI

gh copilot plugin install winui@awesome-copilot
gh copilot plugin list

Claude Code

claude plugin marketplace add microsoft/win-dev-skills
claude plugin install winui@win-dev-skillsIl flusso end-to-end1. Scaffold del progettomkdir MyFirstApp
cd MyFirstApp
dotnet new winui-navviewIl template genera un layout NavigationView con pagine Home, About e Settings già collegate.

2. Prima esecuzionedotnet runL’app parte come pacchetto “loose layout”, senza bisogno di un’installazione MSIX. Solo dopo il primo dotnet run riuscito conviene aprire VS Code con code .: se si preme F5 prima, il debugger cerca un eseguibile che ancora non esiste.

3. Aggiungere funzionalità con l’agenteIn VS Code, con Copilot Chat in modalità Agent e l’agente winui-dev selezionato, basta descrivere cosa serve in linguaggio naturale:

Aggiungi una pagina Impostazioni alla mia app WinUI NavigationView
con un interruttore per la modalità scuraL’agente genera i file necessari, aggiorna la struttura di navigazione e, tramite la skill winui-design, produce XAML coerente con i controlli Fluent Design attuali invece di ricorrere a pattern più datati.

4. PackagingDa un terminale con privilegi elevati (necessario per generare e installare il certificato di sviluppo):

dotnet publish -o ./publish
winapp pack ./publish --generate-cert --install-certPer la sottomissione allo Store, il certificato locale va sostituito con quello fornito da Partner Center.

5. Pubblicazionewinapp store publish ./*.msix --appId Richiede un account Partner Center attivo; la certificazione richiede tipicamente 1-3 giorni lavorativi.

Cosa considerare prima di adottarlo in produzionePer chi gestisce team .NET, il vantaggio pratico non è tanto il tempo risparmiato sulla prima scaffolding — quello lo si ottiene già con i template dotnet new — quanto la skill winui-code-review, che introduce un controllo automatico contro gli anti-pattern più comuni prima ancora del code review umano, e la skill winui-wpf-migration, utile per chi ha ancora applicazioni WPF legacy da modernizzare in modo incrementale. Resta comunque necessaria una revisione umana del codice generato, in particolare su packaging, firma e permessi richiesti dall’app: sono aspetti che incidono direttamente sulla sicurezza dell’installazione finale.

ConclusioneIl flusso descritto da Microsoft è meno una “demo AI” e più un caso di studio su come rendere affidabile un agente su un dominio verticale: prerequisiti scriptabili, skill specializzate invece di un prompt generico, e un plugin compatibile sia con l’ecosistema GitHub Copilot sia con Claude Code. Per i team che sviluppano o mantengono applicazioni Windows native, è uno stack da provare su un progetto pilota prima di considerarlo parte del flusso standard.

Fonte: 4sysops — approfondimento tecnico basato sulla documentazione ufficiale Microsoft Learn: Quickstart e WinUI agent plugin.

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.