sesh: A Smart tmux Session Manager Built Around zoxide

The gap sesh fills between zoxide and tmux

tmux itself has no opinion about which directory a session belongs to. You type tmux new -s something, you invent a name, and the next day you have three sessions called work, work2 and scratch. sesh takes the naming decision away from you. The README describes it as a CLI that helps you create and manage tmux sessions quickly and easily using zoxide, and that sentence is the whole scope: it is glue between a directory jumper and a multiplexer.

The target user is narrow and identifiable. You already use tmux as your terminal workspace, you already use zoxide so your frequently visited project directories have a score attached to them, and you are tired of typing session names by hand. If any of those three conditions is false, sesh has little to offer. It does not start a terminal, it does not replace tmux, and the README does not present it as a general project launcher for people who work outside a multiplexer.

How session naming and the picker actually work

The README lists the naming sources directly: sesh automatically names sessions based on git repo, git remote, or directory. That ordering matters. A git repository gives the most stable identity, a git remote gives you something closer to the upstream project name, and a bare directory is the fallback when neither applies. The repository layout backs this up: there are separate top-level packages named git/, zoxide/, namer/, lister/, picker/, connector/, startup/, cloner/, mkdirer/, worktree/ and tmux/. Each one is a small unit with a single job, which is what you would expect from a Go CLI assembled around a command dispatcher.

Listing and selection are split as well. The lister/ package produces candidate sessions, the picker/ package presents them, and the picker is built on the Charm stack: go.mod requires charm.land/bubbles/v2, charm.land/bubbletea/v2 and charm.land/lipgloss/v2, so the built-in selector is a Bubble Tea program rather than a plain prompt. The README also says you can integrate with fzf, television, or gum instead, which means the built-in picker is optional rather than the only path.

Configuration lives in sesh.toml, and the README names three things you can define per project: startup commands, windows, and preview commands. Wildcard configs extend that to every project matching a glob pattern. That is the mechanism to understand: sesh is not inferring your project structure, it is applying rules you wrote, keyed by session name or by a glob that matches one.

Installing sesh and starting a first session

The README documents several package managers. On macOS and Linux with Homebrew the command is a single line. After it finishes, sesh should be on your PATH, and running it with no arguments is the way to see the default behaviour.

brew install sesh

If you prefer Go, the README gives the module path with the v2 major version suffix. The Go toolchain downloads and installs the latest tagged version.

go install github.com/joshmedeski/sesh/v2@latest

Fedora and EPEL 10 users go through a Copr repository, which the README names explicitly. Note that the package is called tmux-sesh there, not sesh.

sudo dnf copr enable buckaroogeek/Tmux_sesh
sudo dnf install tmux-sesh

Arch users install from the AUR with yay, and the package is sesh-bin. Conda and Pixi users have their own commands, and Nix users are pointed at the nix package directory rather than given a command in the README.

yay -S sesh-bin

Once installed, the README mentions shell completion for Bash, Zsh, Fish and PowerShell, generated by a completion subcommand. For Zsh the README writes the script to a file named _sesh and places it on fpath.

sesh completion zsh > _sesh
mkdir -p ~/.zsh/completions
cp _sesh ~/.zsh/completions/

The README also has a recommended tmux settings section, which is worth reading before you bind keys, because several of the features assume particular tmux options are set. It does not spell out a single canonical first command, so treat the picker as the entry point and let the completion list show you the subcommands.

Where sesh stops being the right tool

The clearest limitation is structural: sesh is a front end to tmux, so every feature depends on tmux being installed and, for some paths, already running. The README's Raycast extension section states this as an explicit constraint, saying tmux has to be running before you can use the extension. That is the extension, but the dependency is the same one the CLI sits on.

The second limitation is that sesh inherits zoxide's blind spots. If your directory history is thin, the smart naming has less to work with, and the README does not describe a fallback ranking beyond git repo, git remote and directory. A machine where you have just cloned one repository is not a machine where sesh looks clever.

The third is configuration drift. sesh.toml is hand-written, and wildcard configs apply to every matching project. A glob that is broader than you intended will attach startup commands to sessions you did not mean to touch, and the README does not describe a dry-run mode for checking which configs a session will pick up. If you want a tool that discovers projects and their build systems on its own, sesh is the wrong layer; it applies the rules you supply.

sesh against tmuxinator and plain tmux scripting

The obvious comparison is tmuxinator, and the repository itself acknowledges it: there is a top-level tmuxinator/ directory alongside tmux/, which suggests sesh reads or converts tmuxinator-style project definitions. The difference in approach is real. tmuxinator is project-first: you write a YAML file per project describing windows, panes and commands, and you start that project by name. sesh is directory-first: the session identity comes from where you are, or from what zoxide remembers, and configuration is an optional overlay in sesh.toml.

That means tmuxinator is better when a project needs a fixed, elaborate pane layout that you want reproduced exactly. sesh is better when you move between many repositories and mostly want the right session to exist without naming it. They are not mutually exclusive, and the presence of the tmuxinator/ package hints the author did not treat them as such.

The other alternative is doing nothing: a shell function wrapping tmux new-session -A -s with a basename of the current directory gets you part of the way in about three lines. What you give up is the picker, the zoxide ranking, the git remote naming, and the per-project startup commands. Whether that trade is worth a compiled binary is a fair question, and the answer depends on how many sessions you juggle.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-21. Releases have followed quickly: v2.30.0 on 2026-09-09, v2.30.1 on 2026-09-10, and v2.31.0 on 2026-09-21. A patch release the day after a minor release is a normal sign of a project that fixes what it ships, but it also means the version you pin can move under you if you install from a channel that tracks latest.

The licence is MIT, which is permissive and imposes no copyleft obligation on your own code. That is the extent of what can be said here; the repository's LICENSE file is the authoritative text and this is not legal advice.

Upgrade cost is mostly the sesh.toml contract and the CLI surface. The module path carries a v2 major version, so the Go module system will not silently move you across a major boundary. The justfile shows the project's own test and benchmark workflow, including a bench target scoped to the lister and picker packages, which tells you where the maintainers expect performance to matter. It does not tell you anything about your machine's performance.

Editorial conclusion

Adopt sesh if you already run tmux and keep your projects in zoxide, because the naming and switching logic only pays off on top of that existing setup. Skip it if you do not use tmux, or if you expect it to manage terminal multiplexing for you. Before installing, confirm that zoxide is present and populated, check where the binary expects sesh.toml, and decide whether the built-in picker or an external one such as fzf fits your keybindings.

Frequently asked questions

Official sources

1. Issues
2. joshmedeski/sesh on GitHub
3. License: MIT
4. README
5. Releases