Jak zobaczyć, co agent kodujący AI uruchamia na twoich serwerach

Pytasz agenta DevOps, dlaczego produkcyjne API działa wolno. Agent bierze się do pracy. W jego terminalu widzisz linię, że wywołuje narzędzie, potem następną i jeszcze jedną. Sześć wywołań później informuje cię, że dysk jest zapełniony w 97 %, i proponuje wyczyszczenie katalogu z logami.

Co tak naprawdę uruchomił na tej maszynie? Które du, które find, czy już coś usunął? Odpowiedź istnieje, ale jest w transkrypcie sesji, zapisana jako JSON, i czytasz ją po fakcie. Na laptopie to w porządku. Na serwerze produkcyjnym po fakcie jest za późno, żeby powiedzieć „czekaj, nie ten folder”.

Tworzymy AgentsRoom, aplikację desktopową, która uruchamia agentów kodujących i daje im narzędzia do łączenia się z twoimi serwerami, bazami danych i klastrami. Oto historia tego, jak sprawiliśmy, że te wywołania widać w chwili, gdy się dzieją: wersja, która nie zadziałała, liczby stojące za tą, która działa, i sposób na uzyskanie tego samego, jeśli nie używasz naszej aplikacji.

Krótka odpowiedź

• CLI pokazuje ci, że narzędzie się wykonało, a nie sesję po drugiej stronie. Pełne polecenie i jego wynik trafiają do transkryptu na twoim dysku.
• Żeby oglądać to na żywo, coś musi zapisywać każde wywołanie w chwili, gdy się zaczyna, a nie gdy kończy się sesja.
• Jeden dziennik na połączenie działa. Jedna karta terminala na polecenie nie. Zmierzyliśmy 166 zdalnych poleceń w jednej sesji.
• Trzymaj ten dziennik na swojej maszynie. Linia poleceń na serwerze produkcyjnym niesie sekrety i dane klientów.
• Bez naszej aplikacji: hook w Claude Code, który dopisuje każde polecenie powłoki do pliku, daje ci większość tego, czego potrzebujesz, a transkrypt uzupełnia resztę.

Dlaczego transkrypt na serwerze nie wystarcza

Claude Code, Codex i inne CLI rzeczywiście zapisują wszystko. Claude Code zapisuje jeden plik JSONL na sesję w ~/.claude/projects/, Codex jeden w ~/.codex/sessions/. Każde wywołanie narzędzia jest tam razem z danymi wejściowymi i wynikiem.

Problemem nie jest kompletność, tylko moment i forma. Transkrypt jest pisany dla CLI, żeby mogło wznowić sesję. Czytasz go, gdy agent już skończył, przekopując się przez linie JSON. Gdy trzech agentów pracuje naraz, czytasz trzy pliki. A terminal agenta, czyli miejsce, na które faktycznie patrzysz, pokazuje tylko zwinięte podsumowanie każdego wywołania.

Przy kodzie na laptopie czytanie po fakcie to normalna pętla przeglądu: patrzysz na diff, zanim zrobisz commit. Serwer nie ma diffa. systemctl restart albo DELETE działa w chwili, w której się wykonuje.

Co próbowaliśmy najpierw, i 166 poleceń

Nasze pierwsze zdalne narzędzie dla agentów otwierało połączenie w karcie terminala. Wyglądało to dobrze: użytkownik widział sesję. Zawiodło w sposób, którego się nie spodziewaliśmy.

Narzędzie nie dawało agentowi żadnej możliwości odczytania, co działo się w karcie, którą właśnie otworzył. Więc w projekcie jednego z użytkowników agent przestał go używać. Bilans tej sesji: 16 wywołań naszego narzędzia do połączeń i 166 poleceń sshpass uruchomionych własnym narzędziem powłoki agenta, przy czym agent prosił użytkownika o hasło, a użytkownik wklejał je do czatu. Produkcyjne dane logowania wylądowały otwartym tekstem w transkryptach, w ps aux podczas wykonywania każdego polecenia i w pliku w /tmp.

Lekcja nie brzmiała „agenci są lekkomyślni”. Agent zrobił jedyną rzecz, która działała. Bezpieczne narzędzie, które nie pozwala agentowi wykonać jego pracy, zostaje ominięte, a obejście jest gorsze niż brak narzędzia.

Napisaliśmy więc ssh_exec: agent wysyła jedno polecenie, AgentsRoom wykonuje je na zapisanym połączeniu, trzymając hasło w aplikacji, i zwraca wynik oraz kod wyjścia. Agent nigdy nie widzi danych logowania i nie ma już powodu budować linii sshpass.

To rozwiązało problem bezpieczeństwa i stworzyło problem widoczności. Gdyby każde ssh_exec otwierało kartę, ta sesja wyprodukowałaby 166 kart. Więc ssh_exec nie otwierało żadnej, i przez dwa miesiące jedynym miejscem, gdzie można było zobaczyć te polecenia, była znowu rozmowa z agentem.

Jeden dziennik na połączenie

Wersja, którą wydaliśmy 29 października 2026 (AgentsRoom 1.242.0), trzyma się jednej zasady: żadnej karty na polecenie. Zamiast tego każde wywołanie trafia do dziennika, jednego na połączenie.

• Karta Aktywność w prawym panelu, obok kart Pliki, Zmiany i Testy, wyświetla połączenia, których dotknęli agenci, w formie kafelków (ostatnie polecenie, agent, godzina, stan) oraz 40 najnowszych wywołań na osi czasu. Filtruje po agencie i przeszukuje polecenia, nazwy połączeń i wyniki.
• Dziennik połączenia czyta się jak terminal: agent · godzina, potem $ polecenie, potem wynik, potem Zakończono · kod 0 · 1,2 s. Wynik SSH przewija się na żywo, a widok podąża za dołem, dopóki nie przewiniesz w górę. Przycisk kopiuje cały dziennik jako tekst.
• Pigułki w nagłówku agenta, po jednej na każdy serwer, bazę danych lub klaster, których ten agent dotknął, z zieloną kropką w trakcie wywołania. Jedno kliknięcie otwiera ten dziennik.
• Plakietka Agent przy pracy w wierszu połączenia w oknach Serwery, Bazy danych i Kubernetes, tylko gdy trwa wywołanie.

Dziennik jest tylko do odczytu. Żeby samemu pisać na maszynie, nadal wchodzisz przez kartę SSH w oknie Serwery. Pełna strona funkcji to menedżer połączeń SSH, a część dotycząca baz danych jest na stronie połączeń z bazami danych.

Co jest zapisywane, a co nie

Ostatni wiersz to uczciwa granica. Dziennik widzi to, co przechodzi przez nasze narzędzia. Jeśli chcesz, żeby każde zdalne działanie się w nim pojawiało, narzędzia muszą być dla agenta łatwiejszą drogą. To lekcja ze 166 poleceń.

Jeszcze jeden szczegół: tylko SSH przesyła wynik strumieniowo w trakcie działania polecenia, bo przechodzi przez prawdziwy terminal na twojej maszynie. Wyniki WinRM, SQL i kubectl pojawiają się po zakończeniu wywołania.

Ile kosztuje prowadzenie dziennika

Nasi użytkownicy uruchamiają wielu agentów naraz: 45 agentów w 18 projektach na jednej maszynie, 48 konsol na innej. Wszystko, co liczy się na agenta albo na fragment wyniku, zostaje przez to pomnożone, więc dziennik ma twarde limity:

• 120 wywołań na projekt, najstarsze odpadają pierwsze.
• 32 000 znaków wyniku na wywołanie, z zachowaniem końca, bo tam są błędy i kody wyjścia.
• 2000 znaków polecenia lub SQL na wywołanie.
• Jedna wiadomość z aktualizacją na wywołanie co 120 ms dla wyniku na żywo, nigdy jedna na każdy fragment wyjścia terminala.
• Żadnego timera w spoczynku. Dopóki żaden agent nie wywołuje zdalnego narzędzia, dziennik nic nie kosztuje.

Zapis odbywa się w jednym miejscu: w mostku, przez który przechodzą wywołania narzędzi wszystkich CLI. Dlatego działa tak samo dla Claude Code, Codex, Antigravity CLI i każdego innego CLI, które uruchamia aplikacja, bez osobnego kodu dla każdego providera.

Granica, którą wybraliśmy: nic nie opuszcza maszyny

Dziennik jest trzymany w pamięci aplikacji desktopowej i znika, gdy ją zamkniesz. Nie jest synchronizowany z naszymi serwerami, co jest u nas nietypowe: prawie wszystko inne w AgentsRoom podąża za twoim kontem z komputera na komputer.

Ten nie, i to celowo. Wynik env na serwerze zawiera sekrety. SELECT na tabeli klientów zawiera dane klientów. Narzędzie stworzone po to, żeby takie rzeczy pokazywać, nie powinno ich przy okazji kopiować w nowe miejsce.

Telefon może śledzić ten sam dziennik z profilu agenta (aplikacja mobilna 2.47 i nowsze). Strumień idzie z twojego komputera do telefonu przez połączenie szyfrowane end-to-end, sekrety są maskowane, zanim opuszczą komputer (klucze API, pary KEY=value, hasła w adresach URL, tokeny), i nic nie jest przechowywane na serwerze. To samo wywołanie nadal jest też czytelne w rozmowie z agentem, tak jak wcześniej.

Audit logi Claude Code to coś innego

Jeśli szukałeś frazy „Claude Code audit log”, prawdopodobnie trafiłeś na Compliance API od Anthropic dla Claude Enterprise: strumień aktywności, zdarzenia audit logu i, dla lokalnych sesji zalogowanych na konto Enterprise, transkrypty sesji. Jest zbudowane dla administratorów i zespołów ds. zgodności, obejmuje całą organizację i czyta się je po fakcie.

Odpowiada na pytanie „kto w firmie co zrobił z Claude”. Nie odpowiada na pytanie „jakie polecenie mój agent uruchamia teraz na serwerze bazy danych”. Jedno i drugie może współistnieć, a jeśli pracujesz w firmie z wymogami zgodności, pierwszego prawdopodobnie potrzebujesz niezależnie od tego, czego używasz do drugiego.

Jeśli nie używasz AgentsRoom

Sporą część tego uzyskasz tym, co CLI już oferują.

Loguj każde polecenie powłoki w chwili, gdy się zaczyna. Hooki Claude Code mogą uruchomić polecenie przed każdym wywołaniem narzędzia. Przewodnik po hookach pokazuje wzorzec: hook PreToolUse na narzędziu Bash, który przekazuje jq -r .tool_input.command do pliku logu. Uruchom tail -f na tym pliku w drugim terminalu, a zobaczysz każde polecenie w chwili, gdy agent je wysyła, łącznie z liniami ssh.

Czytaj transkrypt, gdy potrzebujesz wyniku. Hook daje ci polecenie, a nie to, co odpowiedział serwer. Do tego służy plik sesji w ~/.claude/projects/ (albo ~/.codex/sessions/ dla Codex), który zawiera pełny wynik każdego wywołania.

Daj agentowi własne konto na serwerze. Osobny użytkownik sprawia, że każde połączenie da się przypisać w logu uwierzytelniania serwera, a jeśli na twoich serwerach działa auditd, reguła na execve dla tego użytkownika zapisuje każdy uruchomiony przez niego proces, po stronie serwera, gdzie agent nie może jej ominąć.

Trzymaj dane logowania poza zasięgiem agenta. Jeśli jedynym sposobem połączenia jest hasło, o które agent musi cię poprosić, zobaczysz linie sshpass w czacie. Użyj klucza, którego agent nigdy nie czyta, albo narzędzia, które przechowuje sekret za niego. Napisaliśmy osobny przewodnik o tym, jak dać agentowi sekret, nie wpisując go do promptu.

Czego ten zestaw ci nie da, to powiązania między tymi trzema rzeczami: który agent, na którym połączeniu, z jakim wynikiem na żywo, w jednym miejscu. To właśnie tę część zbudowaliśmy.

Pytania, które ludzie naprawdę zadają

Czy mogę zobaczyć, co Claude Code robi na zdalnym serwerze, kiedy pracuje?

W terminalu widzisz wywołanie narzędzia, a gdy się zakończy, skrócony wynik. Pełne polecenie i jego wynik trafiają do transkryptu sesji na twoim dysku, który czytasz po fakcie. Żeby śledzić to na żywo, potrzebujesz czegoś, co zapisuje każde wywołanie w chwili, gdy się zaczyna: hooka w Claude Code, który zapisuje każde polecenie Bash do pliku logu, albo aplikacji, która wykonuje zdalne wywołania za agenta i pokazuje je na żywo. To właśnie robi karta Aktywność w AgentsRoom.

Gdzie Claude Code zapisuje, jakie polecenia uruchomił?

W transkrypcie sesji, pliku JSONL w ~/.claude/projects/, jeden folder na projekt i jeden plik na sesję. Każde wywołanie narzędzia to jedna linia z danymi wejściowymi i wynikiem. Codex prowadzi podobny plik dla każdej sesji w ~/.codex/sessions/. Oba są kompletne i oba są pisane po to, żeby CLI mogło wznowić sesję, a nie po to, żeby człowiek je przeglądał.

Czy to to samo co audit logi Claude Code?

Nie. Audit logi, których ludzie szukają pod tą nazwą, to zapisy na poziomie organizacji, które Anthropic oferuje w planie Enterprise przez Compliance API: strumień aktywności, zdarzenia audytowe i, dla zalogowanych sesji, transkrypty, czytane później przez administratora. Odpowiadają na pytanie, kto co zrobił w organizacji. Podgląd na żywo poleceń na jednym serwerze to inne narzędzie dla innej osoby.

Dlaczego nie otwierać jednej karty terminala na każde polecenie agenta?

Sprawdziliśmy tę drogę i ją zmierzyliśmy: agent, który zajmował się incydentem na produkcji, wysłał w jednej sesji 166 zdalnych poleceń. Jedna karta na polecenie sprawia, że po dziesięciu minutach pasek kart jest bezużyteczny. Działa jeden dziennik na połączenie, w którym każde wywołanie jest wpisem z poleceniem, wynikiem na żywo, kodem wyjścia i czasem trwania.

Czy AgentsRoom wysyła polecenia i ich wynik na jakiś serwer?

Nie. Dziennik żyje w pamięci aplikacji desktopowej, z limitem 120 wywołań na projekt, i znika, gdy zamkniesz aplikację. Telefon może go śledzić z profilu agenta (aplikacja mobilna 2.47 i nowsze): strumień idzie z twojego komputera do telefonu przez połączenie szyfrowane end-to-end, z zamaskowanymi sekretami, i nic nie jest przechowywane na serwerze.

Jakich poleceń agenta karta Aktywność nie pokazuje?

Zapisywane są tylko wywołania, które przechodzą przez narzędzia AgentsRoom: ssh_exec, ssh_transfer, db_query, db_schema i kube_kubectl. Polecenie, które agent uruchamia własnym narzędziem powłoki, na przykład gołą linię ssh albo psql, jest w jego terminalu i transkrypcie, ale nie w dzienniku. commands_run i ssh_connect są pominięte celowo, bo już otwierają kartę terminala, którą możesz oglądać.

Wersja skrócona

Agent na serwerze potrzebuje od ciebie dwóch rzeczy: sposobu pracy, który nie wymaga twojego hasła, i sposobu, żebyś widział, co robi, właśnie wtedy, gdy to robi. Pierwsze bez drugiego zostawia cię z czytaniem JSON po fakcie. Drugie bez pierwszego zostaje ominięte przez agenta, który wkleja linie sshpass.

Skończyło się na jednym dzienniku na połączenie, z limitami, trzymanym na twojej maszynie. Jeśli chcesz to wypróbować, AgentsRoom możesz pobrać za darmo, a strona o połączeniach SSH pokazuje konfigurację krok po kroku. Jeśli wolisz zostać przy samym CLI, zacznij od hooka PreToolUse i tail -f: zajmie to pięć minut i już nigdy nie będziesz się zastanawiać, czym było ostatnie sześć wywołań narzędzi.