Files
tai/research/shell-multiplexer-auto-attach/tmuxai-dev-control-mode.md
T
retoorandClaude Sonnet 5 9dbd1fe667 Add plexer subsystem, container test infra, and last-resort opencode box backend
- Plexer: always-active terminal multiplexing. NativePlexerController/
  TmuxPlexerController share one interface, chosen by which env var is
  already set (TAI_PLEXER_SOCKET vs TMUX_PANE); NativePlexerBackend is
  the pty.fork()-based wrapper (raw mode, SIGWINCH resize forwarding,
  a Unix-socket control protocol, continuous session logging, a
  Ctrl+A prefix key distinct from tmux's own Ctrl+B). Auto-wraps new
  interactive shells via a .bashrc hook mirroring the existing
  command-not-found install pattern, gated on $TMUX/$TAI_PLEXER_ACTIVE/
  a $HOME/.tai-no-plexer bypass. New plexer_send/read/type/status
  tools, env-gated on a detected controller.
- tests/container.py + docker-compose.yml + tests/docker/Dockerfile:
  a disposable podman/docker image for the tests that must never touch
  a real machine (installing the plexer hook into a real ~/.bashrc, a
  live tmux session). Required suite (test_seal.py, test_tai.py,
  tests/plexer.py, tests/bashrc.py) gates the result; tests/rag.py
  runs as best-effort since its real-LLM dependency can't be satisfied
  inside a disposable container with no nested engine.
- tests/bashrc.py: real end-to-end hook install + bash -i auto-wrap,
  anti-recursion, tmux-active skip, non-interactive skip, a live
  TmuxPlexerController test, and an install/uninstall round-trip.
- tests/plexer.py: NativePlexerBackend under a real pty, plus a
  dedicated robustness pass (file permissions, >64KB payload framing,
  a malformed control request, a genuine self-deadlock fix in the
  write-to-child path).
- tai_test.py: the shared async process-driving framework (pipe/pty
  transport, group-wide kill-and-reap, a StdinBridge for --interactive)
  both test files build on.
- ChatClient last-resort backend: when there's no local opencode CLI
  but the sandbox box is already running, install opencode into it
  (official Node tarball, not apt -- apt's nodejs/npm pull in
  webpack/babel/jest as transitive deps) and route through it instead
  of giving up. Only reachable after the first retry round already
  failed everything else; never creates the box itself. TmuxPlexerController.status()
  fixed to use `list-panes` instead of `display-message -p`, which
  silently fell back to the default pane instead of erroring against
  a dead target.
- Fix 4 pre-existing test_tai.py bugs surfaced by running it in a
  clean environment for the first time: two stale mock signatures
  (subprocess.run's stdout= kwarg, Chat.complete's deadline= kwarg),
  one $TMUX-dependent catalog assertion, one tty-dependent color
  assertion.
- research/: a sourced research archive (Source Dossier/Citation
  Card/Conclusion tiers) backing the above design decisions, with its
  own audit.py consistency checker.
- .gitignore: fix a blanket *.md rule that was about to silently drop
  the entire research/ archive from version control; add __pycache__/
  and the one-off debug transcript this session started from.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-10-10 04:36:05 +02:00

2.2 KiB

How to use tmux control mode? (tmuxai.dev)

Metadata

Field Value
Institute Molodetz Institute — Research & Retrieval Division
Subject shell-multiplexer-auto-attach
Document type Source Dossier
Tier 1
Source title How to use tmux control mode?
Source URL https://tmuxai.dev/tmux-control-mode/
Source publisher / author tmuxai.dev
Source type blog post
Source date (published) Unknown — not stated
Date researched 2026-10-09
Researched by tai (agent), model: Claude Sonnet 5, on behalf of retoor
Research method web search synthesis
Confidence Medium
Status Active

Summary

Explains tmux's control mode (-C/-CC): a text-only protocol where a client writes newline-terminated tmux commands to stdin, and each command's output is framed between a %begin line (with timestamp and command number) and a closing %end (success) or %error (failure). Asynchronous events arrive as %-prefixed notifications that never appear inside an output block.

Key findings

  • Deterministic framing (%begin...%end/%error) means a program can reliably know where one command's output stops, which plain send-keys+capture-pane polling cannot guarantee on its own.
  • Notifications are guaranteed not to interleave inside a command's output block — a real concurrency guarantee useful for building a parser.
  • -CC additionally disables echo, which matters for programmatic clients that don't want their own commands echoed back.

Pros / strengths

  • Gives the exact framing contract (%begin/%end/%error) needed to write a correct parser for a control-mode client, which is the structured alternative to screen-scraping capture-pane output.

Cons / limitations / caveats

  • A blog post, not tmux's own specification — cross-check framing details against the tmux source or man page before depending on them in production code.

Relevance to tai

This is the mechanism for the "events" requirement in the proposal — control mode's notification stream is how a tai layer would receive pane-output/window-change events asynchronously rather than polling capture-pane in a loop.

Changelog

Date Change
2026-10-09 Initial dossier created.