Cómo ver lo que tu agente de código ejecuta en tus servidores

Le preguntas a un agente DevOps por qué la API de producción va lenta. Se pone a trabajar. En su terminal ves una línea que dice que está llamando a una herramienta, luego otra, luego otra. Seis llamadas después te dice que el disco está al 97 % y te propone vaciar la carpeta de logs.

¿Qué ha ejecutado de verdad en esa máquina? ¿Qué du, qué find, ya ha borrado algo? La respuesta existe, pero está en la transcripción de la sesión, escrita en JSON, y la lees a posteriori. En un portátil, vale. En un servidor de producción, a posteriori es demasiado tarde para decir "espera, esa carpeta no".

Desarrollamos AgentsRoom, una app de escritorio que ejecuta agentes de código y les da herramientas para llegar a tus servidores, bases de datos y clústeres. Esta es la historia de cómo hicimos visibles esas llamadas mientras ocurren, la versión que no funcionó, las cifras de la que funciona y cómo conseguir lo mismo si no usas nuestra app.

La respuesta corta

• El CLI te muestra que una herramienta se ha ejecutado, no la sesión del otro lado. El comando completo y su salida van a la transcripción en tu disco.
• Para verlo en directo, algo tiene que registrar cada llamada en el momento en que sale, no cuando termina la sesión.
• Un registro por conexión funciona. Una pestaña de terminal por comando, no. Medimos 166 comandos remotos en una sola sesión.
• Guarda ese registro en tu máquina. Una línea de comando en un servidor de producción lleva secretos y datos de clientes.
• Sin nuestra app: un hook de Claude Code que añade cada comando de shell a un archivo te lleva casi todo el camino, y la transcripción te da el resto.

Por qué la transcripción no basta en un servidor

Claude Code, Codex y los demás CLI lo registran todo. Claude Code escribe un archivo JSONL por sesión en ~/.claude/projects/, Codex uno en ~/.codex/sessions/. Cada llamada a una herramienta está ahí, con su entrada y su resultado.

El problema no es que falte información, es el momento y la forma. La transcripción está escrita para el CLI, para que pueda retomar una sesión. La lees cuando el agente ya se ha parado, rebuscando entre líneas de JSON. Cuando trabajan tres agentes a la vez, lees tres archivos. Y la terminal del agente, el sitio que de verdad estás mirando, solo muestra un resumen plegado de cada llamada.

Para código en tu portátil, revisar después es el ciclo normal: miras el diff antes de hacer commit. Un servidor no tiene diff. Un systemctl restart o un DELETE surte efecto en el instante en que se ejecuta.

Lo que probamos primero, y los 166 comandos

Nuestra primera herramienta remota para agentes abría una conexión en una pestaña de terminal. Parecía lo correcto: el usuario veía la sesión. Falló de una forma que no esperábamos.

La herramienta no le daba al agente ninguna forma de leer lo que pasaba en la pestaña que acababa de abrir. Así que, en el proyecto de un usuario, el agente dejó de usarla. El recuento de esa sesión: 16 llamadas a nuestra herramienta de conexión y 166 comandos sshpass ejecutados con la propia herramienta de shell del agente, con el agente pidiéndole la contraseña al usuario y el usuario pegándola en el chat. Las credenciales de producción acabaron en texto plano en las transcripciones, en ps aux mientras corría cada comando y en un archivo dentro de /tmp.

La lección no fue "los agentes son imprudentes". El agente hizo lo único que funcionaba. Una herramienta segura que no deja al agente hacer su trabajo acaba esquivada, y el atajo es peor que no tener herramienta.

Así que escribimos ssh_exec: el agente envía un comando, AgentsRoom lo ejecuta en la conexión guardada con la contraseña guardada en la app, y devuelve la salida y el código de salida. El agente nunca ve la credencial y no tiene ningún motivo para montar una línea sshpass.

Eso resolvió el problema de seguridad y creó uno de visibilidad. Si cada ssh_exec abriera una pestaña, esa sesión habría generado 166. Así que ssh_exec no abría ninguna, y durante dos meses el único sitio donde ver esos comandos fue, otra vez, la conversación del agente.

Un registro por conexión

La versión que publicamos el 29 de octubre de 2026 (AgentsRoom 1.242.0) mantiene una regla: ninguna pestaña por comando. En su lugar, cada llamada llega a un registro, uno por conexión.

• La pestaña Actividad del panel derecho, junto a Archivos, Cambios y Pruebas, muestra como tarjetas las conexiones que han tocado los agentes (último comando, agente, hora, estado) y las 40 llamadas más recientes en una línea de tiempo. Se filtra por agente y busca en los comandos, los nombres de conexión y la salida.
• El registro de una conexión se lee como una terminal: agente · hora, luego $ comando, luego la salida, luego Completado · código 0 · 1,2 s. La salida SSH aparece en directo y la vista sigue el final hasta que subes. Un botón copia todo el registro como texto.
• Pastillas en la cabecera del agente, una por servidor, base de datos o clúster que ese agente ha tocado, con un punto verde durante una llamada. Un clic abre ese registro.
• Una insignia Agente trabajando en la fila de la conexión en las ventanas Servidores, Bases de datos y Kubernetes, solo mientras corre una llamada.

El registro es de solo lectura. Para escribir tú mismo en la máquina, la pestaña SSH de la ventana Servidores sigue siendo la puerta de entrada. La página completa de la función es la del gestor de conexiones SSH, y la parte de bases de datos está en conexiones de base de datos.

Qué se registra y qué no

La última fila es el límite honesto. El registro ve lo que pasa por nuestras herramientas. Si quieres que cada acción remota aparezca ahí, las herramientas tienen que ser el camino más fácil para el agente, que es la lección de los 166 comandos.

Un detalle más: solo SSH muestra la salida mientras corre el comando, porque pasa por una terminal real en tu máquina. Los resultados de WinRM, SQL y kubectl aparecen cuando termina la llamada.

Lo que cuesta mantener el registro

Nuestros usuarios ejecutan muchos agentes a la vez: 45 agentes en 18 proyectos en una máquina, 48 consolas en otra. Todo lo que se cuenta por agente o por fragmento de salida se multiplica por esas cifras, así que el registro tiene límites fijos:

• 120 llamadas por proyecto, las más antiguas se descartan primero.
• 32.000 caracteres de salida por llamada, conservando el final, que es donde están los errores y los códigos de salida.
• 2.000 caracteres de comando o de SQL por llamada.
• Un mensaje de actualización por llamada cada 120 ms para la salida en directo, nunca uno por fragmento de salida de la terminal.
• Ningún temporizador en reposo. Mientras ningún agente llama a una herramienta remota, el registro no cuesta nada.

El registro se hace en un único punto: el puente por el que pasan las llamadas a herramientas de todos los CLI. Por eso funciona igual con Claude Code, Codex, Antigravity CLI o cualquiera de los otros CLI que ejecuta la app, sin código específico por proveedor.

El límite que elegimos: nada sale de la máquina

El registro se guarda en la memoria de la app de escritorio y desaparece cuando la cierras. No se sincroniza con nuestros servidores, algo poco habitual en nosotros: casi todo lo demás en AgentsRoom sigue a tu cuenta de un ordenador a otro.

Esto no, a propósito. La salida de un env en un servidor contiene secretos. Un SELECT sobre una tabla de clientes contiene datos de clientes. Una herramienta hecha para hacer visibles esas cosas no debería, además, copiarlas en otro sitio.

El móvil puede seguir el mismo registro desde el perfil del agente (app móvil 2.47 y posteriores). El flujo va de tu ordenador a tu móvil por el enlace cifrado de extremo a extremo, los secretos se enmascaran antes de salir (claves de API, pares CLAVE=valor, contraseñas en URL, tokens) y no se guarda nada en ningún servidor. La misma llamada sigue siendo legible en la conversación del agente, como antes.

Los audit logs de Claude Code son otra cosa

Si buscaste "Claude Code audit log", seguramente encontraste la Compliance API de Anthropic para Claude Enterprise: un feed de actividad, eventos de audit log y, para las sesiones locales iniciadas con la cuenta Enterprise, las transcripciones de las sesiones. Está pensada para administradores y equipos de cumplimiento normativo, cubre la organización y se lee a posteriori.

Eso responde a "quién en la empresa hizo qué con Claude". No responde a "qué comando está ejecutando mi agente ahora mismo en el servidor de base de datos". Las dos cosas pueden convivir, y si trabajas en una empresa con obligaciones de cumplimiento normativo, probablemente necesites la primera, uses lo que uses para la segunda.

Si no usas AgentsRoom

Puedes conseguir buena parte de esto con lo que los CLI ya ofrecen.

Registra cada comando de shell en el momento en que sale. Los hooks de Claude Code pueden ejecutar un comando antes de cada llamada a una herramienta. La guía de hooks muestra el patrón: un hook PreToolUse sobre la herramienta Bash que envía jq -r .tool_input.command a un archivo de log. Lanza tail -f sobre ese archivo en una segunda terminal y verás cada comando en el instante en que el agente lo envía, líneas ssh incluidas.

Lee la transcripción cuando necesites la salida. El hook te da el comando, no lo que respondió el servidor. Para eso, el archivo de sesión en ~/.claude/projects/ (o ~/.codex/sessions/ para Codex) tiene el resultado completo de cada llamada.

Dale al agente su propia cuenta en el servidor. Un usuario dedicado hace que cada conexión sea atribuible en el log de autenticación del servidor, y si tus servidores usan auditd, una regla sobre execve para ese usuario registra cada proceso que lanza, del lado del servidor, donde el agente no puede saltársela.

Mantén las credenciales fuera del alcance del agente. Si la única forma de conectarse es una contraseña que el agente tiene que pedirte, verás líneas sshpass en el chat. Usa una clave que el agente nunca lea, o una herramienta que guarde el secreto por él. Escribimos una guía aparte sobre cómo darle un secreto a un agente sin ponerlo en el prompt.

Lo que este montaje no te da es el vínculo entre las tres cosas: qué agente, en qué conexión, con qué salida en directo, en un solo sitio. Esa es la parte que construimos.

Las preguntas que de verdad nos hacen

¿Puedo ver lo que hace Claude Code en un servidor remoto mientras trabaja?

En la terminal ves la llamada a la herramienta y, cuando termina, un resultado resumido. El comando completo y su salida se escriben en la transcripción de la sesión en tu disco, que lees después. Para seguirlo en directo necesitas algo que registre cada llamada en el momento en que sale: un hook de Claude Code que escriba cada comando Bash en un archivo de log, o una app que ejecute las llamadas remotas por el agente y las muestre en directo, que es lo que hace la pestaña Actividad de AgentsRoom.

¿Dónde guarda Claude Code el rastro de los comandos que ha ejecutado?

En la transcripción de la sesión, un archivo JSONL en ~/.claude/projects/, una carpeta por proyecto y un archivo por sesión. Cada llamada a una herramienta es una línea con su entrada y su resultado. Codex guarda un archivo parecido por sesión en ~/.codex/sessions/. Los dos están completos, y los dos están escritos para que el CLI retome una sesión, no para que una persona los recorra.

¿Es lo mismo que los audit logs de Claude Code?

No. Los audit logs que la gente busca con ese nombre son los registros a nivel de organización que Anthropic ofrece en su plan Enterprise a través de la Compliance API: un feed de actividad, eventos de auditoría y, para las sesiones iniciadas con la cuenta, las transcripciones, que un administrador lee más tarde. Responden a quién hizo qué en la organización. Una vista en directo de los comandos en un servidor es otra herramienta, para otra persona.

¿Por qué no abrir una pestaña de terminal por cada comando que ejecuta el agente?

Probamos ese camino y lo medimos: un agente que trabajaba en una incidencia de producción lanzó 166 comandos remotos en una sola sesión. Una pestaña por comando deja la barra de pestañas inservible en diez minutos. Lo que funciona es un registro por conexión, donde cada llamada es una entrada con su comando, su salida en directo, su código de salida y su duración.

¿AgentsRoom envía los comandos y su salida a un servidor?

No. El registro vive en la memoria de la app de escritorio, limitado a 120 llamadas por proyecto, y desaparece cuando cierras la app. El móvil puede seguirlo desde el perfil del agente (app móvil 2.47 y posteriores): el flujo va de tu ordenador a tu móvil por el enlace cifrado de extremo a extremo, con los secretos enmascarados, y no se guarda nada en ningún servidor.

¿Qué comandos del agente no muestra la pestaña Actividad?

Solo se registran las llamadas que pasan por las herramientas de AgentsRoom: ssh_exec, ssh_transfer, db_query, db_schema y kube_kubectl. Un comando que el agente lanza con su propia herramienta de shell, como una línea ssh o psql escrita a mano, está en su terminal y en su transcripción, pero no en el registro. commands_run y ssh_connect se dejan fuera a propósito, porque ya abren una pestaña de terminal que puedes mirar.

La versión corta

Un agente en un servidor necesita dos cosas de ti: una forma de trabajar que no pase por tu contraseña, y una forma de que tú veas lo que hace mientras lo hace. Lo primero sin lo segundo te deja leyendo JSON a posteriori. Lo segundo sin lo primero acaba esquivado por un agente que pega líneas sshpass.

Acabamos con un registro por conexión, acotado, guardado en tu máquina. Si quieres probarlo, AgentsRoom se descarga gratis, y la página de conexiones SSH muestra la configuración paso a paso. Si prefieres quedarte solo con tu CLI, empieza por el hook PreToolUse y un tail -f: te lleva cinco minutos y no volverás a preguntarte cuáles fueron las seis últimas llamadas a herramientas.