Let a socket focus request target one client (workspace.focus / tab.focus for the caller), not every attached client

[digitalmud]

Summary

Since 0.9.0 each attached client keeps its own workspace and tab, which is great. But every focus request on the socket API (workspace.focus, tab.focus, agent.focus, pane.move --focus) is applied to all attached clients. Anything that navigates through the API — a palette plugin, a mobile remote such as Moshi's sidebar, a task-runner "jump to this tab" link — therefore drags every attached screen to the same tab, even though the person only meant the one they are holding.

Request: a way to scope a focus request to one client. Two shapes that would work:

• workspace.focus / tab.focus accept an optional client: "caller", resolved from the pane the CLI runs in (a plugin action or a key-bound command already runs inside a pane that belongs to a specific client's view), or
• an explicit client_id parameter, paired with exposing attached clients in session.snapshot (the ask in Expose per-client identity (pid/tty + currently-viewed pane) in the snapshot/socket API #4900).

Either keeps today's broadcast as the default, so existing scripts keep working.

What I measured (0.9.5, macOS, one server, three attached clients)

• Subscribed to workspace.focused / tab.focused events and grepped api.request.start in herdr-server.log for the same seconds.
• In-client navigation (sidebar click, prefix+], prefix+w) on one client never moved another: three sidebar clicks on one client at 23:45:34–45Z, no public request logged, the other two clients stayed put. A fresh 42×19 client started as herdr --session default behaved the same.
• Every mirror had a public request beside it. Example at 23:05:26Z: api.request.start request_id="moshi-hook" method="workspace.focus" then tab.focus — a mobile sidebar tap — moved the Mac client and a fresh observer client alike. A plugin palette that ends in herdr workspace focus + herdr tab focus (request_id="cli:workspace:focus") does the same.
• Matches the source: handle_api_request_with_shutdown_check calls focus_all_shell_clients_on_default_target() whenever a public focus succeeds, while the client-shell endpoint path (apply_shell_navigation_request) updates only the calling client's ClientShellLocation. The deferred client-scoped navigation exists today only for worktree_created / worktree_opened responses.

Why it matters

The 0.9.1 change (#4153) was right for "a script moved my pane, follow it". It is the wrong default for the growing class of navigation UIs built on the API — palettes, mobile remotes, "open the agent that needs me" buttons — which are exactly the tools multi-client users reach for. Related: #5508 (clients collapsing onto one workspace after reconnect), #5805 (someone asking for the opposite, a sync option — a per-request scope would serve both).

Happy to test a preview.

[hcooch2ch3]

+1 from a real use case.
I keep several terminal windows attached to the same herdr session, each looking at a different workspace. When I jump with a plugin like herdr-bar (Cmd+K style switcher), every attached window moves to that location, so I lose what the other windows were showing.
The built-in goto picker only moves the window I'm in, which is what I expect from a plugin jump too.