asciimoo/wuzz: An Interactive CLI for HTTP Inspection

The gap wuzz fills between curl and a GUI client

curl sends a request and prints a response. If the response is wrong, you edit the command line and run it again, and the previous output is gone. Wuzz keeps the request and the response on screen at the same time and lets you move between them with function keys. The README describes the tool as an "Interactive cli tool for HTTP inspection" and notes that its arguments are similar to cURL's. That similarity is the whole point of the design: you copy a request out of a browser's network inspector with the "copy as cURL" feature, paste it into wuzz, and then change it in place instead of editing a shell string.

The audience is narrow and specific. It is for backend engineers and API consumers who are already comfortable in a terminal and who treat a request as something to be inspected rather than scripted. It is not a load tester, not a proxy, and not a replacement for an API client with saved collections.

How wuzz splits a request into editable views

The interface is organised around views, and the keybinding table in the README maps each function key to one of them: F2 for the URL, F3 for query parameters, F4 for the HTTP method, F5 for the request body, F6 for headers, F8 for response headers, F9 for response body. Tab and Shift+Tab move between views. Ctrl+R sends the request, and Enter sends it when focus is in the URL view. That layout is the mechanism: the request is not a text blob you edit as a whole, it is a set of fields the UI keeps separate, so changing a header does not risk breaking the body.

Two features go beyond plain request editing. F11 toggles a redirects restriction mode, which the README lists without further explanation, so the exact behaviour of that mode is not documented. Ctrl+T toggles context specific search, and the README states that wuzz accepts regular expressions by default to filter the response body. When the context specific syntax is on, HTML responses are queried with goquery selectors and JSON responses with gjson paths, both of which are dependencies in go.mod. That means you can type a CSS selector against an HTML response instead of writing a regex against the raw markup, which is a real difference in effort when the document is large.

Installing wuzz and sending a first request

The README lists several installation routes. Go is the primary one, and it requires Go 1.10 or newer. The go.mod file in the repository declares go 1.25.0, so a current toolchain is the safer assumption when building from source.

go get github.com/asciimoo/wuzz
"$GOPATH/bin/wuzz" --help

After that, the binary lands in your GOPATH bin directory and the help output lists the available flags. If you would rather not build it, the README points to binary releases on the GitHub releases page, and also documents package manager installs for apt, apk, Scoop, X-CMD and Nix.

apt install wuzz

Once it starts, the tool opens a terminal UI. Paste a cURL command or type a URL, press Ctrl+R to send, then use F6 to jump to headers and F9 to jump to the response body. Ctrl+S saves the response and Ctrl+E saves the request, so a request you have tuned can be kept and reloaded later with Ctrl+F. Configuration lives in a TOML file: the README gives "$XDG_CONFIG_HOME/wuzz/config.toml" on Linux and ~/.wuzz/config.toml elsewhere, and -c or --config loads a file from a custom path. The repository ships sample-config.toml as the reference for the available keys.

wuzz -c ./sample-config.toml

What you should see is the request view populated with whatever you passed in, and after Ctrl+R a status line and the response tabs filled in.

Where wuzz stops being the right tool

The README's own TODO list is the most honest limitation: "Better navigation", "Autocompletion", and "Tests". A tool that lists tests as an outstanding item is telling you something about how much you can lean on it in a pipeline. Wuzz is interactive by design, and nothing in the README describes a non-interactive mode, a way to emit a response to stdout, or an exit code contract. If you need to run the same request in CI or assert on a response body, wuzz is the wrong instrument; the repository has a wuzz_test.go file, but the README still carries Tests as a TODO, so treat the test coverage as unverified.

The release cadence is the second constraint. The most recent tagged release listed is v0.5.0 from 2021-01-19, with v0.4.0 before it in 2017 and v0.3.0 in 2017. The repository has not been archived and the last push was on 2026-08-04, so work is happening on the branch, but the tags are far behind. Anyone who pins a version rather than tracking master is pinning something from 2021. There is also no homepage field, so the README is the documentation.

Finally, the licence is AGPL-3.0. For a personal inspection tool that is usually irrelevant. For anyone considering embedding wuzz in a networked product, the copyleft terms are worth reading before you build on it, and that is a question for your own legal review rather than something this article can settle.

How wuzz differs from mitmproxy and Postman

The nearest alternative in spirit is mitmproxy, and the difference is where the request comes from. mitmproxy sits between your client and the server as an intercepting proxy, so requests are captured as they happen, including ones your browser or another program generates without your involvement. Wuzz does not intercept traffic. You hand it a request, it sends that request, and you edit it. That makes wuzz simpler to start but useless for observing traffic you did not construct.

Against a GUI client like Postman, the difference is persistence and collaboration. Postman stores requests in collections, supports environments and variables, and can run a collection on a schedule. Wuzz saves a single request to a file with Ctrl+E and loads it with Ctrl+F. There is no collection concept in the README, no environment variable substitution, and no runner. What wuzz gives you in exchange is that it runs where your shell runs, over SSH if needed, and accepts cURL syntax so an existing command is the starting point rather than something you rebuild by hand.

A plain curl loop is the third comparison. curl is scriptable and ubiquitous; wuzz is neither. The case for wuzz is the iteration loop: when you are changing one header at a time and reading the response, the edit-send-read cycle in a TUI is faster than editing a shell command, and the response stays visible while you do it.

Running wuzz in Docker and what the image actually does

The repository includes a Dockerfile, and reading it is the fastest way to understand the intended runtime. It is a multi-stage build on alpine:3.12. A first stage makes docker-entrypoint.sh executable, a second stage builds the binary with golang:1.14-alpine3.12, a third stage copies the binary and the entrypoint together, and the final stage places both in /usr/local/bin with WORKDIR /wuzz and the entrypoint set to docker-entrypoint.sh.

Two things stand out. The builder pins Go 1.14 while go.mod declares go 1.25.0, so the container build path and the source build path are not aligned, and a build from this Dockerfile may not match what a modern local toolchain produces. Second, the image is built to run interactively; a TUI needs a TTY, so any container invocation needs the appropriate terminal flags. The Dockerfile itself does not document how to pass arguments through, and the README does not cover the Docker route at all, so the entrypoint script is the place to look.

Editorial conclusion

Adopt wuzz if you spend your day in a terminal, already have cURL commands to work from, and want to edit a header or a query parameter without retyping the whole invocation. Skip it if you need a scripting interface, a collection runner, or a tool with a test suite you can rely on, because the README lists Tests under TODO and the last tagged release was v0.5.0 on 2021-01-19. Before you build anything on it, check whether the behaviour you need is documented at all: the README does not document rollback, retry, or any non-interactive mode.

Frequently asked questions

Official sources

1. asciimoo/wuzz on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases