tmux-fzf-url: open the links on your terminal without touching the mouse

Read the screen, pick a link, open it

tmux-fzf-url is a tmux plugin for opening URLs from the browser quickly without a mouse, and the idea is as simple as it sounds.

The plugin captures the text on the current tmux screen, extracts everything that looks like a link, and hands the list to fzf. You pick one, and it opens in your browser. The default key binding is u, with the tmux prefix required, and the binding can be changed through a tmux configuration option.

That last detail is the thing that makes the plugin usable rather than a curiosity. A terminal user who already lives in tmux has muscle memory for the keys, and a plugin that hardcodes one is a plugin that gets rebound. The configuration option is a single line.

set -g @fzf-url-bind 'x'

The dependencies are short and all of them are things a terminal user is likely to have already. There is tmux, fzf, and bash, plus a small extraction tool called xre, which is auto-installed on the first use.

The plugin is listed in the tmux plugin manager index and in the awesome tmux list, and the project is MIT licensed by Wenxuan Zhang. The last push was on 2026-08-13 and there are no tagged releases, so you install from the branch.

The repository itself is three files and a test directory: a shell script, a tmux script, the tests, and a submodule configuration for the test framework.

Two installation routes, and a legacy branch

The installation is documented for the tmux plugin manager and by hand, and the manual route is two commands.

With the plugin manager, you add one line to the tmux configuration and then reload the plugins with the prefix and I.

set -g @plugin 'wfxr/tmux-fzf-url'

By hand, you clone the repository into the plugins directory.

git clone https://github.com/wfxr/tmux-fzf-url ~/.tmux/plugins/tmux-fzf-url

And then the tmux configuration needs one more line, so that tmux runs the plugin script when it starts.

run-shell ~/.tmux/plugins/tmux-fzf-url/fzf-url.tmux

The third route is the interesting one, because it is a compatibility promise rather than an installation. The legacy version has no dependency on the xre extraction tool and uses grep instead, and you get it by pinning to the legacy tag.

set -g @plugin 'wfxr/tmux-fzf-url#legacy'

Or, for a manual install of that version, the clone command with a branch argument.

git clone -b legacy https://github.com/wfxr/tmux-fzf-url ~/.tmux/plugins/tmux-fzf-url

So if the current version misbehaves on a machine, or if the xre installation is a problem in a restricted environment, there is a documented older path rather than a bug report.

What it recognises, and what you can make it recognise

The supported URL types are listed in the README, and the list is broader than plain links.

Standard URLs are the obvious case, with the http, https, ftp, and file schemes. A bare host name written as www.example.com is recognised and prefixed with the http scheme automatically.

IP addresses are recognised, including a host and a port, such as an address with a port and a path. Git SSH remotes are recognised and converted to an https link, and GitHub shorthand, a user and repository written in single or double quotes, is converted to a link on the GitHub domain.

The last entry is the important one, because it is the extension point. A custom pattern can be supplied as a regular expression, with an optional replacement, and the example in the README turns a Jira ticket identifier into a link on a ticket tracker.

# capture files like 'abc.txt'
set -g @fzf-url-custom-pat '\b[a-zA-Z]+\.txt\b'

# capture Jira ticket IDs and turn them into URLs
set -g @fzf-url-custom-pat '[A-Z]+-\d+'
set -g @fzf-url-custom-sub 'https://jira.example.com/browse/$0'

That is the feature that turns this from a link opener into a general terminal picker, because a lot of what appears in a terminal is not a URL at all. A file name, a ticket reference, a container id, a commit hash, all of them are strings that could be turned into something clickable, and the pattern option is how you decide which.

The replacement is optional, and the dollar zero in the example is the matched text, which is the standard substitution convention and is worth recognising because it is what makes the second pattern produce a working ticket link rather than a bare identifier.

Screen, scrollback, and the shape of the popup

The default is to capture the current screen, and the scrollback history is one option away.

set -g @fzf-url-history-limit '2000'

The README calls the option history_limit, and the value is a number of lines, so this widens the capture from the visible pane to two thousand lines of scrollback, which is the difference between finding the link that is on screen now and finding the one that scrolled past twenty minutes ago.

The popup itself is an fzf window, and the fzf options can be replaced wholesale through a configuration option, with the example showing a half width, half height, multi-select, no preview, and no border setup.

# these options are passed to fzf-tmux
set -g @fzf-url-fzf-options '-w 50% -h 50% --multi -0 --no-preview --no-border'

The multi-select and the zero exit mode are the two that matter in practice, because they are what allow the tip in the README's own tips section, marking several URLs and opening them at once.

The theme in the screenshot is not the plugin, it is another one by the same author, tmux-power, which is listed among the related plugins along with tmux-net-speed. A similar project by a different author is mentioned too, tmux-fzf-links, described as a more versatile tmux plugin that allows searching for and opening links, and it is the one to look at if the fzf integration you want is not the one here.

Opening, and copying instead of opening

How the selected link is opened is a configuration option, and the default follows the conventions of the platform.

By default the plugin uses xdg-open, or open, or the BROWSER environment variable, respectively, and a different command can be set with the open option.

set -g @fzf-url-open "firefox"

The other half of that is copying rather than opening, and it is the feature that makes the plugin safe to use on a remote machine. Pressing ctrl-y inside the fzf popup copies the URL to the clipboard, and the popup stays open, so you can copy several in a row and paste them wherever they need to go.

The clipboard command is auto-detected, and the list of candidates is the one that tells you what the author had to support: clip.exe on WSL2, pbcopy on macOS, wl-copy on Wayland, xclip or xsel on X11, and tmux load-buffer as a fallback, which is the one that always works because it is part of tmux itself.

It can be overridden.

set -g @fzf-url-copy-cmd 'xclip -selection clipboard'

So the plugin has two outputs, open and copy, and the copy path is the one that matters when the machine you are sitting at is not the machine with the browser.

Tests, submodules, and the shape of the repository

The development section is short, and it is the part of the repository that shows the project is maintained like a tool rather than a script.

To work on it, clone with the test dependencies, and then run the tests with the bats runner from the vendored subdirectory.

# Clone with test dependencies
git clone --recurse-submodules https://github.com/wfxr/tmux-fzf-url
cd tmux-fzf-url

# Run tests
./test/libs/bats-core/bin/bats test/*.bats

The tests use bats-core, the Bash Automated Testing System, and the framework is vendored as a git submodule rather than being expected on the machine. The README covers the case where the clone was done without the submodules, with a command to fetch them.

git submodule update --init --recursive

Vendoring the test framework is a deliberate choice for a shell project. The alternative, requiring bats to be installed, puts an extra prerequisite on every contributor and every CI runner, and for a plugin whose whole selling point is that it has almost no dependencies, that would be inconsistent.

The repository layout is small and follows from that. There are the two implementation files, a shell script and a tmux script, the test directory with the vendored framework, a submodule configuration, an editor configuration, a funding file, a licence file, and an agent instruction file. The last one is the same convention that keeps appearing in these repositories, where the project states how it wants automated contributions to arrive.

There is also a legacy branch, and the two are kept working side by side, which is the sort of maintenance that rarely gets mentioned in a readme and always shows up in the version you are actually running.

Editorial conclusion

tmux-fzf-url fits a terminal user who reads documentation, logs, and chat in tmux and wants to follow a link without reaching for the mouse, and who already has fzf installed. It does not fit a mouse driven workflow, and it does not fit a machine where the terminal output you want to search is not in tmux. Verify first that the key binding does not collide with one of your existing tmux bindings, since the default takes the u key, that the browser you want is what the open command resolves to, and that the extraction pattern matches the URLs you actually see, because the default pattern finds links in URLs and not the bare host names and ticket identifiers that a lot of terminal output uses.

Frequently asked questions

Official sources

1. Issues
2. README
3. wfxr/tmux-fzf-url on GitHub