Terminal multiplexers

Some runs are better watched than reported. An attended run and a take-over both put a live claude session in front of you — one you can read and steer directly — by opening it in a terminal multiplexer pane. loopkeep drives four: herdr, tmux, zellij, and cmux. The policy gate is unchanged inside a pane; the multiplexer only decides where the session shows up, not what it may do.

Choosing a multiplexer

By default loopkeep auto-detects one and uses whichever it finds. To pin a choice or turn the feature off, set multiplexer.id in config.yaml:

multiplexer:
  id: tmux # herdr | tmux | zellij | cmux — omit to auto-detect, "none" to disable

With none, attended runs fall back to headless and take-over inherits your current terminal instead of opening a pane.

Where panes open

An attended run's pane opens at a stable location: a space (the multiplexer's session or workspace), a tab (a window within it), and a pane named after the run id — so you can find run run_000123 by name. A take-over of that run lands in the same place.

Space and tab each resolve the same way, first match wins:

  1. the workflow's x-loopkeep.mux.space / .tab,
  2. multiplexer.options.space / .tab in config.yaml,
  3. the built-in defaults loopkeep and automation.
# config.yaml — defaults for every attended pane
multiplexer:
  options:
    space: loopkeep
    tab: automation

What each mode needs

Multiplexers differ in what loopkeep can ask of them. An attended run needs one that can open a pane, inject text into it, and report whether it's still alive — the full set. A take-over only needs to open a pane, since you drive it by hand from there. When the resolved multiplexer can't meet a mode's needs, that mode falls back: attended to headless, take-over to your current terminal.

PreviousTake-over & hand-back
NextSecrets