ThinkRail è un IDE agentico open source, con licenza Apache 2.0, sviluppato da JetBrains InnovationHub, il laboratorio interno della società che produce IntelliJ IDEA e PyCharm. A differenza dei plugin AI che si appoggiano a un programma già esistente, ThinkRail mette l’agente al centro e gli costruisce intorno editor, terminali, revisione delle modifiche e integrazione con GitHub.
Il motore, però, non è di JetBrains. Sotto il cofano lavora pi, l’agente di programmazione minimale creato da Mario Zechner, che ThinkRail esegue come libreria nel proprio processo. Da questa base derivano tre scelte: ogni attività gira in un worktree Git separato, ogni turno dell’agente si chiude con una ricevuta delle modifiche da rivedere in un colpo solo, e le intenzioni del progetto restano scritte in file SPEC.md che sopravvivono alla singola chat. La versione stabile è la 0.2.0 del 18 ottobre 2026, funziona su Windows, Linux e Mac con Apple Silicon e non richiede un account dedicato. In questa breve guida trovi le istruzioni per installarlo e collegarlo a un modello, anche locale, insieme al mio parere sui casi in cui lavora meglio di un agente da terminale.
Pi fa l’agente, ThinkRail fa tutto il resto
Per capire ThinkRail conviene separare due ruoli. L’agente è il programma che dialoga con il modello linguistico, decide quali file leggere, quali comandi lanciare e come gestire la memoria della conversazione. L’host è invece l’ambiente che gli sta intorno, cioè finestre, editor, terminali e pulsanti. In ThinkRail il primo ruolo spetta interamente a pi, che gestisce modelli, skill, compattazione della cronologia e calcolo dei costi, mentre ThinkRail si occupa soltanto del secondo.
Questa architettura porta a dei vantaggi pratici. ThinkRail e un’eventuale installazione di pi da riga di comando condividono la cartella ~/.pi, per cui fornitori configurati, modelli e cronologia delle sessioni passano da una parte all’altra. Puoi avviare un lavoro nel terminale e riprenderlo nell’interfaccia grafica, o fare il contrario.
Lo stesso discorso vale per le skill, i pacchetti di istruzioni in formato SKILL.md che un agente carica nel proprio contesto quando servono. ThinkRail le cerca non solo in ~/.pi ma anche nelle cartelle di Claude, Codex, Copilot e Gemini, sia a livello di sistema sia dentro il progetto aperto. Se hai già installato Ponytail per Claude Code, per esempio, ThinkRail la trova da solo e la mostra nella finestra Skills, raggiungibile in alto a destra.
Nel pacchetto arrivano inoltre alcune estensioni di pi già pronte, ovvero pi-web-access per le ricerche online, pi-visualize per diagrammi e anteprime, pi-spec-graph per le specifiche, pi-todos per i piani di lavoro e pi-thinkrail-workflow per i flussi guidati. Le estensioni di terze parti che aggiungono strumenti, comandi o eventi dovrebbero funzionare senza modifiche. Al contrario, quelle che cambiano l’aspetto dell’interfaccia testuale di pi restano escluse, perché ThinkRail usa un proprio sistema di temi.
Dal punto di vista tecnico il progetto è un monorepo TypeScript basato su Bun, con un server che espone l’agente tramite WebSocket e un’interfaccia React separata, mentre l’app desktop è costruita con Electrobun. Per questo app desktop e versione browser, quella aperta dal comando thinkrail, sono lo stesso programma e cambia solo il modo di avviarlo. Una separazione molto sensata, chi conosce pi non rinuncia a nulla, chi non lo conosce ottiene un’interfaccia leggibile senza imparare decine di comandi.
Installare ThinkRail e collegarlo a un modello
L’unico requisito di sistema, oltre a un fornitore di modelli, è Git disponibile nel PATH. Su Windows, se non lo hai ancora, basta un comando da PowerShell:
winget install --id Git.Git -e
Per l’app desktop si scaricano i pacchetti dalla pagina Releases del repository. Su Windows x64 va decompresso per intero il file ZIP di setup e l’eseguibile si lancia dalla cartella ottenuta, accanto ai file che lo accompagnano. Su Mac si apre il file DMG; l’app richiede macOS 14 e un processore Apple Silicon, dato che per i Mac Intel non esiste una build. Su Linux, infine, servono glibc 2.38 o successiva (Ubuntu 24.04 o equivalenti) e alcune librerie grafiche, poi si estrae l’archivio e si avvia il programma installer:
sudo apt install libgtk-3-0 libwebkit2gtk-4.1-0 libayatana-appindicator3-1 librsvg2-2
Se preferisci lavorare dal browser, magari su un server raggiungibile in rete locale, conviene la versione a riga di comando:
# macOS e Linux, canale stabile
curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh | bash
# canale nightly, aggiornato quasi ogni giorno
curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh | bash -s -- --channel nightly
# avvio su un repository
thinkrail ~/code/mio-progetto
# Windows (PowerShell)
powershell -c "irm https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.ps1 | iex"
thinkrail C:\progetti\mio-sito
Su Windows il canale e la versione si scelgono con le variabili d’ambiente THINKRAIL_CHANNEL e THINKRAIL_VERSION da impostare prima di lanciare l’installer. Per il resto, thinkrail update aggiorna il programma restando sul canale scelto, thinkrail uninstall --remove-data lo rimuove insieme alla cartella ~/.thinkrail e thinkrail --no-analytics disattiva per una sessione la condivisione dei dati d’uso aggiuntivi.
Per i modelli ci sono due strade. La più rapida è l’accesso con un account JetBrains AI direttamente dall’app, con i crediti previsti dal tuo piano. In alternativa ThinkRail usa le credenziali già configurate per pi nel file ~/.pi/agent/auth.json, che su Windows corrisponde a C:\Users\<nome>\.pi\agent\auth.json. Il trucco più utile è che il campo key accetta anche il nome di una variabile d’ambiente al posto della chiave in chiaro:
{
"openrouter": { "type": "api_key", "key": "OPENROUTER_API_KEY" },
"anthropic": { "type": "api_key", "key": "ANTHROPIC_API_KEY" }
}
Chi vuole restare in locale con Ollama aggiunge invece il fornitore in ~/.pi/agent/models.json:
{
"providers": {
"ollama": {
"baseUrl": "http://localhost:11434/v1",
"api": "openai-completions",
"apiKey": "ollama",
"compat": { "supportsDeveloperRole": false, "supportsReasoningEffort": false },
"models": [
{ "id": "qwen3-coder:30b", "name": "Qwen3 Coder 30B (locale)", "contextWindow": 65536 }
]
}
}
}
Comunque non aspettarti dai modelli locali open source la stessa affidabilità dei grandi modelli in cloud, almeno sulle attività di maggior spessore.
Un worktree per ogni attività, anche in parallelo
Il concetto su cui ruota tutto ThinkRail è il worktree, una funzione di Git poco conosciuta. In parole semplici, un worktree è una seconda cartella di lavoro dello stesso repository, che ne condivide la cronologia ma è posizionata su un branch diverso, cioè su un ramo di sviluppo separato. ThinkRail chiama ciascuna di queste cartelle workspace e le crea in ~/.thinkrail/worktrees/<nome-progetto>/, lontano dalla copia su cui lavori tu.
Per aprirne uno si preme Start building, si sceglie il branch di partenza e si scrive una descrizione dell’attività. Quella frase fa da nome del workspace e, allo stesso tempo, da primo prompt per l’agente, che parte subito. Ogni workspace ha file, terminali (sessioni di sistema reali, utili per lanciare i test mentre l’agente lavora) e chat indipendenti. Ciascuna chat può usare un modello diverso e mostra in tempo reale token consumati e costo stimato.
L’effetto più comodo è che la cartella originale del progetto resta intatta. Se la apri nel tuo editor abituale vedi il codice di prima, mentre le modifiche dell’agente vivono nel worktree finché non decidi di integrarle. Per farlo ThinkRail offre una barra in alto con cui pubblicare il branch, aprire una pull request (la richiesta di unione al ramo principale) con descrizione ricavata da piano e commit, seguire i controlli automatici della CI e completare il merge.
Ci sono però due aspetti da mettere in conto. Il primo riguarda lo spazio su disco, perché ogni worktree contiene una copia completa dei file del progetto e le cartelle ignorate da Git, come node_modules o gli ambienti virtuali Python, vanno ricreate in ciascun workspace. Il secondo riguarda i subagenti, cioè le istanze secondarie a cui l’agente principale delega pezzi di lavoro. Il loro numero va da 1 a 16 per chat, con 4 come valore predefinito, e si regola per tutto il programma o per singolo workspace. Con un fornitore a consumo ogni subagente moltiplica la spesa, perciò su progetti piccoli conviene scendere a 1 o 2.
Chi ha letto la nostra guida a GitButler noterà una filosofia diversa. Quel client gestisce più branch nella stessa cartella ed è pensato per una persona impegnata su vari fronti, mentre ThinkRail separa fisicamente le cartelle perché a lavorare in parallelo sono più agenti, che non devono pestarsi i piedi.
Rivedere un turno alla volta, non l’intera chat
La funzione che giustifica da sola l’installazione è la ricevuta di turno, introdotta con la versione 0.2.0. Ogni volta che una richiesta all’agente modifica dei file, la risposta si chiude con una riga riassuntiva come 3 files changed · +27 −4. Per calcolarla ThinkRail fotografa il worktree all’inizio e alla fine del turno, quindi conta anche le modifiche prodotte da comandi di terminale, formattatori automatici o rinomine, non solo quelle fatte con gli strumenti di scrittura dell’agente. L’operazione non tocca né la cronologia Git né l’area di staging.
Accanto alla ricevuta c’è il pulsante Review turn, che apre un’unica scheda con tutti i file cambiati in quel turno, da leggere in un solo scorrimento. I documenti Markdown appaiono già formattati, il codice come confronto prima e dopo, e la modalità One file permette di procedere un file alla volta senza perdere il punto. Il valore di questa vista emerge nelle sessioni lunghe.
La revisione dell’intero branch, nella scheda Changes, aggiunge tre azioni su ogni blocco di righe modificate:
- Keep. Lo accetta e, se è l’ultimo rimasto, segna il file come visto e fa crescere la barra di avanzamento.
- Revert. Lo annulla lasciando intatto tutto il resto.
- Ask agent. Apre una domanda all’agente proprio su quelle righe, con il contesto già allegato.
Il tasto J salta al prossimo file non ancora rivisto, mentre i file enormi, i lock file che fissano le versioni delle dipendenze e quelli generati automaticamente partono chiusi per non intasare la vista. L’approvazione con Keep è legata al contenuto del blocco, quindi sopravvive se le righe si spostano ma si azzera se l’agente torna a modificarlo, e così nessuna correzione successiva passa inosservata.
Per lavorare bene ti consiglio un ritmo preciso, cioè una richiesta, la revisione del turno, Keep o Ask agent sui blocchi dubbi e solo a quel punto la domanda seguente. Scrivere un nuovo prompt per correggere un errore visto nel diff costa più token e più tempo che chiedere direttamente su quel blocco.
Completano il quadro la scorciatoia Ctrl+K (Cmd+K su Mac), che elenca solo le chat in attesa di una tua risposta o ancora in esecuzione, anche in progetti diversi, e la barra dei piani con le sezioni Up next, Now e Done. Ogni passo completato riporta un riepilogo e la verifica eseguita, una traccia comoda quando torni su un lavoro lasciato a metà il giorno prima.
Cosa un worktree non protegge
È facile confondere l’isolamento dei workspace con una protezione di sicurezza, ma le due cose non coincidono. Il worktree tiene separate le modifiche ai file del progetto, non limita ciò che l’agente può fare sul computer. Un processo che lancia comandi di terminale può leggere altre cartelle del disco, le variabili d’ambiente e i file di configurazione con le credenziali, esattamente come qualsiasi agente da riga di comando. Se lavori su codice di terzi o fai girare l’agente senza sorveglianza, la soluzione resta un ambiente separato, come una macchina virtuale, un container o almeno un account di sistema privo di accesso ai tuoi dati personali.
L’ambito in cui ThinkRail interviene in modo più significativo è quello dei server MCP, i connettori del Model Context Protocol con cui l’agente usa servizi esterni come Sentry, Linear o un browser automatizzato tramite Playwright. Nelle impostazioni trovi preset pronti, un modulo guidato e l’inserimento manuale in JSON, e le credenziali si indicano solo come riferimento a una variabile o a un comando, mai in chiaro negli indirizzi. Se uno strumento può modificare dati, la chat mostra gli argomenti della chiamata e chiede di scegliere tra Deny, Allow once, Allow in this chat e Always allow.
Quanto alla privacy, ThinkRail invia eventi d’uso di base legati a un identificativo casuale, senza prompt, codice, file o credenziali, mentre le segnalazioni di errore partono sempre e contengono tipo e posizione del guasto nei sorgenti del programma. La condivisione aggiuntiva è spenta di serie e si gestisce da Settings, alla voce Privacy, oppure con la variabile THINKRAIL_NO_ANALYTICS=1.
Comincia da un repository di prova e da un solo workspace
ThinkRail convince soprattutto per il sistema di revisione del lavoro: ricevute di turno, approvazione per blocchi e workspace separati rendono leggibili anche sessioni molto lunghe. Il fatto che il motore sia pi, con la sua cartella di configurazione condivisa e le skill lette anche da Claude e Codex, abbassa inoltre il costo di una prova, perché non devi ricostruire da capo il tuo ambiente.
Se mantieni un sito, una piccola applicazione web o uno script con una suite di test, il consiglio pratico è partire da un clone di prova. Apri un solo workspace con un compito circoscritto, rivedi ogni turno con Review turn e osserva il costo mostrato nella chat prima di aumentare subagenti e sessioni parallele. Il confronto tra due modelli sulla stessa attività è il secondo esperimento da fare. Se invece non usi Git, lavori su un Mac Intel o cerchi un ambiente chiuso in cui lasciare l’agente da solo, per ora conviene aspettare.
