Tabla de contenidos
El 31 de marzo de 2026, alguien descubrió un archivo .map dentro de la versión 2.1.88 del paquete npm @anthropic-ai/claude-code. Ese source map contenía el código fuente completo — sin ofuscar — y apuntaba a un zip en el almacenamiento R2 de Cloudflare de Anthropic. En cuestión de horas, el código estaba clonado en más de 8.100 repositorios de GitHub. Unas 1.900 archivos. Más de 512.000 líneas de TypeScript de producción. Todo: herramientas, comandos, system prompts, arquitectura de permisos, orquestación multi-agente, gestión de contexto, y 44 feature flags de capacidades no lanzadas.
Anthropic lo calificó de “error de empaquetado causado por error humano” y empezó a emitir DMCAs. Pero hay un detalle que me chirría: diez días antes de que el paquete se publicara en npm, Anthropic ya estaba enviando amenazas legales para proteger este mismo código fuente. Y el “error” requería un cambio específico en la configuración del build. ¿Incompetencia o marketing? Cada feature no lanzada que se filtró — un agente siempre activo, sesiones de planificación autónoma de 30 minutos, un sistema de mascotas virtuales — está recibiendo cobertura gratuita en todos los medios tech. Tú decides.
Como uso Claude Code varias horas al día, lo analicé. No por morbo — porque llevo meses trabajando con esta herramienta y quería entender por qué funciona como funciona.
Lo que encontré cambia bastante la idea que tenía de cómo trabajan los agentes de IA por dentro. Y lo más útil: explica cosas que ya intuía usándolo, pero que ahora tienen una explicación técnica concreta.
Aviso de seguridad: A las pocas horas de la filtración, se detectó un ataque a la cadena de suministro en el paquete npm de axios. Cualquiera que instaló o actualizó Claude Code vía npm el 31 de marzo entre las 00:21 y las 03:29 UTC pudo haber descargado una versión troyanizada con un RAT (Remote Access Trojan). También hay typosquatting con nombres internos de paquetes. Si clonas cualquiera de los repos filtrados: no ejecutes npm install, no ejecutes nada. Solo lectura. Máquina aislada o VM si es posible. Comprueba en los lockfiles si aparecen axios 1.14.1, axios 0.30.4 o la dependencia plain-crypto-js. Si los encuentras, trata esa máquina como comprometida.
Qué se filtró y qué no
Esto es importante: lo que se filtró es el código del cliente CLI. La capa de orquestación. Cómo gestiona conversaciones, elige herramientas, maneja permisos, comprime contexto cuando la ventana se llena, y coordina múltiples agentes en paralelo.
Lo que no se filtró: pesos del modelo, código de entrenamiento, backend de la API, infraestructura de seguridad/alignment, ni datos de clientes. Si Claude Code es un coche, lo que tenemos son el salpicadero y la transmisión. No el motor.
En resumen: Claude Code no es un chatbot con acceso a archivos. Es un runtime de agente completo — 512K líneas de código, 44 feature flags, un sistema de mascotas virtuales, agentes que “sueñan”, y herramientas falsas para envenenar a la competencia. El 90% es ingeniería de software clásica. La IA es el 10% restante, pero genera la mayor parte del valor.
No es un chatbot. Es un runtime de agente completo.
La primera sorpresa al abrir el código es que Claude Code no es “Claude en tu terminal”. No es un wrapper que coge tu pregunta y se la manda al modelo.
Es una aplicación completa construida con Bun, TypeScript y React. Tiene un parser de comandos, un motor de consultas (Query Engine), un bucle de ejecución de herramientas, un sistema de permisos, un gestor de tareas, un coordinador multi-agente, y un cliente y servidor MCP — todo conectado bajo un mismo pipeline de ejecución.
En cristiano: cuando escribes algo en Claude Code, tu texto pasa por un parser CLI, llega al Query Engine, se envía al LLM, el modelo decide qué herramientas usar, las herramientas se ejecutan, y el resultado vuelve a tu terminal. Y ese ciclo se repite hasta que el agente considera que ha terminado.
La superficie de herramientas
El código documenta unos 40 tipos de herramientas (agent tools) que cubren prácticamente cualquier operación que harías tú a mano: lectura/escritura/edición de archivos, grep y glob para buscar en código, ejecución de shell, notebooks, REPLs, herramientas web, MCP, LSP (Language Server Protocol), tareas, agentes, planes, y worktrees de git.
Cada herramienta tiene su propio input schema, sus propias comprobaciones de permisos, su lógica de ejecución, su renderizado en la UI, y su gestión de concurrencia. No son wrappers. Son componentes completos con ciclo de vida propio.
Lo que significa en la práctica: tus peticiones funcionan mejor cuando implican acciones concretas — leer archivos, buscar en código, editar zonas específicas, ejecutar comprobaciones, lanzar sub-agentes. Cuanto más orientado a acción es tu prompt, mejor puede Claude Code aprovechar su sistema de herramientas.
~40 herramientas internas. Cada una con su propio schema, permisos, rendering y control de concurrencia. Esto no es un chatbot — es un sistema operativo para un agente. Código fuente de Claude Code
El archivo que lo controla todo: CLAUDE.md
De todo lo que vi en el código fuente, esto es lo que más impacto práctico tiene.
Claude Code tiene un sistema de memoria completo, y el centro de ese sistema es un archivo llamado CLAUDE.md. Cuando el agente arranca una sesión, lo primero que lee es ese archivo. Antes de tu mensaje. Antes de cualquier otra cosa.
La mayoría de la gente lo ignora o le pone cuatro notas genéricas. Error. CLAUDE.md no es documentación. Es el manual de operaciones del agente.
Piénsalo así: si Claude Code es un empleado nuevo, CLAUDE.md es su onboarding. Le dice cómo trabajas, qué te importa, qué no se toca nunca, y cómo está organizado el proyecto.
Yo tengo el mío bastante currado. Le dice cosas como:
- “El contenido se escribe en español peninsular. Directo, sin fluff.”
- “Nunca cambies el slug de un post publicado sin confirmar conmigo.”
- “Los drafts van en
.ai-ops/drafts/, no ensrc/content/blog/.” - “Antes de escribir contenido, lee la estrategia editorial.”
- “Las fuentes externas van como notas al pie, no como links inline.”
Son reglas de decisión, restricciones y convenciones. No una novela sobre la historia del proyecto.
Las capas de memoria
El código fuente revela que no es solo un archivo. Hay varias capas trabajando juntas:
- Memoria a nivel de proyecto — el
CLAUDE.mdde tu repo, visible para cualquiera que trabaje en él. - Memoria a nivel de usuario — configuración global en
~/.claude/CLAUDE.md, aplicable a todos tus proyectos. - Memoria extraída — el sistema extrae y persiste información relevante automáticamente entre sesiones.
- Sincronización en equipo — mecanismos para compartir memoria entre miembros de un equipo.
Esto significa que Claude Code tiene memoria persistente a nivel de proyecto, usuario y sesión. Y CLAUDE.md es una de las entradas con más peso en cómo se comporta en cada interacción.
Si solo te llevas una cosa de este artículo: ve y curra tu archivo CLAUDE.md. Es lo que más diferencia hay entre usarlo como un chat y usarlo como un agente que entiende tu proyecto.
85 comandos que casi nadie usa
El código revela unos 85 comandos tipo slash en Claude Code. La mayoría de usuarios conoce cinco. Los que más le sacan partido al sistema los usan como atajos que cambian radicalmente el flujo de trabajo.
Los esenciales
/init genera tu CLAUDE.md inicial. Es el punto de partida para que el agente entienda tu proyecto. Si nunca lo has ejecutado, empieza por ahí.
/plan y /ultraplan ponen al agente en modo planificación. En vez de lanzarse a ejecutar, primero mapea el enfoque completo y te pregunta antes de tocar nada. El código confirma que plan mode es una feature de producto con herramientas dedicadas para entrar y salir del modo — no un truco de prompting.
/compact comprime el historial de conversación. Te quedas con el contexto importante y sueltas el ruido. Si estás quemando tokens, este es el arreglo más rápido. Puedes ejecutarlo con un prompt específico — “comprime todo pero guarda la info de la integración X”.
/review y /security-review son flujos de revisión de código estructurados. En vez de pedirle que “mire tu código”, estos comandos ejecutan un proceso de revisión completo. El hecho de que existan como comandos dedicados te dice que la revisión es un flujo de primera clase en el producto, no un añadido.
/cost te muestra cuánto llevas gastado en la sesión. La mayoría no tiene ni idea hasta que llega la factura.
/resume y /summary te permiten retomar donde lo dejaste entre sesiones sin tener que re-explicar todo desde cero.
Los que la mayoría no conoce
/memory es un comando de primera clase para gestionar la memoria persistente directamente — no solo lo que está en CLAUDE.md, sino el sistema de memoria completo entre sesiones.
/permissions te deja ver y configurar tus reglas de permisos sin salir de la sesión.
/mcp gestiona tus conexiones a servidores MCP — añadir, quitar o inspeccionar herramientas conectadas.
/tasks y /agents te dan acceso a las capacidades multi-agente y de gestión de tareas desde dentro de una sesión.
/context controla qué archivos está viendo Claude Code. Esto importa porque cada archivo en contexto te cuesta tokens.
Detalle técnico: tipos de comando
El código revela que los comandos no son simples alias. Hay tres tipos distintos en la arquitectura:
- Prompt-driven — implican al LLM para ejecutarse.
- Local text — ejecutan lógica local y devuelven texto.
- Local JSX UI — renderizan componentes de interfaz directamente en el terminal.
Es una arquitectura de comandos completa, no una lista de atajos.
Escribir mejores prompts es una palanca. Conocer estos comandos es una palanca completamente distinta que la mayoría ni toca.
Los permisos: por qué parece lento y cómo arreglarlo
Si has usado Claude Code, conoces la dinámica. Le pides algo y empieza: “¿Puedo hacer esto? ¿Me dejas editar esto? ¿Puedo ejecutar esto?” Una y otra vez.
La mayoría piensa que la solución es escribir mejor el prompt. No lo es. La solución son los permisos.
El código fuente muestra un sistema de permisos profundo con varios modos: modo por defecto (te pregunta todo), modo plan, y modos de bypass/auto donde simplemente ejecuta.
Y aquí está la joya: puedes configurar permisos con wildcards. Cosas como “permite todos los comandos de git” o “permite editar cualquier archivo en src/”. El código confirma patrones como Bash(git *) y FileEdit(/src/*).
En vez de que te pregunte 15 veces si puede ejecutar git status o editar un archivo o correr un test, configuras la regla una vez y funciona.
Esto se hace en settings.local.json o settings.json, y puedes definir permisos a tres niveles: globales, por usuario y por proyecto — cosas que siempre permites, cosas que siempre bloqueas, y cosas que quieres que pregunte.
Para flujos que repites cada día, este es uno de los cambios con más retorno. Pasas de estar vigilando cada acción a dejar que el agente opere como agente mientras tú haces otra cosa.
Está diseñado para trabajo multi-agente
El código revela un subsistema completo de coordinación: herramientas de agente, herramientas de equipo, y un sistema de tareas diseñado para trabajo en segundo plano y en paralelo.
El sistema de tareas es más complejo de lo que parece desde fuera. Distingue entre:
- Tareas de shell — ejecución de comandos.
- Agentes locales — sub-agentes que corren en tu máquina.
- Agentes remotos — agentes que pueden correr en otro sitio.
- Tareas de compañero (teammate) — tareas delegadas a otros agentes del equipo.
- Tareas en background — ejecución asíncrona mientras sigues trabajando.
Lo que significa: la arquitectura está construida para descomposición — dividir el trabajo entre varios agentes que pueden correr en paralelo. Un agente explorando tu codebase, otro escribiendo cambios, otro validando tests.
Esto lo veo en mi día a día. Cuando le pido que audite contenido, lo mejor que puedo hacer es no pedirle “audita todo y arréglalo” en un solo prompt. Lo que funciona es descomponer: primero investiga, luego planifica, luego ejecuta, luego verifica. Cada fase separada. El mismo principio que usarías organizando trabajo para un equipo de personas.
La diferencia entre un prompt de 500 palabras y cinco prompts de 100 no es estética. Es arquitectónica. El sistema está diseñado para lo segundo.
MCP: el protocolo que conecta todo
Si has oído hablar del Model Context Protocol (MCP) de Anthropic, el código fuente confirma algo importante: MCP no es solo “compatible” con Claude Code. Está integrado en la arquitectura desde la raíz.
Claude Code es a la vez cliente y servidor MCP. Puede conectarse a herramientas externas a través de MCP, y otros sistemas pueden conectarse a él.
Más profundo de lo esperado
La implementación MCP en el código es mucho más completa de lo que la documentación pública sugiere:
- Invocación de herramientas — llamar a cualquier herramienta expuesta por un servidor MCP.
- Listado y lectura de recursos — descubrir y consumir datos de servidores externos.
- Gestión de autenticación — auth handling integrado.
- Descubrimiento diferido (deferred tool discovery) — Claude Code puede encontrar y cargar herramientas nuevas de servidores MCP sobre la marcha, sin reiniciar.
- Servidor de exploración propio — el repo incluye un servidor MCP dedicado para explorar su propio árbol de código fuente. Eso te da una idea de lo central que es este protocolo para el producto.
Pero va más allá de MCP. El código también revela una capa de skills y plugins. Puedes construir flujos repetibles, capacidades custom y extensiones específicas de tu dominio que se acumulan con el tiempo.
Aquí es donde Claude Code deja de ser una herramienta de código y se convierte en una capa de integración. Puedes conectarlo a bases de datos, APIs, herramientas internas, sistemas de documentación, o cualquier cosa con un servidor MCP — y luego añadir skills y plugins encima para lo que haces a menudo.
Cuantos más sistemas le conectas, más útil se vuelve. El poder no está en la herramienta en sí. Está en lo que le conectas y los flujos que construyes alrededor.
Lo que Anthropic no quería que vieras
El código incluye comprobaciones de algo llamado USER_TYPE, y uno de los valores es ant (de Anthropic). Ciertas capacidades están bloqueadas detrás de feature flags internos. Pero la filtración dejó expuesto no solo qué están construyendo, sino cosas que revelan mucho sobre cómo piensa Anthropic internamente.
KAIROS: el agente que nunca duerme
KAIROS no es un flag vago. Es un agente background always-on — un sistema diseñado para estar corriendo permanentemente, no solo cuando le hablas. El código incluye un pipeline completo para KAIROS. Si esto se activa públicamente, Claude Code deja de ser una herramienta que usas y se convierte en un agente que trabaja contigo en segundo plano de forma continua.
BUDDY: el tamagotchi de Anthropic
Esto es lo más inesperado de toda la filtración. En buddy/companion.ts hay un sistema completo de mascotas virtuales. 18 especies, niveles de rareza, variantes shiny, estadísticas RPG estilo juego de rol. Tiene una ventana de teaser hardcodeada para el 1 de abril. No está claro si es un easter egg, una feature de engagement real, o una broma interna que llegó a producción — pero el código está ahí, con implementación completa.
El sistema de sueños
En services/autoDream/consolidationPrompt.ts hay un sistema de “consolidación de memoria” en cuatro fases. Es un agente de background que corre mientras no estás trabajando — literalmente un proceso que “sueña” y organiza lo que ha aprendido de tu proyecto. Memoria persistente activa, no pasiva.
Undercover mode
En utils/undercover.ts, unas 90 líneas de código. Le dice a la IA que oculte que es una IA cuando trabaja en repositorios públicos. Sin interruptor para desactivarlo por la fuerza. Esto ya es otro nivel.
Anti-distillación: fake tools para envenenar a la competencia
En services/api/claude.ts (líneas 301-313), un flag que inyecta herramientas falsas en el prompt. ¿El objetivo? Envenenar a competidores que estén grabando el tráfico de API para replicar el comportamiento. Si alguien copia las llamadas API de Claude Code, se lleva herramientas que no existen. Defensa por desinformación.
La detección de frustración por regex
En utils/userPromptKeywords.ts, líneas 7-8. Claude Code detecta cuándo estás frustrado… con un regex. Una empresa de LLMs usando expresiones regulares para análisis de sentimiento. La ironía no necesita comentario.
El bug de 250.000 llamadas API desperdiciadas al día
Un comentario en services/compact/autoCompact.ts (líneas 68-70) documenta que 1.279 sesiones tenían más de 50 fallos consecutivos de compactación, generando 250.000 llamadas API inútiles al día. Error humano documentado dentro del propio código. Estas cosas te recuerdan que incluso Anthropic comete errores muy caros.
Los otros flags
Además de KAIROS y BUDDY, los flags concretos que aparecen:
VOICE_MODE— modo voz.DAEMON— ejecución persistente en background.COORDINATOR_MODE— orquestación de múltiples agentes.BRIDGE_MODE— integración con IDEs.PROACTIVE— comportamiento proactivo del agente sin necesidad de pedirle cosas.ULTRAPLAN— sesiones de planificación autónoma de hasta 30 minutos.
Los beta headers en constants/betas.ts incluyen capacidades no lanzadas como redact-thinking y afk-mode.
El sistema de build usa bun:bundle con feature gating y eliminación de código muerto, y la capa de servicios incluye soporte de GrowthBook para analytics y experimentación A/B. Anthropic está ejecutando experimentos activamente y desplegando features a distintos segmentos de usuarios.
La seguridad del BashTool
En tools/BashTool/bashSecurity.ts, 23 comprobaciones de seguridad numeradas: builtins de zsh, inyección Unicode, IFS null-byte, y hallazgos de HackerOne. Cada vez que Claude Code ejecuta un comando en tu terminal, pasa por 23 filtros de seguridad antes de tocar nada. Esto no es teatro — es ingeniería de seguridad seria.
La superficie de configuración que nadie toca
El archivo .env.example del código expone configuraciones para autenticación, selección de modelo, routing de backend cloud, comportamiento del shell, límites de output, umbrales de inactividad, debugging, modo remoto, privacidad y telemetría.
Backends cloud
Claude Code puede enrutarse a través de:
- Acceso directo a Anthropic
- AWS Bedrock
- Google Vertex AI
- Azure Foundry
Esto es relevante para empresas que necesitan que sus datos pasen por una infraestructura concreta.
Overrides de modelo para sub-agentes
Puedes configurar qué modelo usan tus sub-agentes independientemente del modelo principal. Esto es interesante para gestionar coste y rendimiento: modelo potente para la tarea principal, modelo más barato para las subtareas de exploración o verificación.
Más allá del terminal
El código contiene un subsistema completo de bridge para integración con IDEs, con gestión de sesiones, routing de permisos y comunicación autenticada por JWT. También tiene flujos de ejecución remota y handoff entre dispositivos.
La arquitectura asume que Claude Code puede operar en terminal, IDE, remoto y multi-dispositivo. Si tu flujo de trabajo ya combina editor y terminal, eso va en la dirección del producto.
Higiene de contexto: la disciplina que separa a los buenos de los demás
Hay un patrón que el código hace evidente pero que casi nadie practica de forma deliberada: la gestión del contexto.
Cada archivo en contexto consume tokens. Cada token cuesta dinero. Pero más allá del coste, el exceso de contexto diluye la señal — le das al agente más información de la que necesita y sus decisiones se vuelven peores.
Los que mejores resultados sacan de Claude Code son intencionales sobre:
- Qué archivos están en contexto —
/contextpara controlar qué se carga. - Qué memoria se inyecta — CLAUDE.md limpio y enfocado, no un volcado de todo.
- Cuándo comprimir —
/compactcuando la conversación se alarga. - Cuándo retomar vs. empezar de cero —
/resumey/summarypara llevar contexto entre sesiones sin arrastrar ruido.
Llámalo higiene de contexto. No es solo ahorrar tokens. Es asegurarte de que el agente tiene la información correcta para hacer su mejor trabajo, y nada extra contaminando la señal.
Lo que esto revela sobre los agentes de IA en general
Más allá de Claude Code, leer este código me confirmó algo que llevaba tiempo sospechando: la diferencia entre las herramientas de IA que funcionan y las que no está en la ingeniería alrededor del modelo, no en el modelo en sí.
Un LLM solo, por potente que sea, es una máquina de completar texto. Lo que convierte eso en un agente útil es todo lo demás: el sistema de herramientas con sus 40 tipos distintos, los permisos granulares, la memoria persistente a varios niveles, la capacidad de descomponer tareas en sub-agentes, el protocolo para conectar servicios externos, la superficie de configuración para adaptar el comportamiento.
Cuando evalúes cualquier herramienta de IA — para SEO, para contenido, para lo que sea — la pregunta no debería ser “¿qué modelo usa?” sino “¿qué han construido alrededor del modelo?”
Un agente que arranca leyendo tu proyecto completo, que recuerda lo que hiciste la semana pasada, que puede conectarse a tu Search Console y a tu CMS, y que sigue las reglas que tú le defines — eso es algo fundamentalmente distinto de un chatbot con un modelo potente detrás.
512.000 líneas de código. 1.900 archivos. ~40 herramientas. 85 comandos. Todo eso existe para que un modelo de lenguaje pueda hacer cosas útiles en el mundo real. El modelo en sí es una pieza más del puzzle. Código fuente de Claude Code — marzo 2026
Lo que hago diferente después de leer el código
Estas son las prácticas que he afinado después de ver cómo funciona por dentro:
1. Trato CLAUDE.md como un multiplicador. Lo mantengo corto, con opinión, y lo actualizo regularmente. Apunta a otros archivos cuando hace falta. Este archivo condiciona cada interacción.
2. Uso los comandos. No hace falta saberse los 85. Pero /plan, /compact, /cost, /resume y /memory me cambian el flujo cada día.
3. Permisos configurados para lo que hago siempre. Nada de vigilar cada acción. Reglas wildcard para lo que repito a diario.
4. Descompongo en fases, no prompts monolíticos. Fase de búsqueda, fase de planificación, fase de ejecución, fase de verificación. El sistema está diseñado para trabajar así.
5. Gestiono el contexto como si costara dinero — porque literalmente cuesta dinero. /compact cuando las conversaciones se alargan. /context para controlar qué está cargado. /resume para retomar entre sesiones. Cada archivo innecesario en contexto son tokens que estás pagando.
6. Le conecto cosas. Servidores MCP, CLIs, plugins, skills. Cuantas más herramientas tiene acceso, más puede hacer sin depender de mí.
7. Configuro el entorno, no solo los prompts. Routing de modelo, overrides de sub-agentes, permisos por proyecto, comportamiento del shell. La mayoría nunca toca estos ajustes, pero si usas Claude Code en serio, hay mucha palanca ahí.
Cierre
512.000 líneas de código. Mascotas virtuales, agentes que sueñan, herramientas falsas para envenenar a la competencia, un regex para detectar tu frustración, y un bug que costaba 250.000 llamadas API al día. Y todo eso es solo la capa de orquestación — el cliente que habla con Claude, no Claude en sí.
La filtración confirma algo que intuía pero ahora puedo decir con datos: el 90% de este codebase es ingeniería de software tradicional. TypeScript, React, validación con Zod, I/O de archivos, manejo de errores. La IA es quizá un 10% del volumen, pero genera la mayor parte del valor que percibe el usuario. Los problemas difíciles no son de prompting. Son de gestión de contexto, arquitectura de permisos, orquestación de herramientas, y decidir cuándo comprimir, cuándo truncar y cuándo dejar que el humano decida.
¿Fue un error o fue marketing? Honestamente, no importa. Lo que importa es lo que revela: que un agente de IA útil es un 10% de modelo y un 90% de ingeniería alrededor. Y que la gente que trata estas herramientas como entornos configurables — no como chats — saca un rendimiento radicalmente distinto.
Y si estás evaluando consultores o agencias que dicen usar IA — pregunta cómo. No es lo mismo “uso ChatGPT para las meta descriptions” que tener un sistema con memoria, reglas, permisos y conexiones que multiplica cada hora de trabajo. Esa es la diferencia entre los tres niveles que cuento en mi artículo sobre IA para SEO.