Herdr: il runtime che tiene vivi i vostri coding agent anche quando chiudete il terminale

Chi lavora con più agenti CLI in parallelo conosce la scena: tre o quattro finestre di terminale, un agente sul refactor, uno sui test, e poi la finestra si chiude, o il computer va in riavvio, e tutto quello che stava girando si ferma con lei.

Herdr nasce per quello. È un runtime open source (Apache-2.0) che sposta i terminali dentro un server: TUI, CLI e SSH sono client collegati a lui. Se il client si chiude o crasha, gli agenti non se ne accorgono e continuano a lavorare; al riavvio della macchina riporta a schermo layout e sessioni. Nato come progetto a una sola persona, è entrato in Y Combinator (batch F26) e oggi conta 34k stelle su GitHub.

Cosa fa in pratica

• Persistenza vera: i terminali appartengono al server, non alla finestra. Vi staccate e vi riattaccate quando volete, anche da remoto con herdr --remote user@host verso host Linux o macOS.
• Stato semantico degli agenti: per ogni pannello distingue working, blocked, idle, riassume lo stato a livello di tab e workspace e vi porta dritto al pannello che ha bisogno di voi, invece di costringervi a scorrere le finestre a mano. La detection legge il contenuto dello schermo e, dove l'agente li fornisce, i suoi lifecycle hooks.
• Tante CLI riconosciute out of the box: tra gli altri Claude Code, Codex, GitHub Copilot CLI, OpenCode, Cursor Agent CLI, Kimi Code CLI, Qwen Code, Grok CLI, Antigravity CLI e Hermes Agent. Quelli fuori lista girano comunque, come normali processi del terminale.
• Scriptabile e agent-native: CLI e socket API permettono a script o ad altri agenti di leggere lo stato, mandare prompt e aspettare che un agente sia davvero blocked invece di sparare keystroke e sperare.
• Plugin: il sito dichiara 885 plugin della community; il blog del progetto racconta un'estensione Raycast, pulsanti da Stream Deck e un'app iOS che pilota una sessione dal telefono.

Non sostituisce nulla: lo stesso terminale di sempre, gli stessi CLI, che funzionano esattamente come prima.

Installazione su Windows

```
irm https://herdr.dev/install.ps1 | iex
```

Il supporto Windows

È nativo (pannelli via ConPTY) e la pagina dedicata lo dichiara generalmente available, con canali di aggiornamento stable e preview. Mancano però alcune funzioni disponibili su Linux e macOS: Windows non può essere l'host di destinazione di --remote, non c'è l'attach diretto di un terminale esistente, e il cursore può sfarfallare durante output intenso, una limitazione documentata dello stack ConPTY che il progetto non può eliminare mantenendo il cursore nativo.

E Paseo, di cui parlavamo un paio di giorni fa?

Due livelli diversi. Paseo pilota gli agenti come processi da app desktop, mobile e web, con relay cifrato e workflow su worktree e PR: utile quando volete dirigere il lavoro dal telefono. Herdr vive nel terminale e si occupa di persistenza e stato della "mandria". Nessuno dei due obbliga a buttare l'altro.

Cosa NON è / limiti

• Non offre modelli né compute: non incapsula gli agenti, possiede i loro terminali. Servono CLI già installati, con le vostre credenziali.
• Le integrazioni installabili su Windows sono meno che su Unix (11 agenti, tra cui Claude Code, Codex, GitHub Copilot CLI e OpenCode).
• Lo stato blocked è volutamente conservativo: prompt insoliti o nuovi possono comparire come idle finché le regole di detection non coprono quella schermata.
• Installazioni totali (635k) e numero di plugin sono cifre dichiarate dal sito del progetto; le stelle GitHub le abbiamo verificate sulla pagina del repository.

Per trasparenza: herdr fa parte del mio setup, e uso un piccolo plugin che riporta lo stato del mio Coding Agent nella sua sidebar, così anche lui compare tra gli agenti con lo stato working/blocked/idle.

Voi quanti agenti riuscite a seguire in parallelo?

📌 Questo articolo riassume una discussione su r/vibecodingitalia. Leggi il post originale.