podwise-cli is a Go client for one podcast backend, with an MCP server and eight agent workflows bolted on

Four install paths, and one of them pipes a script into your shell

macOS users get a Homebrew tap:

brew install hardhackerlabs/podwise-tap/podwise

Everyone else has three options of differing transparency. The automatic route fetches a script from the raw content host and hands it to a shell in one line:

curl -sL https://raw.githubusercontent.com/hardhackerlabs/podwise-cli/main/install.sh | sh

That is convenient and it is also unpinned: the URL points at the main branch, so the script's contents can change without a release. The manual route asks you to download an archive for your OS and architecture from GitHub Releases, unpack it, move the podwise binary onto your PATH, and mark it executable with chmod +x.

The source route needs Go installed and is three commands:

git clone https://github.com/hardhackerlabs/podwise-cli.git
cd podwise-cli
go build -o podwise .

Each of the four leaves you with the same binary, and each assumes a different amount of trust in the project's infrastructure. The manual route is the only one where you can see what you are running, since you chose the archive and verified the name of the file yourself, and it is the only one that gives you a checksum to compare, because the release upload step is what produces dist/checksums.txt.

The module path says hardhacker while the repository says hardhackerlabs

go.mod opens with a different identity from every URL in the documentation:

module github.com/hardhacker/podwise-cli

go 1.25.8

The clone instructions, the curl URL, the Homebrew tap and the releases link all name the hardhackerlabs organization. The Go module declaration names hardhacker. For a build from source that is harmless, because go build resolves imports from the vendor directory and the local module. For anything that treats the module path as an identity, a dependency scanner, an SBOM tool or a proxy rule, the two names will not match and one of them will look like an unknown source.

The Go version line is worth noticing too. It requires 1.25.8, a patch-level pin, so a machine on an earlier 1.25 patch cannot build it without upgrading the toolchain first.

Authorization happens in a browser and the key lands in a TOML file

The credential flow is designed for a person at a keyboard, not for a container:

# Open the browser authorization flow
podwise auth

# Verify connection
podwise config show

Running auth opens a browser, and whatever comes back is saved for you. If you already hold a key, the manual path is:

podwise config set api_key your-sk-xxxx

Storage is a single file at ~/.config/podwise/config.toml, parsed by BurntSushi/toml, one of only five direct dependencies. That is a small surface, and it is also a plaintext key on disk in a well-known location.

For the automation this tool is meant to serve, the browser step is the awkward part. An agent calling podwise get summary cannot complete a browser authorization flow on its own, so the key has to be placed into that file beforehand.

The verification command matters for that setup. podwise config show is the documented way to confirm the connection works, which means you can check a key was written correctly without spending a request on an episode. In a container image, the same file is the artifact you have to bake or mount, and nothing in the documentation describes a non-interactive login.

Retrieval is separated from processing, so an episode needs two round trips

Processing and fetching are separate command groups. A URL or a local file goes in first:

# Podwise episode URL (Recommended)
podwise process https://podwise.ai/dashboard/episodes/7360326

# local file
podwise process ./episode.mp3

Then a later command reads the output, and the summary and transcript are addressed by the same episode URL:

# Get summary
podwise get summary https://podwise.ai/dashboard/episodes/7360326

# Get transcript
podwise get transcript <episode-url>

So the URL is the identifier that ties the two steps together, and the second command is the one that has to wait for the first to finish server-side. The documentation marks the podwise.ai dashboard URL as recommended, with a Xiaoyuzhou URL and a YouTube URL as alternates and a local file as the fourth input type.

Two consequences follow from that split. A script has to hold the identifier across two invocations, and a failed processing run is invisible from the CLI, because nothing here reports how far along the service is. Where a whole library is wanted, the search commands take a limit and a target kind, so podwise search episode "machine learning" --limit 20 and podwise search podcast "Lex Fridman" cover the two ways in.

The MCP server exposes sixteen tools over stdio

One command turns the binary into an MCP server that speaks over stdin and stdout:

podwise mcp

The tool list is the real interface. Retrieval covers search_episode, search_podcast, popular, list_episodes, get_transcript, get_summary, get_qa, get_chapters, get_mindmap, get_highlights, get_keywords, plus ask, which sends a question answered from podcast transcripts. Subscription state has its own trio: drill lists recent episodes for one podcast by its Podwise URL, follow and unfollow both take that URL and are described as idempotent.

Two features are worth separating from the rest. get_transcript returns text, SRT or VTT, so the same tool serves a reader and a subtitler. ask runs the question through the service rather than grepping locally, which means an answer you get back carries the service's interpretation rather than a span of transcript you can quote.

The retrieval tools are split by output shape rather than by subject. Chapters, highlights and keywords all come back with timestamps or descriptions attached, mind maps come back as a structure, and Q&A comes back as pairs. An agent wiring these together gets structured fields to work with, which is the reason the project exists as a binary rather than as a library someone imports.

Eight workflows ship as a skill, and the CLI has to exist first

The agent skill installs with one command:

npx skills add hardhackerlabs/podwise-cli

The documentation puts a prerequisite above it: the podwise binary must be installed and your api_key must already be set, or the workflows have nothing to call. The skill then routes intent to one of eight named workflows, catch-up, weekly-recap, episode-notes, topic-research, episode-debate, language-learning, discover and refine-taste.

Three of them write somewhere other than the terminal. episode-notes exports summaries and highlights to Notion, Obsidian or Logseq. language-learning turns a transcript into Anki flashcards. discover and refine-taste build on a listener profile, which means taste has to be gathered before recommendations mean anything.

The runtime model is documented as three steps: load the CLI reference docs, match your intent to a workflow, then execute the workflow steps or the raw CLI command.

Releases ship twice, once by tag and once by upload

The Makefile carries two paths out of the same tree:

release:
	@$(if $(strip $(version)),:,$(error version is required: make release version=v1.2.3))
	git tag $(version) && git push origin $(version)
	goreleaser release --clean

upload:
	@$(if $(strip $(version)),:,$(error version is required: make release version=v1.2.3))
	gh release create $(version) ./dist/*.tar.gz ./dist/*.zip ./dist/checksums.txt --generate-notes --title "$(version)" --latest

Both fail fast if version is empty, which is the useful part. The difference is that release drives goreleaser, which is where a .goreleaser.yaml at the top level comes in, while upload calls the GitHub CLI directly against whatever is sitting in ./dist. Running them in sequence publishes twice, and nothing in the file stops you from doing that.

The three most recent tags, v0.4.0, v0.4.1 and v0.4.2, landed on 2026-05-05, 2026-05-19 and 2026-05-31, with the last commit on 2026-05-31. The direct dependency set is five modules: cobra for commands, BurntSushi/toml for config, the MCP Go SDK, glamour for terminal rendering and charmbracelet/x/term for terminal detection.

Editorial conclusion

Adopt it if your automation already has a podwise account and you want transcripts and summaries as text an agent can read rather than as browser output. Check two things before you install it on a machine you care about: whether the curl-and-shell route is acceptable under your policy, since it executes a script fetched from the main branch, and whether your team accepts a dependency whose module path is github.com/hardhacker/podwise-cli while the code lives under hardhackerlabs. For anything scripted, pin a release tag, because the last three were published within eight weeks of each other and the default branch moves after a tag.

Frequently asked questions

Official sources

1. hardhackerlabs/podwise-cli on GitHub
2. License: MIT
3. Project website
4. README
5. Releases