Skip to content

Gate unsafe optional tmux features independently #778

Open

Description

@tony

Summary

Give optional engines and version-sensitive operations explicit capability boundaries while preserving ordinary operations on supported older daemons. Keep the current tmux 3.2a minimum unchanged. The separate minimum-version proposals #777/#779 remain outside this train.

Motivation

Control acquisition, output observation, buffer cleanup and version-sensitive commands have different requirements. One whole-product minimum or reduced CI coverage cannot express those guarantees accurately.

Proposal

  • Require daemon tmux 3.7 or verified initialization-fix backports before library-managed control acquisition, including internal watches, mirrors and streams; make the decision before attachment.
  • Preserve supported subprocess and polling operations, and return explicit per-operation refusals where no qualified fallback exists.
  • Protect exact named-buffer deletion and temporary-buffer cleanup below tmux 3.4 where these operations are exposed.
  • Preserve exact-3.7 break-pane handling and other still-required codecs, layout validation, readiness, buffering and cleanup.
  • Update capability documentation, examples and focused CI coverage, distinguishing unsupported, timing-sensitive and unverified behavior.
  • Demonstrate that regression gates fail when their protection is deliberately removed, and obtain independent review.

References


Delivery contract from the rmux helper audit

Use one capability vocabulary across cancellation, observations, cells, surfaces, and leases: supported, unsupported, conditional, or unverified, with the reason and relevant backend/version evidence.

Determine capabilities against the connected daemon and selected engine. Do not assume the executable on the client's path describes an already running server. Include reconnect/server-generation invalidation.

Keep the issue's proposed control-acquisition policy, exact buffer-cleanup requirements, and qualified fallbacks. Older supported daemons can retain ordinary subprocess operations even if a control stream or cell export is refused.

Do not bundle the separate core-minimum proposal #777 into this work. Exact new format/version support needs fixtures and a negative gate, not an assumed monotonic feature flag.

Delivery links: #800, #801, #802, #805. Track this work under #629 in the libtmux project.

Independent PR delivery

Follow the minimal slice and shared compatibility contract in #629. Build and test against master with every other unmerged feature branch absent. Cross-links above identify semantic contracts and future consumers; use a private adapter where needed instead of introducing a merge dependency. Preserve existing facade behavior and the inspected engine-ops interfaces. Leave deferred acceptance criteria open after an MVP lands.

Activity

  1. moved this to Todo in libtmuxon Oct 31, 2026
  2. tony commented on Nov 1, 2026

    @tony
    MemberAuthor

    UNVERIFIED — qualification result; implementation remains open.

    The connected-daemon/selected-backend admission contract remains distinct from executable-version parsing. Candidate PR #780 at 5df9cb3e89647577b7dd8484f844ffe1053129bb includes the separate minimum-version work and broad version refactoring; it is not the small standalone admission slice required here.

    A real compatibility probe with the proposed injected engine exposed a concrete observer hazard: command dispatch reaches the selected engine’s daemon while the private control observer attaches to a different facade endpoint with the same numeric session ID. Both borrowed daemons survive cleanup, but observation attribution is wrong. Keep admission here: require refusal or positively routed observation before attachment, conflicting client/daemon version controls and replacement invalidation. Those admission criteria remain UNVERIFIED; ordinary 3.2a operations remain supported and unchanged. No PR inherits #779 or its floor change.

    Evidence and canonical scope: current dispatch, proposed optional gates, byte-observer owner.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    • Status
      Todo

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions