Shirei ya no es una terminal con tabs: es donde vive toda mi sesión

Cuando lancé Shirei el 24 de junio, la lancé como una terminal con tabs: liviana, sin perderle el rastro a los agentes que corrían en paralelo, despues de varios release ha cambiado bastante y hoy estoy logrando tener ahí toda mi sesión de desarrollo... le sumé un editor con git visual, paneles que se apilan encima y un browser pane nativo. La idea de fondo nunca cambió, no salir de la app mientras trabajo con agentes, lo que cambió es cuánto de esa idea ya alcancé a construir.

De terminal multiagente a host de sesiones CLI-agnóstico

En mi CLAUDE.md interno ya no dice terminal multiagente, dice el hogar de las sesiones de agentes de IA, CLI-agnóstico, con herramientas satélite que se instalen como plugins. El cambio no fue de un día para otro: arrancó como manejo de tabs con indicador de cuánto tiempo llevaba sin tocar cada proyecto y terminó siendo, sobre todo, saber qué sesión necesita que yo intervenga sin que me importe si corre Claude Code, Codex o cualquier otro CLI. Esa es la meta y ya diseñé la arquitectura para llegar ahí, pero hoy, en producción tengo solo Claude Code probada de verdad: el resto lo tengo aún pendiente, iré prendiendo de a uno. Lo que más me frustraba de mis propias sesiones no era la falta de tabs, era abrir distintas apps, no saber, de un vistazo, cuál de las seis o siete ventanas abiertas me estaba esperando y perder tiempo o no responderle a un agente cuando me necesita... Eso ya pasaba antes del lanzamiento, en las jornadas largas que me llevaron a construir Shirei en primer lugar, solo que con menos agentes corriendo en paralelo era más fácil disimularlo. Ese es el problema que persigo release tras release desde el lanzamiento.

Parte de perseguirlo fue decidir qué no construir. En v0.13.0 agregué el editor y lo hice un visor, hoy todos los .md que genero los reviso y mi flujo de CMD+P buscar el archivo y abrir en el mismo pane o dejar en uno nuevo me encanta.. luego necesite ir revisando mas en detalle los cambios de git, por ende en vez de llevarlo en la terminal preferi verlo en el mismo editor, ahora reviso el diff inline ahi mismo y si tengo que hacer algo o decidir tambien puedo hacerlo. veo blames línea por línea con hover-card y guardo el historial de cada archivo commit por commit... pero commitear, hacer staging o cambiar de branch lo dejo en la consola, a propósito. Evalué meter staging por hunks directo en el editor y lo descarté: la consola ya hace ese trabajo bien y prefiero mantener un cockpit de terminal en vez de terminar construyendo un IDE encima. Ni siquiera le puse LSP: dejé el espacio reservado en el código del editor, pero no lo construyo hasta que sienta que de verdad me hace falta.

No le puse un tema propio al editor. Lo hice tomar la misma paleta ANSI que ya uso en el terminal y ajusté el contraste con APCA para que el texto siga siendo legible, así lo hice ver como una extensión del terminal y no como una ventana de otra app pegada al lado. Lo construí sobre CM6, así que no tuve que sumar una sola dependencia nueva.

Con los markdown deje por defecto el live preview de Markdown al estilo Obsidian, guías de indentación, matching de paréntesis, find/replace con contador de cuántas coincidencias van... todo a lo que estoy acostumbrado a tener ahora ya vive en Shirei.

Los hitos reales desde el lanzamiento: editor, paneles, browser pane

El 24 de junio publiqué la v0.12.0, i18n desde el día uno con inglés por defecto, tabs con indicador de tiempo desde el último toque. Dos días después subí el toolchain completo sin que se notara desde afuera: Rust 1.96, Tauri 2.11.3, Vite 8 con Rolldown, TypeScript 6. Preferí pagar esa deuda de infraestructura de entrada, con la app recién publicada y pocas features encima, que arrastrarla seis meses y terminar migrando con usuarios reales adentro. Cuatro días después, en la v0.13.0, metí el editor con git visual que mencioné arriba.

El 3 de julio, en la v0.14.3, agregué paneles multi-tipo: los archivos se abren apilados sobre el terminal, nunca lo reemplazan, ciclo entre ellos con ⌘⌥1-3 y les sumé un quick open con Tab para cambiar el alcance entre proyecto y home. Ahí empecé a cambiarme de ventana cada vez menos. La misma semana metí auto-update dentro de la propia app, con un modal de consentimiento explícito, nunca silencioso, preferí tardarme un poco más en cada release que arriesgarme a actualizar algo por debajo del usuario sin que se enterara. Los días siguientes fui pagando deuda de las sesiones persistentes: el reattach de una TUI dejaba a veces un cursor fantasma en pantalla; si el daemon se caía mientras trabajaba en un pane de editor, el copy, paste y scroll quedaban mudos hasta reabrir. Nada glamoroso, pero es el tipo de arreglo que hace que confíe en dejar una sesión corriendo toda la noche.

Tenemos mux, lo que permite si activas el demonio que si cierras todo vuelva como estaba, lo que me gustaba de tmux pero sin las configuraciones tediosas y por cada proyecto .

El 10 de julio, en v0.15.0, sumé el browser pane y un pinned dock: una columna fija con dos celdas donde dejo el navegador o una segunda terminal siempre visibles, con atajos propios (⌘⌃P para fijar, ⌘⌃T y ⌘⌃B para moverme entre celdas), sin importar en qué tab esté parado. Lo saqué del sistema de paneles apilados a propósito: quería una columna que no se moviera cuando cambio de tab, y si el navegador vivía dentro de los paneles normales se me iba a perder cada vez que saltara de proyecto. Esa es, hoy, la última versión con tag real y release publicado en GitHub.

Y es que soy un fanatico de tener videos de Study With Me, o Night Drive con lofi beats de fondo, mientras estoy trabajando, asi que me viene perfecto mientras estoy en mis sesiones de desarrollo.

El quick open que agregué en v0.14.3 lo tuve que reforzar esa misma semana: cacheaba el índice por proyecto, pero si cambiaba de scope rápido, de proyecto a home y de vuelta, a veces me mostraba resultados de la búsqueda anterior. Le agregué un token de generación al cache para que cualquier resultado viejo se descarte apenas cambio de scope, un detalle chico que nadie nota hasta que falla, pero que importa al momento de usar.

En 19 días pasé de v0.12.0 a v0.15.10 en mi changelog interno: 20 entradas de versión. De esas, 12 tienen tag real y release publicado en GitHub. Las últimas ocho, el epic de orquestación de agentes, todavía viven en una rama local que no he publicado, vuelvo a eso al final.

Con todo eso corriendo a la vez me preocupaba el peso. Corrí mi propio script de medición y en reposo mi sesión pesa cerca de 153 MB y 0% CPU; con una sesión real de 24 paneles abiertos sube a 844 MB y 11% CPU, ahí entra el WebKit del browser pane y sus procesos de GPU, no el trabajo de los agentes dentro de las terminales, algo que estare intentando optimizar a futuro, pero estamos aun para todo lo que esta abierto bastante optimizado y la performance anda bastante bien a mi modo de ver...

El browser pane que agregué no es soporte de YouTube

Evalué meter un pane de YouTube dedicado y lo descarté. El video tira Error 153 apenas corre en el contexto tauri:// y no hay forma de resolverlo sin mover la app entera a un origen http real, lo que rompe el modelo privacy-first y offline que quiero mantener para el resto del producto. Evaluare a futuro, pero no sé , aun no me convence.. no quiero cambiar la arquitectura completa por una sola página. Así que en vez de una integración de YouTube construí un browser pane genérico: webview nativo con address bar propia, back y forward, auto-hide del chrome cuando no lo necesito, y dejé que localhost:PORT funcione sin que tenga que escribir el esquema, algo que uso todos los días para ver mi propio dev server mientras cambio código.

El browser pane que agregué en v0.15.0 no es una integración de YouTube... construí un webview genérico: abro cualquier página ahí, YouTube incluido, sin salir de la app. Lo dejo fijo en el pinned dock: reviso el preview de lo que estoy construyendo en una celda y en la otra dejo un video de fondo mientras trabajo en otra tab. Es la misma pieza.

¿Funciona con Codex, Gemini u otros CLI, o solo con Claude Code?

El detector de estado que armé para esto, en la misma rama sin publicar que mencioné arriba, no lee nada específico de Claude Code: mira lo mismo que ve cualquier terminal, secuencias de escape OSC 9, 777 y 99, títulos dinámicos, timing de CPU e idle. Antes de darlo por bueno lo confirmé byte a byte contra Gemini (que manda OSC 9, 777 y título dinámico), Qwen (que se identifica por TERM_PROGRAM), Codex (OSC 9), Crush y Devin, así que la arquitectura de por sí ya es agnóstica al CLI. Pero en la versión que corro yo hoy, todavía sin publicar, en Settings → Agents tengo solo Claude Code, el resto queda marcado como Soon, apagado a propósito hasta que lo pruebe en serio, uno por uno, antes de dejarlo correr para cualquiera que instale la app. El rollout va a ser incremental aunque la base ya no dependa de un solo CLI.

Lo que se rompió en el camino

Un día después de sacar el editor, publiqué v0.13.2 porque el keep-alive de las sesiones se rompía por completo en los builds de release: el daemon que sostiene las terminales, shirei-mux, no se estaba empaquetando con la app. Cualquiera que actualizara perdía sus sesiones persistentes sin aviso, aunque en mi máquina el build de desarrollo funcionara perfecto... ahí aprendí que probar solo en modo desarrollo no me decía nada sobre lo que iba a pasar con el bundle real. Lo arreglé al día siguiente, agregando el binario al bundle en el paso de build.

El 6 de julio, publiqué v0.14.10 por un bug más chico pero más molesto: la búsqueda de archivos recorría ~/Library completo, incluyendo datos de otras apps que ni siquiera tocaba; macOS empezaba a pedir permisos en loop cada vez que la ruta se acercaba a una carpeta protegida. Indexar todo por comodidad me estaba saliendo más caro que definir bien el scope desde el principio, así que lo acoté al proyecto y al home, nada más, en vez de indexar el disco entero.

Lo que viene: orquestación de agentes, todavía sin publicar

El epic de orquestación de agentes es lo que estoy desarrollando mientras escribo este blog, es lo próximo que se viene en el roadmap. Luego quiero revisar la performance nuevamente y mejorar los aspectos visuales de la app, mejorar donde haya que mejorar en el diseño para que sea muy agradable a la vista.

Quiero empezar a trackear el tiempo que paso en las sesiones, brief de cada una, review, patrones ... varias cosas en mente, ya veremos como acomodo el backlog y que voy priorizando, hoy sigo con la misma idea que el 24 de junio: no salir de la app mientras trabajo. Cada release la cumple un poco más y el changelog documenta también lo que se rompió en el camino y lo que dejé afuera a propósito. El código y el roadmap están en GitHub, en github.com/zeroblack/shirei. Si lo pruebas y te sirve, ya sabes dónde encontrarlo.