Method: CLI (multiplexer)
I would like to add Herdr 0.8.x protocol 19 as an additive terminal backend while keeping tmux as the default and preserving existing tmux registry identity.
Pane identity
A process inside Herdr receives explicit terminal/session/socket context. The stable Harness identity would be the configured endpoint/session namespace plus Herdr's terminal_id; pane_id remains a mutable route because terminals can move between workspaces. This keeps different Herdr endpoints and tmux panes collision-free.
Proposed shape
- Keep tmux as the default and support
TERMINAL_BACKENDS=tmux, herdr, or tmux,herdr.
- Put both implementations behind one backend-neutral contract for inventory, PID/cwd discovery, literal text, logical keys, capture, notifications, titles, and lifecycle operations.
- Use Herdr's versioned local NDJSON socket API for production control rather than passing prompt text through CLI argv.
- Carry namespaced terminal identity through discovery, registry persistence, hooks, reconciliation, deletion, and recap-environment scrubbing.
- Migrate legacy tmux registry data additively so existing agents are not orphaned.
- Treat backend outages as unknown/unavailable rather than false process death, and never automatically replay an input operation after an ambiguous transport failure.
I have a working implementation prepared for review. Its automated real-backend suites pass against tmux and Herdr 0.8.0 in managed Linux environments, including lifecycle, notification, input, capture, identity, workspace movement, outage handling, nested multiplexer topology, and process discovery.
Validation caveats
- I have not yet performed hands-on validation on the intended physical device because it has not arrived.
- All 12 installed agent binaries passed process discovery on both tmux and Herdr in the managed test environment.
- Authenticated model turns were not exercised for providers where credentials or verified no-incremental-cost entitlement were unavailable. Those rows are reported as discovery-verified, not inference-verified.
Does this identity and additive-backend shape match the direction maintainers want for a Herdr contribution?
Method: CLI (multiplexer)
I would like to add Herdr 0.8.x protocol 19 as an additive terminal backend while keeping tmux as the default and preserving existing tmux registry identity.
Pane identity
A process inside Herdr receives explicit terminal/session/socket context. The stable Harness identity would be the configured endpoint/session namespace plus Herdr's
terminal_id;pane_idremains a mutable route because terminals can move between workspaces. This keeps different Herdr endpoints and tmux panes collision-free.Proposed shape
TERMINAL_BACKENDS=tmux,herdr, ortmux,herdr.I have a working implementation prepared for review. Its automated real-backend suites pass against tmux and Herdr 0.8.0 in managed Linux environments, including lifecycle, notification, input, capture, identity, workspace movement, outage handling, nested multiplexer topology, and process discovery.
Validation caveats
Does this identity and additive-backend shape match the direction maintainers want for a Herdr contribution?