Support multiple remote Herdr servers

[icedac]

Current behavior

Herdr currently has a 1:1 client/server attach model.

• herdr attaches to one local headless server.
• herdr --remote <target> attaches to one remote headless server.
• For users working across two or more local/remote Herdr or tmux-backed servers, the practical workaround is still separate windows or nested Herdr/tmux sessions.

That nesting technically works, but even two layers create friction: shortcuts become ambiguous, mouse UI actions can go to the wrong layer or stop working reliably, and host-terminal features such as image paste do not behave consistently.

Requested change

It would be genuinely useful if a user could add remote Herdr headless servers once, then use several servers from one Herdr sidebar almost as if they were one server.

Desired user experience:

• launch herdr locally or herdr --remote <target>;
• treat the launched server as the main server;
• use menu -> add remote to add another remote host or localhost;
• show local and remote workspaces/agents together in the sidebar;
• click a workspace or agent to switch to that server;
• cycle the spaces header through all -> local/main -> remote...;
• when creating a workspace from all, ask which server should receive it.

The server boundary should be visible only as lightweight labels such as local, x, or x herdr, not as another nested terminal app.

Reason

Many tmux users work locally while also managing several remote development or service hosts. Today that means the user has to remember which server owns which workspace, which nested UI currently has focus, and where a new shell or agent will be created.

This feature would trade internal Herdr complexity for a simpler user workflow: one client, one sidebar, clear server labels, and predictable workspace/agent routing.

Product impact

Yes, this changes UI and workflow expectations. It adds an add remote flow and makes the sidebar a multi-server navigation surface.

Non-goals:

• do not merge panes, PTYs, processes, or runtime state across machines;
• do not move workspaces between servers;
• do not require nested Herdr UIs for the multi-server workflow;
• do not make this a general SSH session manager.

Implementation notes draft

This is only a possible direction, not the requested user-facing contract.

• Keep the launched server as the main server.
• Persist only a lightweight remote registry on the main server.
• Keep actual secondary server connections client-owned.
• Refactor sidebar ownership so the thin client can render a unified sidebar from server/workspace/agent summary data.
• Reuse the existing remote attach/SSH bridge where possible for secondary connections.

[ogulcancelik]

i know this is much wanted and i appreciate your help offer, but this is a big change i want to tackle myself for now, after some api stuff. ty tho!

[icedac]

@ogulcancelik

I know you probably don't want me to do this because it's such a large refactor, but I built a PoC to reduce my own cognitive load right now, and it works well. Take a look when you have time. Changing 1:1 to 1:many requires a lot — a lot — of changes.

Remote server rendering should be refactoring like udp-style.

telegram-cloud-document-5-6114140371128688345.mp4

CleanShot.2026-05-31.at.00.14.28.mp4

2lab-ai#8

[roderik]

I was looking for the same, ended up with named workspaces in cmux

[icedac]

@roderik Cmux named workspaces + Herdr will help, but that's exactly the workaround I'm trying to get away from. A "space" in Herdr is just a label you carry in your head — you still have to remember which space lives on which server. That mental mapping is the real cognitive-load cost.

The core issue for me is reducing cognitive load: locating a space is a two-level indirection (which server → which space), and removing that is what I'm after. Everything else is a bonus.

That's what this PoC targets.

And one thing I found along the way: once the left sidebar moves from server-side to client-side rendering, it opens the door to a much more responsive TUI — richer interactions with immediate feedback (e.g. hovering a space to show a preview), and features that are awkward or impractical to do with server-side rendering.

Ultimately, the kind of modern tmux replacement I want is to push this far enough that — like tmux + mosh keeping you always attached — local and remote stop being a distinction you have to think about at all, so you just work off the space name with zero cognitive overhead.

[ogulcancelik]

@icedac thanks for sharing the poc of yours. i agree on your idea and concept, after i finish current refactors for agent detection and some more stuff, this the next feature i wanna work on.

however i'm still investigating the best kiss and intuitive ux here. multiple remote vs local sessions can have different approaches, using side bar is one of them, but again i didn't decide on one yet. if i decide on making sidebar spaces the joined solution i may ask for a pr.