Zien wat je AI-codeeragent op je servers uitvoert

Je vraagt een DevOps-agent waarom de productie-API traag is. Hij gaat aan de slag. In zijn terminal zie je een regel die zegt dat hij een tool aanroept, dan nog een, en nog een. Zes aanroepen later meldt hij dat de schijf voor 97 % vol is en biedt hij aan de logmap op te ruimen.

Wat heeft hij op die machine echt uitgevoerd? Welke du, welke find, heeft hij al iets verwijderd? Het antwoord bestaat, maar het staat in het transcript van de sessie, geschreven als JSON, en je leest het achteraf. Op een laptop is dat prima. Op een productieserver is achteraf te laat om te zeggen: "wacht, niet die map".

Wij bouwen AgentsRoom, een desktop-app die codeeragents draait en ze tools geeft om je servers, databases en clusters te bereiken. Dit is het verhaal van hoe we die aanroepen zichtbaar hebben gemaakt terwijl ze gebeuren: de versie die niet werkte, de cijfers achter de versie die wel werkt, en hoe je hetzelfde krijgt als je onze app niet gebruikt.

Het korte antwoord

• De CLI laat je zien dát een tool gedraaid heeft, niet de sessie aan de andere kant. Het volledige commando en de uitvoer gaan naar het transcript op je schijf.
• Om live mee te kijken moet iets elke aanroep vastleggen wanneer hij start, niet wanneer de sessie eindigt.
• Eén logboek per verbinding werkt. Eén terminaltabblad per commando niet. We hebben 166 externe commando's in één sessie gemeten.
• Houd dat logboek op je eigen machine. Een commandoregel op een productieserver bevat geheimen en klantgegevens.
• Zonder onze app: een hook in Claude Code die elk shellcommando aan een bestand toevoegt, brengt je het grootste deel van de weg, en het transcript doet de rest.

Waarom het transcript op een server niet genoeg is

Claude Code, Codex en de andere CLI's leggen wel degelijk alles vast. Claude Code schrijft één JSONL-bestand per sessie onder ~/.claude/projects/, Codex één onder ~/.codex/sessions/. Elke toolaanroep staat erin, met zijn invoer en zijn resultaat.

Het probleem is niet de volledigheid, maar het moment en de vorm. Het transcript is geschreven voor de CLI, zodat die een sessie kan hervatten. Je leest het als de agent gestopt is, door regels JSON door te spitten. Als drie agents tegelijk werken, lees je drie bestanden. En de terminal van de agent, de plek waar je echt naar kijkt, toont van elke aanroep alleen een ingeklapte samenvatting.

Voor code op je laptop is achteraf lezen de normale reviewlus: je bekijkt de diff voordat je commit. Een server heeft geen diff. Een systemctl restart of een DELETE heeft effect op het moment dat hij draait.

Wat we eerst probeerden, en de 166 commando's

Onze eerste externe tool voor agents opende een verbinding in een terminaltabblad. Dat leek goed: de gebruiker kon de sessie zien. Het mislukte op een manier die we niet hadden verwacht.

De tool gaf de agent geen enkele manier om te lezen wat er gebeurde in het tabblad dat hij net had geopend. Dus stopte de agent in het project van een gebruiker met het gebruik ervan. De telling in die sessie: 16 aanroepen van onze verbindingstool, en 166 sshpass-commando's uitgevoerd via de eigen shelltool van de agent, waarbij de agent de gebruiker om het wachtwoord vroeg en de gebruiker het in de chat plakte. Inloggegevens voor productie kwamen in platte tekst terecht in de transcripten, in ps aux terwijl elk commando draaide, en in een bestand onder /tmp.

De les was niet "agents zijn roekeloos". De agent deed het enige wat werkte. Een veilige tool die de agent zijn werk niet laat doen, wordt omzeild, en die omweg is erger dan helemaal geen tool.

Dus schreven we ssh_exec: de agent stuurt één commando, AgentsRoom voert het uit op de opgeslagen verbinding met het wachtwoord bewaard in de app, en geeft de uitvoer en de exitcode terug. De agent ziet de inloggegevens nooit en heeft geen reden meer om een sshpass-regel te bouwen.

Dat loste het beveiligingsprobleem op en schiep een zichtbaarheidsprobleem. Als elke ssh_exec een tabblad had geopend, had die sessie 166 tabbladen opgeleverd. Dus opende ssh_exec er geen, en twee maanden lang was de enige plek om die commando's te zien, opnieuw, het gesprek van de agent.

Eén logboek per verbinding

De versie die we op 29 oktober 2026 hebben uitgebracht (AgentsRoom 1.242.0) houdt vast aan één regel: geen tabblad per commando. In plaats daarvan komt elke aanroep in een logboek terecht, één per verbinding.

• Het tabblad Activiteit in het rechterpaneel, naast Bestanden, Wijzigingen en Tests, toont de verbindingen die agents hebben aangeraakt als kaarten (laatste commando, agent, tijd, status) en de 40 recentste aanroepen op een tijdlijn. Het filtert op agent en doorzoekt commando's, verbindingsnamen en uitvoer.
• Het logboek van een verbinding leest als een terminal: agent · tijd, dan $ commando, dan de uitvoer, dan Voltooid · exitcode 0 · 1,2 s. SSH-uitvoer scrolt live mee en de weergave volgt de onderkant tot je omhoog scrolt. Een knop kopieert het hele logboek als tekst.
• Pillen in de header van de agent, één per server, database of cluster die die agent heeft aangeraakt, met een groene stip tijdens een aanroep. Eén klik opent dat logboek.
• Een badge Agent aan het werk op de regel van de verbinding in de vensters Servers, Databases en Kubernetes, alleen zolang een aanroep loopt.

Het logboek is alleen-lezen. Om zelf op de machine te typen, blijft het SSH-tabblad van het venster Servers de ingang. De volledige featurepagina is de SSH-verbindingbeheerder, en de databasekant staat op databaseverbindingen.

Wat wordt vastgelegd, en wat niet

De laatste regel is de eerlijke grens. Het logboek ziet wat via onze tools loopt. Wil je dat elke externe actie daar verschijnt, dan moeten de tools de makkelijkste weg zijn voor de agent. Dat is de les van de 166 commando's.

Nog een detail: alleen SSH streamt uitvoer terwijl het commando draait, omdat het via een echte terminal op je machine gaat. Resultaten van WinRM, SQL en kubectl verschijnen als de aanroep klaar is.

Wat het bijhouden van het logboek kost

Onze gebruikers draaien veel agents tegelijk: 45 agents verdeeld over 18 projecten op de ene machine, 48 consoles op een andere. Alles wat per agent of per stuk uitvoer wordt geteld, wordt daarmee vermenigvuldigd, dus het logboek heeft harde grenzen:

• 120 aanroepen per project, de oudste verdwijnen eerst.
• 32.000 tekens uitvoer per aanroep, waarbij het einde bewaard blijft, want daar staan fouten en exitcodes.
• 2.000 tekens commando of SQL per aanroep.
• Eén updatebericht per aanroep elke 120 ms voor live uitvoer, nooit één per stuk terminaluitvoer.
• Geen timer in rust. Zolang geen agent een externe tool aanroept, kost het logboek niets.

Het vastleggen gebeurt op één punt: de brug waar de toolaanroepen van elke CLI doorheen gaan. Daarom werkt het hetzelfde voor Claude Code, Codex, Antigravity CLI of een van de andere CLI's die de app draait, zonder code per provider.

De grens die we kozen: niets verlaat de machine

Het logboek wordt in het geheugen van de desktop-app bewaard en verdwijnt als je de app afsluit. Het wordt niet gesynchroniseerd met onze servers, wat ongebruikelijk is voor ons: bijna al het andere in AgentsRoom volgt je account van computer naar computer.

Dit niet, en dat is bewust. De uitvoer van een env op een server bevat geheimen. Een SELECT op een klantentabel bevat klantgegevens. Een tool die zulke dingen zichtbaar moet maken, hoort ze niet ook nog ergens anders naartoe te kopiëren.

Je telefoon kan hetzelfde logboek volgen vanuit het profiel van de agent (mobiele app 2.47 en hoger). De stroom gaat van je computer naar je telefoon via de end-to-end versleutelde verbinding, geheimen worden gemaskeerd voordat ze vertrekken (API-sleutels, KEY=value-paren, wachtwoorden in URL's, tokens), en er wordt niets op een server opgeslagen. Dezelfde aanroep blijft ook leesbaar in het gesprek van de agent, zoals voorheen.

Audit logs van Claude Code zijn iets anders

Als je hebt gezocht op "Claude Code audit log", ben je waarschijnlijk uitgekomen bij de Compliance API van Anthropic voor Claude Enterprise: een activiteitenfeed, auditloggebeurtenissen en, voor lokale sessies die zijn aangemeld bij het Enterprise-account, de transcripten van de sessies. Die is gebouwd voor beheerders en complianceteams, dekt de organisatie af, en je leest hem achteraf.

Dat beantwoordt "wie in het bedrijf deed wat met Claude". Het beantwoordt niet "welk commando voert mijn agent nu uit op de databaseserver". Die twee kunnen naast elkaar bestaan, en als je werkt in een bedrijf met compliance-eisen, heb je de eerste waarschijnlijk hoe dan ook nodig, wat je ook gebruikt voor de tweede.

Als je AgentsRoom niet gebruikt

Een groot deel hiervan krijg je met wat de CLI's al bieden.

Log elk shellcommando zodra het start. Hooks van Claude Code kunnen vóór elke toolaanroep een commando uitvoeren. De hooks-gids toont het patroon: een PreToolUse-hook op de tool Bash die jq -r .tool_input.command naar een logbestand stuurt. Draai tail -f op dat bestand in een tweede terminal en je ziet elk commando op het moment dat de agent het verstuurt, ssh-regels inbegrepen.

Lees het transcript als je de uitvoer nodig hebt. De hook geeft je het commando, niet wat de server antwoordde. Daarvoor bevat het sessiebestand onder ~/.claude/projects/ (of ~/.codex/sessions/ voor Codex) het volledige resultaat van elke aanroep.

Geef de agent een eigen account op de server. Een aparte gebruiker maakt elke verbinding herleidbaar in het authenticatielog van de server, en als je servers auditd draaien, legt een regel op execve voor die gebruiker elk proces vast dat hij start, aan de serverkant, waar de agent er niet omheen kan.

Houd inloggegevens buiten bereik van de agent. Als de enige manier om verbinding te maken een wachtwoord is dat de agent jou moet vragen, zie je sshpass-regels in de chat. Gebruik een sleutel die de agent nooit leest, of een tool die het geheim voor hem bewaart. We schreven een aparte gids over hoe je een agent een geheim geeft zonder het in de prompt te zetten.

Wat deze opzet je niet geeft, is het verband tussen de drie: welke agent, op welke verbinding, met welke live uitvoer, op één plek. Dat is het deel dat wij hebben gebouwd.

Vragen die mensen echt stellen

Kan ik zien wat Claude Code op een externe server doet terwijl het werkt?

In de terminal zie je de toolaanroep en, zodra die klaar is, een ingekort resultaat. Het volledige commando en de uitvoer ervan worden in het transcript van de sessie op je schijf geschreven, en dat lees je achteraf. Om live mee te kijken heb je iets nodig dat elke aanroep vastlegt op het moment dat hij start: een hook in Claude Code die elk Bash-commando naar een logbestand schrijft, of een app die de externe aanroepen voor de agent uitvoert en ze live toont. Dat is precies wat het tabblad Activiteit van AgentsRoom doet.

Waar houdt Claude Code bij welke commando's het heeft uitgevoerd?

In het transcript van de sessie, een JSONL-bestand onder ~/.claude/projects/, één map per project en één bestand per sessie. Elke toolaanroep is daar een regel met zijn invoer en zijn resultaat. Codex houdt een vergelijkbaar bestand per sessie bij onder ~/.codex/sessions/. Beide zijn volledig, en beide zijn geschreven zodat de CLI een sessie kan hervatten, niet zodat een mens ze doorleest.

Is dit hetzelfde als de audit logs van Claude Code?

Nee. De audit logs die mensen onder die naam zoeken, zijn de registraties op organisatieniveau die Anthropic in zijn Enterprise-abonnement aanbiedt via de Compliance API: een activiteitenfeed, auditgebeurtenissen en, voor aangemelde sessies, de transcripten, die een beheerder later leest. Ze beantwoorden wie wat deed in de organisatie. Een liveweergave van de commando's op één server is een ander hulpmiddel voor een andere persoon.

Waarom niet één terminaltabblad openen per commando van de agent?

Die weg hebben we geprobeerd en gemeten: een agent die een productie-incident behandelde, vuurde in één sessie 166 externe commando's af. Eén tabblad per commando maakt de tabbladbalk na tien minuten onbruikbaar. Wat werkt is één logboek per verbinding, waarin elke aanroep een item is met zijn commando, zijn live uitvoer, zijn exitcode en zijn duur.

Stuurt AgentsRoom de commando's en hun uitvoer naar een server?

Nee. Het logboek leeft in het geheugen van de desktop-app, begrensd op 120 aanroepen per project, en het is weg als je de app afsluit. Je telefoon kan het volgen vanuit het profiel van de agent (mobiele app 2.47 en hoger): de stroom gaat van je computer naar je telefoon via de end-to-end versleutelde verbinding, met gemaskeerde geheimen, en er wordt niets op een server opgeslagen.

Welke commando's van de agent toont het tabblad Activiteit niet?

Alleen aanroepen die via de tools van AgentsRoom lopen, worden vastgelegd: ssh_exec, ssh_transfer, db_query, db_schema en kube_kubectl. Een commando dat de agent met zijn eigen shelltool uitvoert, zoals een kale ssh- of psql-regel, staat in zijn terminal en zijn transcript, maar niet in het logboek. commands_run en ssh_connect zijn bewust weggelaten, omdat ze al een terminaltabblad openen waarin je kunt meekijken.

De korte versie

Een agent op een server heeft twee dingen van je nodig: een manier van werken waar jouw wachtwoord niet aan te pas komt, en een manier voor jou om te zien wat hij doet terwijl hij het doet. Het eerste zonder het tweede laat je achteraf JSON lezen. Het tweede zonder het eerste wordt omzeild door een agent die sshpass-regels plakt.

We kwamen uit op één logboek per verbinding, begrensd en bewaard op je eigen machine. Wil je het proberen, dan is AgentsRoom gratis te downloaden, en de pagina over SSH-verbindingen toont de installatie stap voor stap. Blijf je liever alleen bij je CLI, begin dan met de PreToolUse-hook en een tail -f: het kost vijf minuten en je vraagt je nooit meer af wat die laatste zes toolaanroepen waren.