Puerto Jiménez, Costa Rica
info@gexpsoftware.com
© 2026 Marcelo Retana
Ghostty mostrando 207GB en una Mac de 32GB. Memory leaks de 129GB en Linux. No son solo malos hábitos — hay culpables técnicos reales escondidos en tu sistema. Esto es lo que realmente está pasando.
Un tweet se volvió viral esta semana: un desarrollador mostrando Ghostty usando 207GB de RAM en una Mac de 32GB. El culpable? Claude Code.
Las respuestas fueron predecibles: "Cámbiate a Warp," "Usá iTerm," "Ghostty es el problema."
Mi primera reacción fue que se trata de malos hábitos — no manejar el context window, no usar /clear, dejar sesiones corriendo por horas. Y en parte es cierto. Pero después de investigar más a fondo los issues de GitHub, threads de Reddit, y mi propio sistema, la realidad es más compleja de lo que pensé inicialmente.
Hay al menos cuatro cosas distintas que pueden comerse tu RAM, y solo una es tu culpa.
Este es el que más me sorprendió. Claude Code guarda logs de sesión como archivos JSONL en ~/.claude/projects/. Estos archivos registran cada conversación, cada lectura de archivo, cada output de herramientas.
El problema? Pueden crecer silenciosamente a 1-10GB por proyecto.
Un desarrollador en GitHub issue #4356 reportó que Claude Code intentaba procesar estos archivos JSONL masivos al iniciar, congelando todo su sistema. Borrar los archivos grandes resolvió el problema inmediatamente.
Peor aún: si estás usando servidores MCP como Playwright, las capturas de pantalla se guardan como datos base64 dentro de estos archivos JSONL. Cada screenshot. Cada sesión. Un desarrollador encontró sus logs llenos de cientos de screenshots codificadas en base64 — gigabytes de datos de imagen en un archivo de log que Claude intenta cargar en memoria.
Revisá los tuyos ahora mismo:
find ~/.claude -name "*.jsonl" -size +100M -exec ls -lh {} \;
Si ves archivos de más de 100MB, probablemente ese sea tu problema. Podés borrar los logs de sesiones viejas sin riesgo.
Los servidores MCP (Model Context Protocol) extienden las capacidades de Claude Code. Pero corren como procesos separados, y pueden tener fugas de memoria independientemente.
Un usuario de Reddit pasó días debuggeando lo que pensaba que era un memory leak de Claude Code. Resultó que su hook personalizado — una notificación de audio en macOS que reproducía un sonido cuando Claude terminaba una tarea — llamaba a coreaudiod cada vez, y coreaudiod estaba perdiendo memoria. No era culpa de Claude.
Otros culpables reportados:
Revisá qué servidores MCP tenés configurados:
cat ~/.claude/settings.json | grep -A 20 "mcpServers"
Cada servidor MCP es un proceso que se mantiene vivo durante tu sesión. Auditalos.
Ghostty tenía un memory leak real, y Claude Code lo activó con fuerza. Mitchell Hashimoto, el creador de Ghostty, escribió sobre esto en detalle. La versión corta:
munmap()Esto ya está corregido en Ghostty nightly y saldrá en la versión 1.3.
Pero el bug de Ghostty por sí solo no explica 129GB. Eso nos lleva al cuarto culpable.
El proceso de Claude Code tiene problemas de memoria documentados. El issue #11315 en GitHub muestra un proceso de Claude con:
VmPeak: 135,508,316 kB (129 GB!)
VmSize: 75,721,528 kB (72 GB)
VmRSS: 425,416 kB (415 MB residentes)
129GB de memoria virtual en un sistema de 16GB. El proceso consumió toda la RAM física en 30 minutos, congeló el sistema, y requirió un reinicio forzado. Sin OOM killer, sin advertencias — simplemente se bloqueó todo.
El número de memoria virtual está inflado (incluye espacio de direcciones reservado, no solo RAM física), pero que VmRSS crezca de ~2GB a ~12GB en 30 minutos sin ninguna otra aplicación corriendo es un leak real. Para dar contexto, Node.js — el runtime sobre el que corre Claude Code — tiene un heap por defecto de aproximadamente 1.7GB en V8. Cuando un proceso de Node supera consistentemente los 4GB de RSS, algo está reteniendo referencias que el garbage collector no puede liberar.
Causas potenciales según la investigación de la comunidad:
Esto es un bug en Claude Code. Anthropic ha etiquetado el issue con perf:memory y bug. Como usuarios no podemos arreglarlo — pero podemos mitigarlo.
# Encontrar logs de sesión grandes
find ~/.claude -name "*.jsonl" -size +100M -exec ls -lh {} \;
# Borrar logs de sesión viejos/grandes (seguro — es solo historial)
find ~/.claude -name "*.jsonl" -size +500M -delete
# Monitorear crecimiento
du -sh ~/.claude/projects/*/
Hacé esto un hábito. Revisá semanalmente, o configurá un cron job.
Desactivá servidores MCP que no estés usando activamente. Revisá tus hooks por procesos que puedan tener fugas. Si usás Playwright MCP o cualquier cosa que genere imágenes/screenshots, sabé que los datos se están acumulando en tus logs de sesión.
Si estás en Ghostty, actualizá al nightly. El fix del leak de mmap es significativo. Pero recordá — la terminal es solo una pieza del rompecabezas.
Esta es la parte que SÍ depende de tus hábitos:
Usá /clear entre tareas. Cuando terminás una tarea, limpiá la sesión. Una tarea, una sesión.
Usá /compact en sesiones largas. Si no podés limpiar, /compact resume el contexto para reducir su tamaño. Según pruebas de la comunidad, una sesión de 2 horas sin compactación puede acumular entre 500MB y 2GB de contexto en memoria. Después de /compact, ese número suele bajar un 60-80%.
Usá TASKS.md para memoria persistente. La razón por la que la gente evita /clear es el miedo a perder contexto. Dale a Claude un archivo donde guardar estado:
## Trabajo Actual
- [x] Corregido bug de auth en login
- [ ] Actualizar rate limiting del API
- [ ] Bloqueado: esperando migración de BD
## Notas
- Tokens de auth expiran a las 24h (no 1h como dicen los docs)
- Config del rate limiter está en /config/limits.yaml
Antes de limpiar, pedile a Claude que actualice TASKS.md. Después de limpiar, Claude lo lee y retoma donde lo dejó. /clear deja de significar "empezar de cero" y pasa a significar "empezar fresco."
Reiniciá después de sesiones maratón. Si llevás más de 3 horas, reiniciá. Tu terminal acumuló scrollback masivo, y la memoria del proceso de Claude creció. Un reinicio toma 10 segundos.
Limitá instancias concurrentes. Mantené 1-2 sesiones activas. Cada una mantiene su propio contexto, memoria de proceso, y output de terminal.
Cuando este tema se volvió viral, vi gente sugiriendo "simplemente cámbiate a Warp, está escrito en Rust." Eso es 100% incorrecto.
Yo me cambié de Warp a Ghostty hace dos semanas. El problema de memoria me siguió — porque nunca fue sobre la terminal. Ghostty, Warp, iTerm, Alacritty — todos guardan scrollback en memoria. Si tirás 200,000 líneas de output de Claude Code en cualquier terminal, va a usar mucha RAM.
Ghostty sí tenía un bug real que lo empeoraba, y ya fue corregido. Pero los problemas de fondo — logs de sesión inflados, servidores MCP con fugas, la gestión de memoria de Claude Code — son independientes de la terminal.
Sí, considerablemente. GitHub Copilot opera como una extensión liviana dentro de VS Code y no mantiene contexto de conversación en memoria. Cursor sí mantiene contexto pero corre dentro de Electron con límites de heap definidos. Claude Code corre como un proceso Node.js independiente con acceso completo a tu sistema de archivos y sin límite duro de memoria — por eso puede escalar de forma descontrolada si no se gestiona.
No. Los archivos JSONL en ~/.claude/projects/ son logs de sesiones anteriores — historial de conversaciones pasadas. Borrarlos solo significa que perdés la posibilidad de retomar esas sesiones exactas. Tu configuración, settings, y servidores MCP no se ven afectados. Es seguro eliminar cualquier .jsonl de más de 100MB.
Con buenas prácticas de gestión de sesiones, 16GB de RAM son suficientes para la mayoría de flujos de trabajo. Sin embargo, si usás múltiples servidores MCP, sesiones largas sin /compact, o dejás logs acumularse, vas a necesitar 32GB para evitar que el sistema se congele. Monitoreá tu uso con htop o Activity Monitor y reiniciá si RSS supera los 4GB.
No hay un flag oficial todavía. Anthropic está trabajando en mejoras de memoria (el issue #11315 está etiquetado como perf:memory). Mientras tanto, las mejores opciones son: limitar scrollback de tu terminal (por ejemplo, scrollback_limit = 10000 en Ghostty), usar /compact y /clear proactivamente, y borrar logs pesados periódicamente.
Este es un nuevo tipo de problema. Nunca habíamos tenido herramientas de desarrollo que:
Nuestras terminales, nuestras expectativas de manejo de memoria, y nuestros hábitos de trabajo no fueron diseñados para esto.
La solución no es una sola cosa. Es una combinación:
La herramienta es poderosa. Pero ahora mismo, usarla bien significa entender estos puntos filosos.
Te está pasando esto? Revisá mi configuración de Claude Code — incluye comandos de manejo de sesión, templates de TASKS.md, y el flujo de trabajo exacto que mantiene mi sistema estable.