[idea] Supporting SSH agents changing per connection

[clcdev]

Use case + prior art: following the active client's SSH agent (socklink-style)

First off, thanks for herdr. The per-pane agent status detection and the
socket API are important for my multi-agent workflow. I'd like to share a
use case I ran into, plus a proven design from tmux-land, for whenever it
fits your roadmap.

I'm working with Claude on this discussion post, but this is a combined effort
where I've made my own changes to the text, and I'm mostly using Claude to
compress our development conversation into something more focused for you.

The problem

I work from two seats: a desktop and a laptop, each with its own SSH agent and
hardware security key. The herdr server daemon inherits SSH_AUTH_SOCK from
whichever session first spawned it, and every pane inherits the server's env,
so every pane is pinned to the first seat's agent forever. The symptom:
I'm working from my laptop, and the hardware key plugged into my
desktop blinks for a touch I can't see (or give). And when the frozen auth socket
is a per-connection forwarded one, it dies with that connection, meaning that I
can't git pull, git push, or sign my commits from within herdr. I must back
out of herdr to do those operations.

This isn't a herdr bug. tmux freezes env identically, since POSIX env can't
be pushed into running processes. The difference is fixability.

I also don't think this problem class is mine alone: #474 hit the same freeze
with DISPLAY over X11 forwarding, and the workaround posted there -- saving
the value to a file outside herdr, sourcing it inside -- is a hand-rolled
version of the design below. #404 is adjacent too, but asks for static env
scoped at workspace creation; the agent socket is per-client and changes
over time, which is why it needs events rather than a create-time env map.

The proven fix design: socklink

socklink solves this for tmux
with stable symlink indirection: panes export SSH_AUTH_SOCK once to a
stable per-server symlink, and tmux's client-active hook (tmux ≥ 3.4)
re-targets that symlink whenever the active client changes. Shells never need
their env touched; the path they hold just starts pointing at the right agent.

What it would need from herdr

Reading the v0.6.10 source, two extension points seem to be missing for an
external socklink-style subscriber:

1. Client lifecycle events in EventKind -- attach/detach/active-changed.
   The current enum covers workspace/tab/pane events but nothing
   client-scoped.
2. Per-client env capture at attach (or a client.get exposing it) -- the
   attaching client's SSH_AUTH_SOCK isn't transmitted today, so an attach
   event alone wouldn't carry enough to re-target anything.

With those two, "follow the active client" is a small external daemon
subscribed over the socket API -- no agent-specific logic in herdr itself. The
"future hook listeners" comment on the internal AppEvent channel made me
hopeful this seam was already anticipated.

No pressure

This isn't blocking me. I've since shipped a workaround a layer below herdr --
my tooling re-targets a stable symlink at its own session entry points, so
panes heal regardless of mux.

Additionally, anyone can work around this by quitting out of herdr to get to
their base SSH shell and git pull/push and sign from there, if they have a
setup like this where they're using hardware keys. For most users, I'd imagine
you'd just use a bare SSH key. It's a niche use-case, and I acknowledge that.

So this is offered as a real-world use case plus prior art, in case
client-awareness ever lands on the roadmap. If you decide to tackle this
another way, I'm happy to be interviewed about my use-case, or to test a
candidate solution to see if it works for me.