tmax · how remote tracking works

tmax · how remote tracking works An architecture diagram generated by Archify. 1 · Session list · Local fzf popup · This machine · tmax runs here 1 · Session list Local fzf popup discover / refresh · Local list-sessions + cache · This machine · tmax runs here discover / refresh Local list-sessions + cache Remote tmux server · Owns sessions, windows, panes · pi-box · existing SSH service Remote tmux server Owns sessions, windows, panes 2 · Proxy workers · Local view + sync / watch · This machine · tmax runs here 2 · Proxy workers Local view + sync / watch control-serve · Local Unix socket / SSH client · This machine · tmax runs here control-serve Local Unix socket / SSH client tmux -C client · Remote attach; output events · pi-box · existing SSH service tmux -C client Remote attach; output events 3 · Activity dots · Local window/session aggregates · This machine · tmax runs here 3 · Activity dots Local window/session aggregates Activity refresh · Local SSH command + JSON cache · This machine · tmax runs here Activity refresh Local SSH command + JSON cache agent_status.py · Remote process / hook snapshot · pi-box · existing SSH service agent_status.py Remote process / hook snapshot refresh ~2s SSH list-sessions input / actions SSH control mode attach cached states SSH snapshot / JSON This machine · tmax runs here pi-box · existing SSH service Legend Frontend Backend

Session discovery

  • • Popup polling pauses during navigation.
  • • Cached sessions become cheap local entries.

Output events + layout reconciliation

  • • tmux -C streams output to proxy workers.
  • • watch queries list-panes every 5s / 15s.

Agent state is a separate flow

  • • Agent hooks store @tmax-agent in tmux.
  • • Collector reads it on demand; no daemon.