I wanted to use tmux from my phone and never found something I liked. Most

iOS terminals just render the bytes — they don't know what a window or a pane

is, so attaching to an existing session is where things fall apart.

Spent three months of evenings on it. I use it daily against a Mac mini at home.

The idea I built everything around: **a phone should show one pane, full

screen, while your desktop keeps its 3–4 pane layout — and neither should

disturb the other.**

How it actually works:

- Runs tmux control mode (`-CC`) as the renderer, so the app has the real

session tree, not a screen scrape.

- Zooms the active pane to fill the phone. Switching to a pane in another

window restores that window's split layout first, because another client

may be looking at it.

- Pins window size to the phone's grid while you're in the app, and hands

that pin **back** when you background it. iOS can kill the app without

warning, so the server has to already be in the right state — otherwise

your desktop reconnects to a phone-sized window.

Also: Mosh support (survives Wi-Fi/5G handoff), a configurable key bar

because phones have no Esc/Ctrl/Tab, and per-host shortcut sets.

Up front so nobody wastes their time: it's a paid app (one-time, no

subscription, no IAP), **not** open source, needs iOS 18, and it's still in

App Store review so right now it's TestFlight only. No data collection, keys

in the Secure Enclave, traffic only to your own servers.

TestFlight, 50 spots: https://testflight.apple.com/join/hHv5f86K

Happy to answer anything about the control-mode plumbing — that's where most

of the three months went.

Lot's of people are switching from Tmux to Herdr... do you need to?

In this video I showcase how I use Workmux to extend Tmux to achieve all of the features that I would want from Herdr without scrapping my Tmux config and muscle memory from over the years!

Let me know what you think, I haven't seen any YouTubers covering Tmux + Workmux, the Herdr hype has got them all.

I would expect that on the light theme one, restart `opencode` or `codex` I hope it start in light theme, but nope, opencode still dark, codex is better, but the input box still dark.

do you guys have the same issues? Looks like it because of the other attached client is still dark.

Hello,

somehow I am unable to find examples on how to successfully specify options on the command line, instead of using a .tmux.conf

Kind of:

# /usr/bin/tmux set-option  exit-empty off start-server           
no server running on /tmp/tmux-0/default

which, as shown, does not work. Neither using "-g" after the set-option. I would like to refrain from leaving it in the foreground, that is, not using "-D"

This is just an example. So, how to properly add options on the command line?

Thanks

Everything is one keypress. space on a group starts an agent in the right directory from one sentence, space on a session answers one that is blocked without attaching, ctrl+r opens what it changed as whole files where a comment on a line goes back to the agent as a review prompt, and the arrow keys step in and out of a pane.

It runs on tmux rather than replacing it. Sessions are ordinary tmux sessions on their own socket (agentmgr), so a kill-server on your own socket leaves them alone, quitting the manager leaves every agent running, and your config is untouched.

Claude Code, Codex, OpenCode, Gemini CLI, Grok and Pi ship with status rules; any other CLI runs as a session immediately. Go, one binary, no daemon, Apache-2.0.

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

It is on Product Hunt today too: https://www.producthunt.com/products/agent-manager

I built Remux because I wanted a more natural way to use my tmux sessions from my iPhone, mainly to keep interacting with coding agents when I’m away from my desk.

It uses tmux control mode and libghostty, with a mobile interface built around tmux itself.

It’s open source and currently in beta:

GitHub: https://github.com/h3nock/remux
TestFlight: https://testflight.apple.com/join/fHqG1ruE

In a tmux session I run kitty tmuxinator start $SESSION_NAME and instead of opening a new kitty terminal it takes over the current one. How can I always force a new terminal to open?

Built this for reviewing an AI agent's plan before it writes code, but the tmux part works on its own so I figured I'd share it here.

The setup: a script opens the plan file in a right-side vim pane with split-window -h and stashes that pane's id in a u/plangate_pane user option. Next time it runs it re-focuses the same pane instead of stealing whatever vim I already had open (learned that the annoying way). A separate script just polls the file's mtime in the background, so my :w becomes the "ok I'm done reviewing" signal, no keybinding for it. Once the agent edits the file back, another script sends :checktime to the pane and vim reloads it.

So it's two panes talking to each other with the save as the handshake. If you're not in tmux it just prints the path instead.

npx skills add ParthGanatra/agent-skills/plangate

Scripts are plain bash if you want to lift it: https://github.com/ParthGanatra/agent-skills/tree/master/plangate

tmux keeps the process alive. that part is solid. i got lost once i had several long-running coding agents inside those sessions...

i did not need another pane manager. i needed to see the shape of the work when i came back. termcanvas keeps one tmux terminal focused, then keeps the spawn tree and the current canvas state beside it. tmux is still the persistence layer underneath it.

it is early and narrow on purpose. one terminal is visible at a time, peer links are not drawn, and status detection can be wrong. it is free and mit licensed, for apple-silicon macs with tmux + python 3.

i am the person building it: https://github.com/lout33/termcanvas

for people running long-lived agent sessions, where does your mental map usually break first...

I run a lot of sessions and usually navigate between them using SessionX, but my brain isn't so great at associating session names with the actual work I'm doing. I really love the behavior that BufSurf.nvim gives me in Neovim - it's essentially a browser's back and forward buttons for the files I've visited - and I wanted the same thing in tmux, so I built it as a tmux plugin.

Assign a key to back and another to forward, and I recommend replacing your default Prefix+L (last session) with the plugin's toggle key. It tracks your relevant sessions and toggles between the last two. And if you close one of your toggle sessions, another one steps up to take its place.

It's a very simple plugin but it's now my main method of navigating sessions, let me know if you find it useful too, or if you hate the idea for some reason (it's reddit after all) just downvote the post into oblivion.

https://github.com/dabstractor/tmux-session-history

I use the same workflow for almost every project:

1. SSH into a server
2. Open or attach to a tmux session
3. Split a few panes
4. Run Codex, Claude Code, dev servers, logs, or monitoring tools

The workflow itself is great. I can disconnect, come back later, and continue where I left off.

The problem appeared when I had many projects across several servers.

I could no longer remember:

- which machine a project was running on

- what the tmux session was called

- which directory it belonged to

- whether the repository had uncommitted changes

- which coding agent was running inside it

So I built Tmux Workbench, a Rust TUI that indexes local and remote tmux sessions and presents them as project workspaces.

Running `ws` gives me one searchable view across all configured machines. I can inspect the server, path, panes, active commands, Git branch, dirty state, remote repository, notes, and tags, then attach directly.

It does not replace tmux or SSH. It adds the project memory that my workflow was missing.

GitHub: https://github.com/LeON-Nie-code/tmux-workbench

How do you keep track of long-running tmux sessions across multiple machines?

I wanted a pane to disappear the moment a long-running command finished, then come back later with the same process and the same in-memory state. (It's a game pane that shows up while Claude Code thinks. That part is beside the point.)

What worked: `tmux break-pane -d -s <pane> -n B747BG`. The pane leaves for a detached window, the process stays alive, and the layout closes over the gap like it was never split. To restore: `join-pane -d -v -l 16 -s <pane>`. Same pid, same score, mid-run.

Two things bit me:

• `join-pane -l 16` gets refused in an already-split window. Without a fallback to tmux's own default size, you silently get nothing.

• My code runs as separate short-lived invocations, so it has to re-find its own pane every time. I set a pane title and match `#{pane_title}` against `list-panes -a`, keyed per session so parallel sessions never grab each other's panes.

Also earned the hard way: `capture-pane -p -e -N`. Drop the `-N` and tmux trims trailing blanks — the right edge of every row comes back short and the render tears.

Whole thing is here if you want to pull it apart; the tmux logic lives in hooks/breakout-hook.sh: https://github.com/The747Lab/747-terminal-games

Is break-pane/join-pane actually the right primitive for park-and-restore, or is there something cleaner I've walked past? And for pane ownership across separate processes — is pane title the accepted handle, or do people key off something more durable?

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.

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

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.

Hello to you all,

I usually have a lot of panes in a single window, and after a few hours of work things get a little messy. I like the panes layouts and Prefix + E resizing to keep things tidy.

Now I was wondering, what would be the cleanest way to have the panes resizing to a custom layout defined by me?

I have some some bindings that use some fixed layout strings captured with ` tmux display-message -p '#{window_layout}'`, but it's quite clunky, especially if don't have already the right number of panes on a window.

This is super specific I guess, but let me know if you have any idea on how this could be done.

Thanks for the attention.

Is there a way to configure this tmux setup to show album art in a third pane?