Come vedere cosa esegue il tuo agente di codice sui tuoi server

Chiedi a un agente DevOps perché l'API di produzione è lenta. Si mette al lavoro. Nel suo terminale vedi una riga che dice che sta chiamando uno strumento, poi un'altra, poi un'altra ancora. Sei chiamate dopo ti dice che il disco è pieno al 97 % e propone di svuotare la cartella dei log.

Cosa ha eseguito davvero su quella macchina? Quale du, quale find, ha già cancellato qualcosa? La risposta esiste, ma è nella trascrizione della sessione, scritta in JSON, e la leggi a cose fatte. Su un portatile va bene. Su un server di produzione, a cose fatte è troppo tardi per dire "aspetta, non quella cartella".

Sviluppiamo AgentsRoom, un'app desktop che esegue agenti di codice e dà loro gli strumenti per raggiungere i tuoi server, database e cluster. Questa è la storia di come abbiamo reso visibili quelle chiamate mentre avvengono, la versione che non ha funzionato, i numeri dietro quella che funziona e come ottenere lo stesso se non usi la nostra app.

La risposta breve

• Il CLI ti mostra che uno strumento è stato eseguito, non la sessione dall'altra parte. Il comando completo e il suo output finiscono nella trascrizione sul tuo disco.
• Per seguirlo in diretta, qualcosa deve registrare ogni chiamata nel momento in cui parte, non quando finisce la sessione.
• Un registro per connessione funziona. Una scheda di terminale per comando no. Abbiamo misurato 166 comandi remoti in una sola sessione.
• Tieni quel registro sulla tua macchina. Una riga di comando su un server di produzione si porta dietro segreti e dati dei clienti.
• Senza la nostra app: un hook di Claude Code che aggiunge ogni comando di shell a un file ti porta quasi fino in fondo, e la trascrizione ti dà il resto.

Perché la trascrizione non basta su un server

Claude Code, Codex e gli altri CLI registrano tutto, eccome. Claude Code scrive un file JSONL per sessione in ~/.claude/projects/, Codex uno in ~/.codex/sessions/. Ogni chiamata a uno strumento è lì dentro, con il suo input e il suo risultato.

Il problema non è la completezza, sono il momento e la forma. La trascrizione è scritta per il CLI, perché possa riprendere una sessione. La leggi quando l'agente si è già fermato, scavando tra righe di JSON. Quando lavorano tre agenti insieme, leggi tre file. E il terminale dell'agente, il posto che stai davvero guardando, mostra solo un riepilogo compresso di ogni chiamata.

Per il codice sul tuo portatile, rileggere dopo è il ciclo normale: guardi il diff prima di fare commit. Un server non ha diff. Un systemctl restart o un DELETE ha effetto nell'istante in cui viene eseguito.

Cosa abbiamo provato prima, e i 166 comandi

Il nostro primo strumento remoto per agenti apriva una connessione in una scheda di terminale. Sembrava la cosa giusta: l'utente vedeva la sessione. È fallito in un modo che non ci aspettavamo.

Lo strumento non dava all'agente alcun modo di leggere cosa succedeva nella scheda che aveva appena aperto. Così, sul progetto di un utente, l'agente ha smesso di usarlo. Il conteggio di quella sessione: 16 chiamate al nostro strumento di connessione e 166 comandi sshpass eseguiti con lo strumento di shell dell'agente stesso, con l'agente che chiedeva la password all'utente e l'utente che la incollava nella chat. Le credenziali di produzione sono finite in chiaro nelle trascrizioni, in ps aux mentre ogni comando girava e in un file sotto /tmp.

La lezione non era "gli agenti sono imprudenti". L'agente ha fatto l'unica cosa che funzionava. Uno strumento sicuro che non permette all'agente di fare il suo lavoro viene aggirato, e l'aggiramento è peggio che non avere alcuno strumento.

Così abbiamo scritto ssh_exec: l'agente invia un comando, AgentsRoom lo esegue sulla connessione salvata con la password conservata nell'app e restituisce l'output e il codice di uscita. L'agente non vede mai la credenziale e non ha alcun motivo per costruire una riga sshpass.

Questo ha risolto il problema di sicurezza e ne ha creato uno di visibilità. Se ogni ssh_exec avesse aperto una scheda, quella sessione ne avrebbe prodotte 166. Quindi ssh_exec non ne apriva nessuna, e per due mesi l'unico posto dove vedere quei comandi è stato, ancora una volta, la conversazione dell'agente.

Un registro per connessione

La versione che abbiamo rilasciato il 29 ottobre 2026 (AgentsRoom 1.242.0) tiene una regola: nessuna scheda per comando. Al suo posto, ogni chiamata finisce in un registro, uno per connessione.

• La scheda Attività del pannello destro, accanto a File, Modifiche e Test, elenca come card le connessioni toccate dagli agenti (ultimo comando, agente, ora, stato) e le 40 chiamate più recenti su una cronologia. Si filtra per agente e cerca nei comandi, nei nomi delle connessioni e nell'output.
• Il registro di una connessione si legge come un terminale: agente · ora, poi $ comando, poi l'output, poi Completato · codice 0 · 1,2 s. L'output SSH scorre in diretta e la vista segue il fondo finché non scorri verso l'alto. Un pulsante copia l'intero registro come testo.
• Pillole nell'intestazione dell'agente, una per ogni server, database o cluster toccato da quell'agente, con un punto verde durante una chiamata. Un clic apre quel registro.
• Un badge Agente al lavoro sulla riga della connessione nelle finestre Server, Database e Kubernetes, solo mentre una chiamata è in corso.

Il registro è in sola lettura. Per scrivere tu stesso sulla macchina, la scheda SSH della finestra Server resta la porta d'ingresso. La pagina completa della funzionalità è quella del gestore di connessioni SSH, e la parte database è su connessioni database.

Cosa viene registrato, e cosa no

L'ultima riga è il limite onesto. Il registro vede ciò che passa per i nostri strumenti. Se vuoi che ogni azione remota compaia lì, gli strumenti devono essere la strada più facile per l'agente, che è la lezione dei 166 comandi.

Un ultimo dettaglio: solo SSH trasmette l'output mentre il comando gira, perché passa per un vero terminale sulla tua macchina. I risultati di WinRM, SQL e kubectl compaiono quando la chiamata finisce.

Quanto costa tenere il registro

I nostri utenti fanno girare molti agenti insieme: 45 agenti su 18 progetti su una macchina, 48 console su un'altra. Tutto ciò che si conta per agente o per blocco di output viene moltiplicato per questi numeri, quindi il registro ha limiti fissi:

• 120 chiamate per progetto, le più vecchie escono per prime.
• 32.000 caratteri di output per chiamata, tenendo la fine, che è dove stanno gli errori e i codici di uscita.
• 2.000 caratteri di comando o di SQL per chiamata.
• Un messaggio di aggiornamento per chiamata ogni 120 ms per l'output in diretta, mai uno per ogni blocco di output del terminale.
• Nessun timer a riposo. Finché nessun agente chiama uno strumento remoto, il registro non costa nulla.

La registrazione avviene in un solo punto: il ponte da cui passano le chiamate agli strumenti di tutti i CLI. Per questo funziona allo stesso modo per Claude Code, Codex, Antigravity CLI o qualsiasi altro CLI che l'app esegue, senza codice specifico per provider.

Il limite che abbiamo scelto: niente lascia la macchina

Il registro è conservato nella memoria dell'app desktop e sparisce quando la chiudi. Non viene sincronizzato con i nostri server, cosa insolita per noi: quasi tutto il resto di AgentsRoom segue il tuo account da un computer all'altro.

Questo no, apposta. L'output di un env su un server contiene segreti. Un SELECT su una tabella clienti contiene dati dei clienti. Uno strumento fatto per rendere visibili queste cose non dovrebbe, per giunta, copiarle da un'altra parte.

Il telefono può seguire lo stesso registro dal profilo dell'agente (app mobile 2.47 e successive). Il flusso va dal tuo computer al tuo telefono attraverso il collegamento cifrato end-to-end, i segreti vengono mascherati prima di partire (chiavi API, coppie CHIAVE=valore, password negli URL, token) e niente viene salvato su un server. La stessa chiamata resta leggibile anche nella conversazione dell'agente, come prima.

Gli audit log di Claude Code sono un'altra cosa

Se hai cercato "Claude Code audit log", probabilmente hai trovato la Compliance API di Anthropic per Claude Enterprise: un feed di attività, eventi di audit log e, per le sessioni locali collegate all'account Enterprise, le trascrizioni delle sessioni. È pensata per amministratori e team di compliance, copre l'organizzazione e si legge a cose fatte.

Risponde a "chi, in azienda, ha fatto cosa con Claude". Non risponde a "quale comando sta eseguendo il mio agente in questo momento sul server del database". Le due cose possono convivere, e se lavori in un'azienda con requisiti di compliance, probabilmente ti serve la prima, qualunque cosa tu usi per la seconda.

Se non usi AgentsRoom

Puoi ottenere buona parte di tutto questo con quello che i CLI offrono già.

Registra ogni comando di shell nel momento in cui parte. Gli hook di Claude Code possono eseguire un comando prima di ogni chiamata a uno strumento. La guida agli hook mostra lo schema: un hook PreToolUse sullo strumento Bash che manda jq -r .tool_input.command in un file di log. Lancia tail -f su quel file in un secondo terminale e vedi ogni comando nell'istante in cui l'agente lo invia, righe ssh comprese.

Leggi la trascrizione quando ti serve l'output. L'hook ti dà il comando, non quello che ha risposto il server. Per quello, il file di sessione in ~/.claude/projects/ (o ~/.codex/sessions/ per Codex) contiene il risultato completo di ogni chiamata.

Dai all'agente un account tutto suo sul server. Un utente dedicato rende ogni connessione attribuibile nel log di autenticazione del server, e se i tuoi server usano auditd, una regola su execve per quell'utente registra ogni processo che avvia, lato server, dove l'agente non può saltarla.

Tieni le credenziali fuori dalla portata dell'agente. Se l'unico modo per collegarsi è una password che l'agente deve chiederti, vedrai righe sshpass nella chat. Usa una chiave che l'agente non legge mai, o uno strumento che custodisce il segreto al posto suo. Abbiamo scritto una guida a parte su come dare un segreto a un agente senza metterlo nel prompt.

Quello che questa configurazione non ti dà è il legame fra le tre cose: quale agente, su quale connessione, con quale output in diretta, in un unico posto. È la parte che abbiamo costruito noi.

Le domande che ci fanno davvero

Posso vedere cosa fa Claude Code su un server remoto mentre lavora?

Nel terminale vedi la chiamata allo strumento e, quando finisce, un risultato abbreviato. Il comando completo e il suo output vengono scritti nella trascrizione della sessione sul tuo disco, che leggi dopo. Per seguirlo in diretta ti serve qualcosa che registri ogni chiamata nel momento in cui parte: un hook di Claude Code che scrive ogni comando Bash in un file di log, oppure un'app che esegue le chiamate remote per conto dell'agente e le mostra in diretta, che è quello che fa la scheda Attività di AgentsRoom.

Dove tiene Claude Code traccia dei comandi che ha eseguito?

Nella trascrizione della sessione, un file JSONL in ~/.claude/projects/, una cartella per progetto e un file per sessione. Ogni chiamata a uno strumento è una riga con il suo input e il suo risultato. Codex tiene un file simile per sessione in ~/.codex/sessions/. Sono entrambi completi, ed entrambi sono scritti perché il CLI possa riprendere una sessione, non perché una persona li scorra.

È la stessa cosa degli audit log di Claude Code?

No. Gli audit log che si cercano con quel nome sono i registri a livello di organizzazione che Anthropic offre nel piano Enterprise tramite la Compliance API: un feed di attività, eventi di audit e, per le sessioni collegate all'account, le trascrizioni, lette più tardi da un amministratore. Rispondono alla domanda chi ha fatto cosa nell'organizzazione. Una vista in diretta dei comandi su un server è un altro strumento, per un'altra persona.

Perché non aprire una scheda di terminale per ogni comando che l'agente esegue?

Abbiamo seguito quella strada e l'abbiamo misurata: un agente che lavorava su un incidente di produzione ha lanciato 166 comandi remoti in una sola sessione. Una scheda per comando rende la barra delle schede inutilizzabile in dieci minuti. Quello che funziona è un registro per connessione, dove ogni chiamata è una voce con il suo comando, il suo output in diretta, il suo codice di uscita e la sua durata.

AgentsRoom invia i comandi e il loro output a un server?

No. Il registro vive nella memoria dell'app desktop, limitato a 120 chiamate per progetto, e sparisce quando chiudi l'app. Il telefono può seguirlo dal profilo dell'agente (app mobile 2.47 e successive): il flusso va dal tuo computer al tuo telefono attraverso il collegamento cifrato end-to-end, con i segreti mascherati, e niente viene salvato su un server.

Quali comandi dell'agente non mostra la scheda Attività?

Vengono registrate solo le chiamate che passano per gli strumenti di AgentsRoom: ssh_exec, ssh_transfer, db_query, db_schema e kube_kubectl. Un comando che l'agente lancia con il proprio strumento di shell, come una riga ssh o psql scritta a mano, è nel suo terminale e nella sua trascrizione, ma non nel registro. commands_run e ssh_connect sono esclusi apposta, perché aprono già una scheda di terminale che puoi guardare.

La versione breve

Un agente su un server ha bisogno di due cose da te: un modo di lavorare che non passi dalla tua password, e un modo per te di vedere cosa fa mentre lo fa. La prima senza la seconda ti lascia a leggere JSON a cose fatte. La seconda senza la prima viene aggirata da un agente che incolla righe sshpass.

Siamo arrivati a un registro per connessione, con limiti precisi, tenuto sulla tua macchina. Se vuoi provarlo, AgentsRoom si scarica gratis, e la pagina delle connessioni SSH mostra la configurazione passo dopo passo. Se preferisci restare solo con il tuo CLI, comincia dall'hook PreToolUse e da un tail -f: ci vogliono cinque minuti e non ti chiederai mai più quali fossero le ultime sei chiamate agli strumenti.