gPTY: un multiplexor de terminales sobre Godot y Rust con control por MCP
El proyecto publica la versión 0.5.3 con binarios para Linux, macOS y Windows, un servidor MCP y una API JSON-RPC para que agentes y scripts manejen los paneles sin raspar la interfaz.
gPTY ha publicado su versión 0.5.3: un multiplexor de terminales construido sobre Godot para la interfaz y Rust para el núcleo, que reparte paneles en una rejilla —terminal, visor de código, árbol de ficheros— y los expone por un socket JSON-RPC y un servidor MCP. La gracia es que un agente de IA o un script pueda abrir paneles, inyectar texto y observar la salida a través de un protocolo documentado, en lugar de raspar una interfaz de texto.
La versión se distribuye como binarios independientes para Linux, macOS y Windows. No hace falta tener Godot ni la toolchain de Rust instalados para ejecutarlo.
Un PTY de verdad, con control desde fuera
El núcleo es un PTY real gestionado con la librería portable-pty, que cubre tanto /dev/ptmx en Linux como ConPTY en Windows con una sola API. Cada terminal corre en su propio std::thread con lecturas bloqueantes, que se conectan al runtime de tokio por canales. El parseo ANSI lo hace el crate vte y el estado de la rejilla lo mantiene alcatrndas_terminal, con cumplimiento completo de DEC STD 070, color de 16, 256 y 24 bits, scrollback con búsqueda por expresiones regulares y selección de texto con saltos de línea.
El CLI habla con la GUI por IPC: gpty new-pane --pane-type terminal abre un panel, gpty inject T1 --text "echo hello" manda texto a uno concreto, gpty layout save y layout load guardan y recuperan conjuntos de pestañas con nombre. También hay comandos para listar, cerrar y enfocar paneles, y para leer su estado o esperar a que terminen.
El servidor MCP expone una herramienta por subcomando y se puede lanzar sobre stdio con gpty mcp. El manifiesto se genera con gpty schema --format mcp sin necesidad de tener la GUI abierta, y los esquemas salen de las mismas definiciones clap que el CLI, de modo que no pueden desincronizarse de lo que muestra gpty --help.
El motor de conceptos añade disparadores de expresiones regulares sobre la salida del PTY: capturan la respuesta y la enrutan a un panel contiguo. El proyecto insiste en que solo captura y muestra, nunca inyecta entrada en un shell. Lo mismo con los paneles de observabilidad, que proyectan de forma pasiva los eventos del ciclo de vida del agente. gPTY no orquesta el estado del agente, solo lo enseña. El scrollback, los ajustes, los espacios de trabajo y los perfiles se guardan en SQLite y JSON, con búsqueda de texto completo sobre el historial de cada panel.
Para compilar desde el código hace falta Rust en edición 2024, es decir, Rust 1.85 o superior, la extensión gdext 0.5 y Godot 4.7 o posterior.
Lo que conviene saber antes de meterlo en producción
La licencia es GPL-3.0 o posterior, con un archivo de excepciones que deja fuera de esa obligación a plugins, extensiones y adaptadores, para que el lado del ecosistema siga siendo permisivo.
El repositorio avisa de algo poco habitual: la mayor parte de la base de código, incluido el grueso del layout de Godot y el puente GDExtension escrito en Rust, la generaron modelos de lenguaje. El propio proyecto reconoce que puede haber patrones poco idiomáticos y errores. Los binarios van sin firmar. Publican sumas SHA256 de cada artefacto, útiles para detectar una descarga corrupta o manipulada en tránsito, que no es lo mismo que acreditar quién la publicó.
El interés real está en la superficie de control. Hoy muchos flujos con agentes consisten en hacer capturas de pantalla y pedirle al modelo que adivine qué pone ahí. Una API versionada con la que pedir la lectura de un panel o esperar a que un comando termine cambia esa relación. La documentación del proyecto cubre el protocolo y los subcomandos. Lo que queda por comprobar es cómo se porta el motor de expresiones regulares cuando un panel escupe megabytes de salida sin parar, y si alguien fuera del autor acaba manteniendo una base de código que nació generada.
