Getting started

Install tmuxLink to section

Every port’s floor is tmux 3.2a — it’s the oldest release all eight are tested against, so anything from there through whatever your package manager ships today will work. Confirm what you have:

$ tmux -V

If that prints something older than tmux 3.2a, or tmux isn’t found at all, install a current one through your platform’s package manager before going further — how to do that is outside libtmux’s scope, since libtmux drives an existing tmux rather than bundling one.

Pick a portLink to section

All eight ports drive the same tmux the same way underneath — the choice is your project’s language, not a difference in what’s possible. Use the port switcher at the top of any page, or jump straight to a landing page: Python, TypeScript, Rust, Go, Java and Kotlin, .NET, C++, Swift. If you’re not sure yet, Server, session, window, pane and Control mode vs one-shot cover what’s shared and what’s worth knowing before you commit.

Every port carries an -alpha prerelease tag today except Python, which is the long-established original the others are ports of — pin an exact version everywhere else, and expect the newer ports’ APIs to still move.

Run the smallest thing that proves it worksLink to section

Start a tmux session to connect to — in one terminal:

$ tmux new-session -s foo -n bar

In a second terminal, install your port’s package and run the round trip below: connect, get a pane, send it a command, and read back what printed. Python’s block attaches to the foo session above; the rest create their own instead, so foo is never touched by anything but Python’s — either way you’ll see the same round trip happen. The install command is repeated as a comment on the first line of each block — it isn’t part of the source being quoted, just this page naming it next to the code. Python’s block is a live doctest, run against a real, isolated tmux session on every run of the test suite (README.md and src/libtmux are pytest’s testpaths, see pyproject.toml); every other block here is the same source Attach and send keys quotes in full, or a shorter cut of it — see that page for exactly how each is checked, for the full version of any block trimmed here, and for the rest of that round trip.

// vcpkg install libtmux-cxx
const auto sessions = server.sessions();
// sessions->at(0) is this example's session, from an already-open scratch server.
const libtmux::Session& session = sessions->at(0);

// Build an arrangement without composing a single tmux argument.
const auto editor = session.new_window({.name = "editor"});
const auto logs = editor->split({.horizontal = true, .percentage = 30});

(void)logs->send_text("journalctl -f");
(void)logs->send_key("Enter");

// Read a pane's visible contents, or its scrollback.
const auto visible = logs->capture();

What just happenedLink to section

Connecting reaches the tmux server already running on the machine (or starts one) — nothing above draws a terminal of its own. Sending a command types it into the pane as if at a keyboard and, where the call takes one, an enter or literal argument decides whether it also presses Enter and whether tmux may read the text as one of its own key names instead of characters — see Sending keys for exactly how each port draws that line. Capturing reads the pane’s visible screen back as a list of lines, top to bottom. That round trip — get a pane, send it something, read back what happened — is the shape nearly everything else in this documentation builds on.

Where to go nextLink to section

Concepts for the mental model behind what you just did — the object hierarchy, how commands actually reach tmux, and how filtering works once you have more than one session to choose from.
Attaching to tmux, Sending keys, and Capturing output go one level deeper into each half of the round trip you just ran.
Attach and send keys for the fully checked version of every block above, and how each one is verified.
Your port’s own API reference (via the port switcher) once you’re ready to build something real.