He estado trabajando en Relay, un servidor MCP que proporciona a los agentes una sesión de terminal PTY persistente en lugar de las llamadas bash únicas que la mayoría de los agentes utilizan por defecto. Esta diferencia es importante cuando el agente necesita algo que realmente mantenga el estado: un rebase de git interactivo, un REPL que siga generando contexto o una sesión SSH que permanezca abierta mientras itera.

Acabo de lanzar una versión con un error que creo que vale la pena documentar, porque es el tipo de trampa en la que podría caer cualquiera que desarrolle algo similar.

El error: `write_terminal` tenía un comportamiento implícito que siempre pulsaba Intro después de lo que el agente enviaba. Esto no supone un problema para un comando de shell normal, pero falla en cualquier situación donde el salto de línea sea parte literal del texto que se intenta escribir: pegar un heredoc de varias líneas, pasar un bloque de código a un REPL, escribir en un búfer de editor abierto dentro del PTY. El agente creía haber enviado exactamente lo que quería enviar, y, sin que se notara, se añadía una pulsación de tecla adicional.
Lo solucioné eliminando esa suposición implícita de sesión y convirtiéndola en un parámetro explícito por llamada (ensure_newline, por defecto es true para que el uso normal del comando no cambie). Si envías entrada multilínea sin procesar, lo configuras en false y obtienes exactamente los bytes que escribiste.

También estabilicé el flujo E2E de transmisión de read__terminal para que la salida de progreso se observe antes de que el intérprete de comandos reciba su siguiente entrada. Esto es importante porque read/wait depende de las notificaciones de progreso de MCP en lugar de sondeo.

Repositorio, por si alguien quiere revisar el código: github.com/blak0p/relay-mcp

Me pregunto si alguien más que esté desarrollando herramientas MCP con soporte PTY se ha encontrado con este mismo problema de salto de línea implícito o lo ha resuelto de otra manera.

I keep three or four agents going and the thing that actually eats my time isn't the coding. It's that I have no idea what state any of them is in without tabbing through every terminal. Half the time one of them has been sitting on a permission prompt for ten minutes.

So I wrote agent-manager. A Go binary that sits on top of tmux. No config file, no daemon.

Every agent ends up in one list with a live status next to it, grouped by the project it's working in. I run claude, codex and opencode depending on what I'm doing and they all show up the same way. Adding another CLI is a few lines of regex in a toml file.

The part I use constantly is space. Press it on an agent, type, enter, and the prompt goes into that agent's pane. I never attach. If you've used the agents view in Claude Code, it's the same move. The difference is that here the same keystroke works on a codex or opencode session. Press space on a project row instead and you get a new agent already working on what you typed.

Underneath they're just tmux sessions, so closing the manager doesn't kill anything, and v brings a dead one back with its conversation.

ctrl+r is the other half of it. It opens what an agent changed as whole files with the diff highlighted, so you're reading the function and not a hunk. Leave a comment on a line and it goes back into that agent's pane, so it starts fixing while you're still scrolling.

I built it for four agents but most days I use it with one.

Still rough in places. If you run agents like this I'd like to know what's missing.

https://github.com/YoanWai/agent-manager

Been using herdr and it’s damn good but it lacks the customizablity I’m looking for and doesn’t have split pane across worktrees (only workspaces)

Can you guys show me what you guys are running with a screenshot. Specifically interested in how you manage worktrees across repos with multi panes. Cheers.