Herdr è un multiplexer di terminale, cioè un programma che divide una finestra in più terminali e li tiene vivi anche dopo che li hai chiusi, esattamente come fa tmux da vent’anni. La differenza sta in una cosa sola, ovvero Herdr sa che dentro quei riquadri gira un agente di programmazione e mostra a colpo d’occhio se sta lavorando, se ha finito o se è fermo in attesa di una tua risposta.
Il progetto è scritto in Rust, si distribuisce come binario unico senza Electron sotto, ed è passato alla licenza Apache 2.0 con la versione 0.8.0, dopo essere nato sotto AGPL. I numeri raccontano un’adozione rapida, con circa 36.900 stelle su GitHub, 2.700 fork e oltre 1.500 commit, mentre la versione 0.9.0 porta la data del 7 settembre 2026.
Il problema che risolve è nato negli ultimi due anni e lo conosce chiunque abbia provato a far girare più di un assistente alla volta. Apri tre schede terminale, lanci Claude Code su una, Codex su un’altra e OpenCode su una terza, poi passi il resto della mattinata a saltare da una all’altra per controllare chi ha finito e chi si è bloccato su una richiesta di conferma. Herdr prova ad aiutare in questo, e il modo in cui ci riesce è la parte tecnicamente più interessante di tutta la faccenda.
Come fa a sapere se un agente sta lavorando o se aspetta una risposta
Qui c’è il nodo che rende il progetto diverso da un qualsiasi tmux . Per dire se un agente è occupato, fermo o in attesa, serve che l’agente lo comunichi, e ad oggi non esiste ancora nessuno standard condiviso per farlo. Herdr affronta il problema su due livelli, uno pulito e uno arrangiato.
Il livello pulito sono i lifecycle hooks, cioè i ganci che alcuni assistenti espongono per segnalare l’inizio e la fine di un’operazione. Se l’integrazione è installata, quella diventa la fonte autorevole per gli stati idle, working e blocked, oltre che per l’identità della sessione. Il comando per attivarla è di una riga.
herdr integration install claude
herdr integration status
Il problema è che quella strada oggi copre pochi assistenti, e precisamente Pi, OMP, Kimi Code CLI, OpenCode, Kilo Code CLI e MastraCode. Per molti altri, entra in scena il secondo livello.
Il secondo livello si chiama screen manifest e funziona così. Herdr identifica il processo in primo piano, legge l’istantanea della parte bassa dello schermo del terminale e confronta quel testo con una serie di regole scritte in file TOML, che possono guardare anche il titolo della finestra e le sequenze di avanzamento OSC. In pratica lo stato dell’agente si deduce leggendo quello che stampa a video.
Lo stato blocked viene assegnato solo se l’istantanea corrisponde a un’interfaccia di approvazione, domanda o permesso già nota, quindi il sistema preferisce non dire niente piuttosto che sbagliare. I manifest arrivano in tre copie sovrapponibili, ovvero quelli compilati dentro il binario, quelli scaricati e messi in cache da herdr.dev, e quelli scritti a mano in ~/.config/herdr/agent-detection/<agente>.toml, che hanno la precedenza.
Quando il riconoscimento sbaglia c’è un comando apposito per capire cosa è successo, e mostra quali regole hanno fatto scattare lo stato.
herdr agent explain w1:p1
herdr agent rename w1:p1 revisore
herdr agent attach revisore
Il giorno in cui un protocollo comune arriverà, metà di questo codice diventerà inutile, e sarà una buona notizia.
Installazione e il modello a server
L’installazione è quella tipica dei progetti Rust moderni, cioè uno script che scarica il binario per la piattaforma, con le alternative per chi preferisce un gestore di pacchetti.
# Linux e macOS
curl -fsSL https://herdr.dev/install.sh | sh
# oppure
brew install herdr
mise use -g herdr
# Windows
powershell -ExecutionPolicy Bypass -c "irm https://herdr.dev/install.ps1 | iex"
Sotto c’è un’architettura a server e client identica nello spirito a quella di tmux. Il server gira in sottofondo e possiede i terminali con i processi che ci stanno dentro, mentre il client è la parte che disegna l’interfaccia e si può staccare senza fermare niente, con ctrl+b q. Lanciando di nuovo herdr ci si riattacca e si ritrova tutto dov’era.
L’organizzazione interna aggiunge un livello rispetto a tmux, che ritorna in tutti i comandi.
- Il workspace è il contenitore di progetto, di solito uno per repository o per compito, e la sua barra laterale riassume lo stato di tutti gli agenti che contiene.
- Il tab è una disposizione dentro il workspace, utile per separare agenti, log e server che restano accesi.
- Il riquadro, che la documentazione chiama
pane, è il terminale vero, quello che Herdr disegna, alimenta con l’input e conserva anche dopo che il client si è staccato. - La sessione è lo spazio dei nomi del server, con herdr come predefinita e la possibilità di crearne altre del tutto separate.
La configurazione vive in un file TOML, generabile con herdr --default-config, e il prefisso da tastiera è ctrl+b, proprio come nella tradizione a cui siamo abituati.
[keys]
prefix = "ctrl+b"
new_tab = "prefix+c"
next_tab = "prefix+n"
focus_pane_left = "prefix+h"
split_horizontal = "prefix+minus"
[theme]
name = "catppuccin"
auto_switch = true
[ui.toast]
delivery = "herdr"
delay_seconds = 1Chi non ha mai usato un multiplexer può ignorare del tutto la tastiera, perché l’interfaccia è utilizzabile con il mouse (a differenza di tmux).
Gli agenti che pilotano il multiplexer
Herdr non serve soltanto a guardare gli agenti, perché gli agenti possono guidare Herdr, e lo fanno attraverso un’interfaccia locale fatta di JSON separati da un ritorno a capo su un socket Unix, che su Windows diventa una named pipe.
Il socket sta in ~/.config/herdr/herdr.sock, i metodi disponibili sono oltre cento e il formato delle richieste è essenziale.
{"id":"req_split","method":"pane.split","params":{"direction":"right","ratio":0.333}}
{"id":"req_run","method":"pane.run","params":{"pane_id":"w1:p2","command":"npm test"}}
{"id":"req_read","method":"pane.read","params":{"pane_id":"w1:p2","source":"recent","lines":50}}
Dentro ogni pane Herdr inietta le variabili d’ambiente che servono a orientarsi, tra cui HERDR_SOCKET_PATH, HERDR_WORKSPACE_ID, HERDR_TAB_ID e HERDR_PANE_ID, quindi un processo sa sempre chi è e a chi parlare. Da lì si aprono scenari che somigliano più a un’orchestrazione che a un multiplexer.
Tre metodi in particolare meritano attenzione. Il primo è pane.report_agent, con cui un processo qualsiasi dichiara il proprio stato semantico e smette di dover essere indovinato. Il secondo è agent.wait, che mette in pausa un’esecuzione finché un altro agente non cambia stato, con tanto di scadenza. Il terzo è agent.prompt, che invia un messaggio a un agente e, volendo, resta in attesa della transizione successiva.
{"id":"req_1","method":"pane.report_agent","params":{"pane_id":"w1:p1","source":"custom:docs","agent":"docs-bot","state":"working","message":"sto generando la documentazione"}}
C’è anche un sistema di sottoscrizione agli eventi, utile per i programmi che restano accesi e vogliono essere avvisati appena un agente si blocca, invece di interrogare il server in continuazione.
{"id":"sub_1","method":"events.subscribe","params":{"subscriptions":[{"type":"pane.agent_status_changed","pane_id":"w1:p1","agent_status":"blocked"}]}}
Sopra a tutto questo si appoggiano i plugin, che si possono scrivere in qualsiasi linguaggio, da Bash a Rust, e che sono semplicemente una cartella con un manifesto herdr-plugin.toml e dei comandi eseguibili. Non esiste un SDK separato e l’intera riga di comando di Herdr fa da interfaccia per i plugin. Si installano da GitHub e finiscono in un catalogo che si popola da solo, indicizzando ogni repository con l’argomento herdr-plugin e aggiornandosi ogni trenta minuti.
herdr plugin install proprietario/repo/sottocartella
herdr plugin link /percorso/del/plugin
Su questo punto il progetto avverte che i plugin girano con i tuoi stessi permessi e con accesso completo all’ambiente, senza nessuna sandbox. Vanno trattati come si tratta un’estensione dell’editor, cioè installati solo da fonti di cui ci si fida.
Macchine locali e remote dentro la stessa finestra
La 0.9.0 ha aggiunto la funzione che più di ogni altra giustifica il salto da tmux per chi lavora su più macchine. Nella stessa finestra si possono tenere il computer locale e uno o più server raggiungibili via SSH, con la barra laterale che elenca gli agenti di tutti quanti insieme.
herdr machine add workbox --label "Macchina di build"
herdr machine add workbox --label "Macchina di build" --remote-session agenti
Il meccanismo non è un tunnel che inoltra caratteri, dato che ogni macchina mantiene il proprio server, le proprie sessioni e i propri processi. Quella selezionata riceve l’input e la dimensione del terminale e restituisce il contenuto visibile, comprese le immagini. La conseguenza pratica più utile è che la caduta di un collegamento non trascina giù gli altri, e la macchina irraggiungibile resta visibile con i dati in cache, in grigio, con l’input disattivato fino al ritorno.
Herdr va installato anche sulla macchina remota, e la procedura controlla sia il binario sia il server in esecuzione, proponendo di sostituire le versioni incompatibili. I client multi macchina funzionano su Linux e macOS ma non ancora su Windows, e un server Windows nativo non può fare da destinazione SSH.
Vale la pena segnalare anche due comportamenti che evitano brutte sorprese. Herdr non copia sulla macchina remota i plugin locali, la configurazione, gli eseguibili o i segreti, quindi ogni server va allestito per conto suo. E gli identificatori dei panee i nomi degli agenti valgono solo dentro il loro server, quindi due macchine possono contenere lo stesso w1:p1 senza che questo crei conflitti.
Cosa sopravvive a un riavvio
Su questo punto conviene avere le idee chiare, perché la parola persistenza copre tre scenari molto diversi.
Se a chiudersi è il client, non succede niente di male. I processi continuano a girare dentro il server, la disposizione torna identica al riattacco e lo schermo recente ricompare, perché i programmi originali non si sono mai fermati. È la stessa garanzia di tmux.
Se invece a ripartire è il server, la musica cambia. La struttura viene conservata, quindi tornano workspace, tab, pane, cartelle di lavoro, disposizione , ma i processi no, e i paneripartono come shell nuove al loro posto. Restano due vie di recupero facoltative, ovvero la cronologia dello schermo dei pane e la ripresa nativa della conversazione per gli assistenti che la supportano attraverso le loro integrazioni ufficiali.
Da notare che la cronologia sia disattivata per impostazione predefinita, con una motivazione di sicurezza. Salvare su disco quello che è passato a schermo significa salvare anche le chiavi, i token e tutto ciò che un comando ha stampato per sbaglio, quindi la scelta di partenza è non conservare niente, lasciando l’onere a chi vuole la comodità.
pane_history = true
C’è infine una funzione sperimentale chiamata live handoff, che durante un aggiornamento passa i pane vivi al nuovo server, così i processi non si fermano nemmeno mentre il programma si sostituisce da sotto.
Il conto è valido dal terzo agente in poi
L’impressione è di un progetto con un’idea precisa e la disciplina per portarla avanti, non di un clone di tmux con l’etichetta AI sopra. Il riconoscimento degli stati, il socket con un centinaio di metodi e la gestione multi macchina hanno sostanza tecnica, e la scelta di Rust con un binario unico tiene i consumi lontani da quelli di un’applicazione Electron.
Detto questo, non serve a tutti. Se apri un terminale per volta, se ci tieni dentro una shell e un editor, se il tuo assistente lo usi uno alla volta e guardi la finestra mentre lavora, lo stato dell’agente è un’informazione che non ti dice niente e tmux continua a essere la risposta giusta. Lo stesso vale per chi lavora su Windows, dove il supporto è arrivato da poco e il collegamento multi macchina ancora manca.
Il vantaggio, arriva dal terzo agente aperto contemporaneamente. Sotto quella soglia il guadagno non copre l’installazione di un tool nuovo su ogni macchina. Sopra, la barra laterale che dice quale dei tre è fermo ad aspettare una conferma diventa la differenza fra lavorare e girare fra le schede.
