tmux-python / tmux-python/libtmux

Research tmux-resurrect parity for workspace archives

Open
#701 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Python
Stars
1.2k
Forks
127
Avg merge
2h 13m
Merged PRs (30d)
1

Description

Goal

Research tmux-resurrect parity for a pure-Python libtmux workspace archive API that does not require TPM or shell plugin scripts. The target consumers are libtmux itself, tmuxp, and agent/MCP surfaces that need headless save/restore behavior.

A first experimental slice exists in libtmux's workspace layer: capture tmux state through list-panes -a -F, persist canonical Workspace IR as JSON, and restore through WorkspaceSet. This issue tracks the remaining parity research and product decisions.

Upstream baseline

Research questions

  • What should libtmux's archive schema guarantee beyond canonical Workspace IR: grouped sessions, alternate windows/sessions, zoom state, pane titles, automatic-rename, shell history, pane contents, and full process command lines?
  • Should libtmux support import/export compatibility with tmux-resurrect's tab-delimited save files, or keep JSON Workspace IR as the native format and provide a separate converter?
  • Which process restore policies belong in libtmux core versus tmuxp or downstream tools: conservative whitelist, per-command strategy plugins, inline restore commands, or no process restore by default?
  • How should archive writes handle rotation and last pointers portably without assuming POSIX symlinks?
  • What is the minimum live integration matrix: Linux, macOS, BSD, Cygwin/MSYS, nested tmux, custom -L/-S sockets, and headless CI?

MVP/sprint proposal

  1. Keep the current MVP as the base: one tmux read, canonical WorkspaceSet JSON, atomic write, restore through existing engines.
  2. Add a typed archive metadata/version layer with explicit capability flags so future readers can know which parity features were captured.
  3. Add focused tests for layout, focus, selected-session capture, archive read/write, restore-on-existing policy, and no-TMP/no-TPM operation.
  4. Prototype optional tmux-resurrect file import as a converter, not the primary persisted format.
  5. Prototype command-capture providers separately from restore policy so Linux /proc, macOS ps, and Cygwin process discovery can evolve independently.

Tradeoffs

  • Native JSON Workspace IR is idiomatic Python and easy for tmuxp/MCP to consume, but it is not drop-in compatible with existing tmux-resurrect save files.
  • tmux-resurrect row compatibility helps migration, but it imports shell-era escaping and plugin-specific process strategy semantics.
  • Pure Python archive/restore is feasible for topology, cwd, layout, and focus on systems with tmux available. Full process resurrection is OS-specific and should be opt-in.
  • Pane contents and shell history are valuable but risk large archives and privacy-sensitive payloads; they need explicit enablement and size controls.

Acceptance criteria

  • Document the parity matrix against tmux-resurrect v4.0.0.
  • Decide native archive schema vs tmux-resurrect-compatible schema vs converter split.
  • Identify the first supported OS/process-capture strategy matrix.
  • Produce tests that run headlessly in CI without TPM.
  • Leave enough API surface for tmuxp and MCP callers to save, inspect, restore, and dry-run archives.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the existing workspace-layer capture using list-panes -a -F, canonical WorkspaceSet JSON, and the restore path through WorkspaceSet. Compare the upstream scripts/save.sh and scripts/restore.sh, then define the parity matrix, archive schema decision, OS/process strategy matrix, and headless CI tests required by the acceptance criteria.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend-api-design
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.