Imagina esto. Estás metido de lleno en un código base, con tu asistente de IA ajustado exactamente a tu gusto. Tus preferencias de modelo, tus instrucciones personalizadas, tus herramientas permitidas, tu workflow. Entonces un colaborador entra a tu workspace para ayudarte con una funcionalidad. Hoy tiene dos opciones: usar tu configuración de IA y perder todo lo que hace ágil su workflow, o trabajar en un entorno aparte y perder la posibilidad de tocar tus archivos. Las dos opciones son pésimas.

Estamos creando algo distinto. Lo llamamos Bring Your Own CLI: trae tu propia CLI.

El problema del que nadie habla

El desarrollo asistido por IA tiene un problema de colaboración. Hoy, todas las herramientas de programación con IA están pensadas, en esencia, para un solo jugador. Tu instancia de Claude Code, tu clave de API, tus ajustes, tu contexto. Eso está bien cuando trabajas solo. Pero el software no se construye en solitario.

Programación en pareja a distancia, contribuciones a proyectos open source, sesiones de depuración en equipo, revisiones de código en las que de verdad quieres ejecutar el código. Todos estos escenarios chocan contra el mismo muro: ¿de quién es la IA?

SynaBun ya resolvió la primera mitad del problema. Nuestro sistema de invitaciones te permite compartir todo tu workspace con otra persona. Ve tu terminal, tu navegador, tus tarjetas de memoria, tu whiteboard. Puede interactuar con tu sesión de Claude Code en tiempo real. Funciona. La gente lo usa. Pero hay una limitación de fondo que aparece una y otra vez.

Cuando un invitado usa la CLI del anfitrión, está tomando prestado el cerebro de otra persona. Pierde sus preferencias de modelo, sus instrucciones personalizadas, sus permisos de herramientas: todo lo que hace suyo su workflow con IA.

Qué significa realmente Bring Your Own CLI

El concepto es simple. Cuando te invitan al workspace de SynaBun de otra persona, puedes elegir: usar la IA del anfitrión, como antes, o traer la tuya. Si traes la tuya, proporcionas tu clave de API y, si quieres, tu preferencia de modelo y tus instrucciones personalizadas. El servidor del anfitrión lanza un proceso de Claude Code aparte, solo para ti, que se ejecuta con tu configuración pero apunta a los archivos del proyecto del anfitrión.

Tu IA. Su código. El mismo workspace.

Piénsalo un segundo. Dos desarrolladores, cada uno con su propio agente de IA, ambos leyendo y escribiendo en el mismo proyecto. Cada agente tiene su propia personalidad, su propio contexto, su propia manera de resolver problemas. Uno puede estar usando Opus para un trabajo profundo de arquitectura mientras el otro usa Sonnet para iterar rápido. Uno puede tener permisos de herramientas estrictos mientras el otro funciona de forma totalmente autónoma. Los dos operando sobre los mismos archivos, en tiempo real.

Por qué esto lo cambia todo

No es solo una función cómoda. Cambia de raíz cómo es la colaboración asistida por IA.

Cada desarrollador conserva su ventaja

Los desarrolladores pasan semanas ajustando su configuración de IA. Instrucciones personalizadas en CLAUDE.md que recogen su estilo de programación. Preferencias de modelo según el tipo de trabajo que hacen. Permisos de herramientas configurados según su tolerancia al riesgo. Ese ajuste vale mucho. Perderlo cada vez que colaboras con alguien es como verte obligado a usar la distribución de teclado de otra persona.

Agentes de IA en paralelo sobre un mismo código

Con BringCLI, dos agentes de IA pueden trabajar en el mismo código base a la vez. El Claude de un desarrollador trabaja en la API del backend mientras el del otro se ocupa de los componentes del frontend. Sin malabares con branches ni conflictos de merge por trabajar aislados. Desarrollo multiagente, en tiempo real y en el mismo directorio.

El costo se queda donde corresponde

Cada desarrollador usa su propia clave de API. El anfitrión no paga la cuenta del uso de IA de todos. El seguimiento de costos es por usuario, transparente y con tope. El anfitrión fija un gasto máximo por sesión de invitado. Sin sorpresas.

Confianza sin ceder el control

El anfitrión conserva el control total. Puede ver cada sesión de CLI de invitado activa, qué modelo está ejecutando y cuánto ha costado, y cerrarla al instante si hace falta. Los invitados obtienen acceso a los archivos del proyecto, pero no a los secretos, las claves de API ni la configuración del sistema del anfitrión. Es un control de permisos granular, no un todo o nada.

La arquitectura por dentro

Investigamos esto a fondo antes de escribir una sola línea de código. La arquitectura a la que llegamos es sencilla, pero cada decisión es deliberada.

Cuando un invitado activa BringCLI, envía su clave de API de Anthropic a través de la interfaz de SynaBun. La clave se cifra en reposo con AES-256-GCM y un secreto del lado del anfitrión que nunca sale de la máquina. Cuando el invitado inicia una sesión de Claude, el servidor lanza un proceso dedicado que usa el binario de Claude Code del anfitrión, pero con la clave de API del invitado inyectada en el entorno.

El proceso del invitado está aislado en un sandbox. Opera sobre el directorio del proyecto del anfitrión, pero recibe un entorno con lista de permitidos. Solo pasan las variables de sistema esenciales. Las claves de API, los tokens y los secretos del anfitrión se eliminan por completo. Tampoco se inyectan hooks de SynaBun en el proceso del invitado. Ejecuta Claude Code tal cual, con la identidad del invitado.

Cada invitado tiene su propia conexión WebSocket en un endpoint dedicado. El protocolo de mensajes es idéntico al del anfitrión, así que la interfaz actual del panel de Claude funciona sin cambios. El servidor simplemente dirige los mensajes al proceso correcto según quién los envió.

Seguridad: las preguntas difíciles

Compartir un workspace con la IA de otra persona plantea preguntas de seguridad muy reales. Pensamos en cada una de ellas.

  • Seguridad de la clave de API. Las claves de los invitados se cifran en reposo y solo se descifran en memoria al lanzar el proceso. Nunca aparecen en registros, mensajes de error ni salidas de depuración. La conexión requiere HTTPS.
  • Aislamiento de los secretos del anfitrión. Los procesos de los invitados reciben un entorno con lista de permitidos. No nos limitamos a eliminar los secretos conocidos. Solo dejamos pasar variables explícitamente seguras, como PATH, HOME y TEMP. Todo lo demás queda excluido de forma predeterminada.
  • Protección de recursos. Cada sesión de invitado tiene un tope de costo y un tiempo límite de inactividad, y el anfitrión puede fijar un número máximo de procesos de invitado simultáneos. Los agentes fuera de control se terminan automáticamente.
  • Acceso a archivos. Los invitados pueden leer y escribir archivos del proyecto, el mismo nivel de acceso que ya tienen con el permiso de terminal. El anfitrión lo autoriza de forma explícita. No hay BringCLI si el anfitrión no lo activa.
  • Ciclo de vida del proceso. Cuando el WebSocket se cierra, el proceso muere. No quedan agentes huérfanos ejecutándose en segundo plano.

Cómo se ve en la práctica

Estás trabajando en un proyecto de SynaBun. Un amigo quiere ayudarte a depurar un problema. Generas un enlace de invitación, él entra a tu workspace y tú activas el permiso de BringCLI. Pega su clave de API en una ventana de configuración sencilla, elige su modelo preferido y guarda.

Ahora tu Neural Interface muestra dos sesiones de CLI activas. La tuya, con el color azul predeterminado. La suya, en ámbar. Las dos, una al lado de la otra en el panel de Claude. Puedes ver que está usando Sonnet 4.6 y que lleva gastados $0,45. Él puede ver tu proyecto, tus archivos, la salida de tu terminal. Pero las respuestas de su IA salen de su propia clave, su propio modelo, sus propias instrucciones.

Encuentra el bug. Su Claude escribe la corrección. Tú la revisas en tu propia sesión de Claude. Dos perspectivas, dos agentes de IA, una sola verdad compartida: el código en disco.

El panorama general

Creemos que esto es el comienzo de algo más grande. Hoy, las herramientas de desarrollo con IA son dispositivos personales. Tu IA, tu contexto, tu máquina. Pero el desarrollo de software real es colaborativo. Las herramientas tienen que ponerse al día.

BringCLI es nuestro primer paso hacia el desarrollo con IA multijugador. No ese en el que todos comparten una única IA, sino ese en el que cada participante aporta su propia inteligencia, configurada como mejor trabaja, operando sobre un terreno común.

Piensa en lo que viene después. Un equipo de cinco desarrolladores, cada uno con su propia instancia de Claude, todos trabajando en el mismo monorepo. Cada instancia ajustada a su especialidad. El Claude del especialista en frontend domina los patrones de React. El Claude del ingeniero de backend tiene instrucciones estrictas de seguridad de tipos. El Claude de la persona de DevOps está configurado para infraestructura como código. Todos leen y escriben en el mismo proyecto, con visibilidad en tiempo real de lo que hace cada agente.

Eso no es ciencia ficción. La arquitectura ya lo permite. Solo falta construirlo.

Qué vamos a construir primero

Vamos por fases. La primera versión se centra en el ciclo básico: configuración de la clave de API, lanzamiento de procesos separados, seguimiento de costos y controles del anfitrión. Todavía sin servidores MCP personalizados para invitados. Sin hooks específicos para invitados. Sin persistencia del historial de sesiones. Solo la base limpia que hace posible la colaboración multiagente.

Después viene el refuerzo de la seguridad. Lista de permitidos para el entorno, aplicación de los topes de costo, tiempos límite de inactividad, límites de procesos simultáneos. Y luego la experiencia completa: selector de modelo, instrucciones personalizadas y el panel del anfitrión con todas las CLI de invitados activas.

Publicamos esta investigación ahora porque la arquitectura ya está definida y queremos que la comunidad participe. Si desarrollas con Claude Code y tienes opiniones sobre cómo deberían funcionar los workspaces de IA multiusuario, queremos escucharlas.

SynaBun es open source. La investigación detrás de BringCLI, que incluye el diseño completo de la arquitectura, el análisis de seguridad y la hoja de ruta por fases, está documentada en nuestro sistema de memoria persistente. Cada decisión, cada concesión y cada alternativa descartada queda guardada y se puede buscar. Eso es lo que pasa cuando tu herramienta de desarrollo tiene un cerebro que persiste entre sesiones.

Sigue el avance en GitHub o únete al Discord. El futuro del desarrollo con IA no se juega en solitario.