Lascia che OpenCode corregga il bug mentre continui a lavorare nella tua directory

Hai una modifica scritta a metà nella tua copia di lavoro quando qualcuno segnala un guasto nell’analizzatore di date. Vuoi continuare a modificare i tuoi file e dare all’agente di programmazione un compito separato. Appena lavorate entrambi nella stessa directory, anche una piccola correzione diventa difficile da separare dal lavoro in corso.

Il 6 novembre OpenCode 2.2.6 ha aggiunto un’opzione worktree alle esecuzioni da script sulla riga di comando. OpenCode è un agente di programmazione open source con un’interfaccia interattiva da terminale e un comando separato per eseguire una richiesta da uno script. Con la nuova opzione lo script può avviare OpenCode in un worktree Git separato, assegnargli un nome facoltativo e lasciare disponibile la directory originale. La stessa versione ha aggiunto la condivisione facoltativa delle connessioni corrispondenti del Model Context Protocol (MCP). La combinazione pone due domande prima di iniziare. Quali file può cambiare l’agente e quali servizi può usare? Versione 2.2.6 di OpenCode · Documentazione della riga di comando di OpenCode

Una configurazione utile unisce un compito circoscritto, un punto di partenza prevedibile, un posto dove esaminare i cambiamenti e permessi espliciti per tutto ciò che esce dal progetto.

La schermata del progetto OpenCode mostra una patch e una sessione. La risorsa ufficiale della versione illustra l’interfaccia da terminale. L’immagine è accompagnata dall’avviso di licenza MIT. Telli.sh ha ridimensionato la schermata e aggiunto margini.

Una directory separata rende più facile fidarsi del diff

Un worktree Git dà a ciascun compito file di lavoro e indice propri. Illustrazione originale di Telli.sh.

I worktree di Git associano più directory di lavoro a un repository. Ogni worktree ha i propri file, il proprio indice e la propria posizione nel progetto. Condividono gran parte dei dati del repository. Un worktree separato permette di esaminare la patch dell’agente mentre le modifiche originali rimangono dove le hai lasciate. Cambia anche il codice sorgente che l’agente vede. Le modifiche senza commit della prima directory non arrivano nella seconda solo perché appartengono allo stesso repository. Documentazione di Git worktree

La versione di OpenCode del 6 novembre descrive tre modi per attivare il comportamento. Usa opencode run -w oppure opencode run --worktree per creare un nuovo worktree e --worktree=<name> per assegnargli un nome. La versione specifica anche che l’opzione non si può combinare con --continue o --session. Una nuova esecuzione ha bisogno di un proprio contesto iniziale. Se una segnalazione ha già una lunga conversazione allegata, porta nella nuova richiesta i passaggi di riproduzione pertinenti e il risultato atteso. Versione 2.2.6 di OpenCode · Implementazione del worktree ed esempi

Usa la directory separata come spazio di revisione. Prima di partire, annota il ramo e il commit che ti aspetti che l’agente usi. Dopo l’avvio, controlla il commit e lo stato del worktree risultante. Se un test dipende da dati di prova non tracciati o da una modifica che esiste solo nell’editor, la differenza di partenza spiega un risultato apparentemente discordante. Una patch può essere corretta per una versione più vecchia e comunque inadatta al ramo che stai per pubblicare.

Prova una piccola modifica prima di delegarne una più ampia

Parti da un repository che controlli e da un compito specifico. Un test che fallisce sul giorno bisestile è un esperimento iniziale migliore di un aggiornamento ampio perché il risultato atteso è facile da controllare. Un altro esempio circoscritto è correggere un collegamento di navigazione obsoleto con una sola prova del percorso. In entrambi i casi, descrivi esplicitamente quale comportamento deve cambiare e come lo controllerai.

1. Registra lo stato iniziale. Nella directory corrente usa git status --short e git rev-parse HEAD. Conserva l’output insieme alla segnalazione. Se hai già uno stato di riferimento con test positivi, annota come riprodurlo. Usa opencode --version per verificare che la versione includa la nuova opzione. Versione 2.2.6 di OpenCode

2. Assegna un solo compito all’agente e indica un worktree con nome. Nella richiesta includi la riproduzione e il test da usare. L’esempio usa un analizzatore di date immaginario e presuppone che nel repository ci sia già un test mirato. Chiedere di lasciare le modifiche senza commit facilita la revisione. Imposta limiti più stringenti nei permessi e nell’ambiente di esecuzione.

   ShellEsegui in Terminale

   opencode run --worktree=date-parser "Reproduce the leap-day parsing bug in the date parser tests. Fix the narrow cause, run the targeted tests, and leave the changes uncommitted for review."
   

3. Trova la nuova directory prima di esaminare il risultato. Esegui git worktree list dal repository originale e usa il percorso indicato. Nella nuova directory controlla git status --short, git diff e git diff --cached. L’ultimo comando serve se l’agente ha aggiunto qualcosa all’indice. Esamina separatamente i file non tracciati. Esegui di nuovo i test mirati dalla directory dell’agente e verifica che coprano sia il 29 febbraio di un anno bisestile sia un anno in cui la data è invalida. Documentazione di Git worktree

4. Integra solo il lavoro che hai esaminato. Tieni la modifica separata finché puoi applicare un commit o una patch verificata al ramo previsto. Ricontrolla lo stato della directory originale. Conserva il worktree dell’agente finché hai registrato ciò che ti serve e verificato che non contenga modifiche in sospeso da tenere. L’elenco dei worktree di Git aiuta a capire quale directory appartiene a quale compito. Documentazione di Git worktree

Lo stesso schema aiuta quando arrivano due problemi indipendenti insieme. Dai a ciascuno un obiettivo piccolo e confronta i due diff prima di integrarli. Separare i worktree evita che una modifica a un test non ancora nell’indice del primo agente appaia nella directory del secondo. Le correzioni possono comunque entrare in conflitto sullo stesso ramo, specialmente se toccano una funzione comune. Integrazione e test finali di regressione restano parte del normale processo di revisione.

Decidi chi può fare cosa fuori dal repository

Due worktree possono essere eseguiti con lo stesso account del sistema operativo. Possono avere accesso allo stesso ambiente, agli stessi gestori delle credenziali e alla stessa rete. La nuova opzione sceglie dove parte l’esecuzione e separa le modifiche ordinarie. Imposta limiti separati per ambiente o account quando il compito richiede confini più forti. Una richiesta di autorizzazione controlla gli strumenti che la rispettano. Il sistema operativo o l’ambiente di esecuzione determina fin dove può arrivare il processo.

Posizione delle modifiche, approvazione degli strumenti e accesso del processo sono controlli distinti. Illustrazione originale di Telli.sh.

La documentazione dei permessi di OpenCode V2 descrive regole ordinate per singole azioni. Fra gli effetti ci sono allow, ask e deny. Prevale l’ultima regola corrispondente. Un esempio ufficiale chiede conferma prima dei comandi di shell, consente i comuni comandi di ispezione e nega l’invio al remoto. Se prevedi esecuzioni senza una persona che possa approvare, prova il comportamento di una regola ask prima di inserirla in un’attività ricorrente. Imposta divieti chiari nella configurazione e usa credenziali di breve durata e con ambito ristretto per i servizi necessari. Documentazione dei permessi di OpenCode

Un compito di sola documentazione è un modo semplice di provare questi livelli. Consenti all’agente di cambiare una sezione in un progetto di esempio. Dagli un fornitore che è autorizzato a usare e fai a meno delle credenziali di produzione. Esegui lo script e controlla che la patch riguardi solo il file previsto. Se l’automazione dovrà accedere a un repository remoto o a un sistema di ticket, giustifica ogni capacità e controllane separatamente i permessi.

Ha senso condividere una connessione quando i progetti condividono già lo stesso perimetro

MCP permette all’agente di usare strumenti forniti da altri programmi, per esempio un motore di ricerca della documentazione o un sistema di ticket. Nella versione del 6 novembre, pool: true consente alle directory servite da un solo server OpenCode di riutilizzare una connessione quando la configurazione rilevante coincide. La documentazione ufficiale V2 specifica che la condivisione si applica alla revisione del protocollo 2026-07-28. Se un server negozia una revisione precedente, mantiene connessioni separate. La corrispondenza richiede più che puntare due progetti allo stesso indirizzo. Devono coincidere la configurazione remota e gli account autenticati. Per un server locale contano anche comando, ambiente e directory di lavoro. Versione 2.2.6 di OpenCode · Documentazione delle connessioni MCP condivise

Immagina due worktree che interrogano lo stesso servizio interno di documentazione con lo stesso account. La condivisione può ridurre le configurazioni duplicate se il servizio supporta la revisione pertinente. Verifica prima che entrambe le directory debbano accedere allo stesso materiale e che l’integrazione offra solo le funzioni necessarie. Se a un worktree servono solo i documenti pubblici e l’altro può aprire ticket interni, tenere separate le connessioni rende più facile controllare i confini.

Un server locale può dipendere dalla directory di lavoro corrente. Un processo lanciato in ciascuna cartella può avere un contesto locale diverso anche se il comando coincide. La documentazione di OpenCode indica che per condividere le connessioni locali tra progetti serve una directory fissa e che una connessione condivisa non ha radici MCP. Conviene quindi partire da un servizio in sola lettura con un ambito di risorse chiaro. Se il comportamento dipende dal repository che invoca lo strumento, misura che cosa cambia prima di passare alla connessione condivisa. Documentazione delle connessioni MCP condivise

Anche le esecuzioni da script devono finire

OpenCode 2.2.6 ha aggiunto anche --archived, così le sessioni da script o di integrazione continua possono partire archiviate e restare fuori dagli elenchi ordinari. Cambia il modo in cui si presenta la sessione. Salva esito, percorso del worktree e risultati dei test dove chi revisiona possa trovarli. Usa l’opzione dopo aver predisposto un modo affidabile per trovare la patch anche se l’elenco ordinario resta vuoto. Le note del 6 novembre dicono che --continue salta le sessioni archiviate. Versione 2.2.6 di OpenCode

La stessa versione cambia il ciclo di vita di un’esecuzione da script. Prima di uscire aspetta i comandi in background, i sottoagenti e i lavori sulle immagini avviati dalla richiesta. Le note indicano che l’attesa non ha un limite interno. Un server di sviluppo o un osservatore di file può dunque lasciare l’esecuzione aperta. Per un test automatizzato, scegli comandi che terminano alla fine della verifica e assegna un tempo massimo al passaggio di integrazione continua. Distingui un’esecuzione annullata, un test fallito e un agente che dichiara successo. Se scade il tempo, controlla lo stato effettivo delle modifiche prima di riavviare o integrare. Versione 2.2.6 di OpenCode

Quando il test pilota funziona, per valutare il risparmio guarda oltre il messaggio di completamento. Quanto tempo serve a preparare un’esecuzione pulita? Quanto impiega chi revisiona a capire e verificare la modifica? Quanto spesso qualcuno deve rimediare a una modifica estranea o indagare su uno strumento bloccato? Confronta compiti di dimensioni simili e includi preparazione e revisione. Un worktree separato è più utile quando mantiene la patch abbastanza piccola perché una persona possa farsene carico.

Una directory pulita rende visibile la responsabilità

L’opzione worktree offre a chi esamina il risultato un punto di partenza chiaro. Può vedere lo stato iniziale, esaminare la modifica e ripetere il test mentre l’altra persona continua a lavorare. Rendi altrettanto espliciti la condivisione delle connessioni e i permessi di esecuzione. Il passaggio di consegne più chiaro è una patch piccola che permette di capire da dove è partita, che cosa è cambiato e quali verifiche permettono di integrarla.

Fonti

• Schermata ufficiale del terminale OpenCode e licenza del repository

• Versione 2.2.6 di OpenCode, 6 novembre 2026

• Documentazione della riga di comando di OpenCode

• Permessi di OpenCode V2

• Condivisione delle connessioni MCP in OpenCode

• Manuale di Git worktree

---

Per conservare le decisioni e gli esperimenti alla base del tuo lavoro in un archivio consultabile, crea un account Telli.sh.