What's new
Pluggable workspace builders (#1066)
tmuxp can now build a workspace with a builder other than its built-in one. Point a workspace file's workspace_builder key at an installed builder — by registered name or by Python import path — and tmuxp loads the session through it. Builders that ship outside tmuxp's environment can be imported from directories listed in workspace_builder_paths, which tmuxp trusts only for that load. The built-in builder stays the default, so existing workspaces are unaffected.
Configurable pane readiness (#1066)
Before sending a pane's layout and commands, tmuxp can wait for the shell to draw its prompt — a guard against a zsh prompt-redraw artifact. That wait is now a policy you set per workspace:
workspace_builder_options:
pane_readiness: auto # auto | always | never (also true/false)The new default, auto, waits only when the session's shell is zsh, so zsh users see no change while bash, sh, and other shells skip a wait they never needed. Set always to keep the previous wait-everywhere behavior, or never to skip it entirely.
Workspace builder API (#1066)
tmuxp.workspace.builder is now a package. The default builder is ClassicWorkspaceBuilder, with WorkspaceBuilder kept as a backwards-compatible alias. Third-party builders implement WorkspaceBuilderProtocol (shaped to allow async builders later) and are resolved by resolve_builder_class() from an entry point or import path, with trusted import directories handled by resolve_builder_paths(). Builder behavior is configured through WorkspaceBuilderOptions and PaneReadiness, and resolution failures raise WorkspaceBuilderError and its subclasses.
See the custom workspace builders guide for details.
What's Changed
Full Changelog: v1.72.0...v1.73.0
