httptoolkit-desktop: the Electron shell that packages HTTP Toolkit for Windows, Linux and macOS

What httptoolkit-desktop actually owns, and who should clone it

HTTP Toolkit is split into three repositories, and this one is the smallest in scope. The README states that the product consists of a UI, written as a single-page web application, and a server, written as a node.js CLI application. This repository builds a single executable that includes the latest build of httptoolkit-server, starts that server in the background when the app runs, opens the UI in an Electron window, and kills the server when the window closes. Everything else you associate with HTTP Toolkit, the proxy, the interception rules, the request inspector, lives in the other two repositories.

So the audience is narrow. The README says plainly: if you want to change the behaviour of the desktop shell but not its contents, change how it is built, or add a new target platform or format, then you are in the right place. If your goal is to intercept traffic, this repository has nothing for you. That distinction matters because the repository name and the product name are close enough that people land here looking for the application and find build configuration instead.

How the shell starts a server, opens a window and shuts both down

The data flow is short. Electron Builder produces one executable. On launch, the shell spawns httptoolkit-server as a background process, loads the UI into an Electron window, and tears the server down on exit. The UI is served from the packaged build rather than fetched from the network, which is what makes the desktop app work offline apart from the traffic it is proxying.

Two consequences follow from that arrangement. First, the server version is pinned in package.json under config.httptoolkit-server-version, and the build step named server:setup is what pulls it in, so the desktop release and the bundled server move together. Second, the README notes that the resulting executable does not autoupdate. Instead the server, described as an oclif app, and the web UI, via service workers, each carry their own update mechanism. That is an unusual split: the installer you download is static, while its two runtime halves can update themselves. It also means a bug in the shell itself, as opposed to the server or the UI, requires a fresh download to fix.

Installing dependencies and running the desktop app locally

This is a private package (private is set to true in package.json), so it is not published to npm and you run it from a clone. Node is expected; the repository carries an .nvmrc file, so the version is pinned there. Install dependencies first, then start the app. The start script runs server:setup before launching, which fetches the pinned httptoolkit-server build, so the first run does more work than later ones.

npm install
npm start

After npm start, the setup step downloads and prepares the server, then tsc-watch compiles the TypeScript and launches Electron once compilation succeeds. You should see the HTTP Toolkit window open. The postinstall hook runs electron-builder install-app-deps, which rebuilds native dependencies against the Electron ABI; skipping npm install and running the start script directly will fail on that step.

For UI work there is a faster path. start:dev skips the server setup entirely and points the app at a UI dev server on port 8080, so you need the UI running there yourself.

npm run start:dev

Building installers is a separate, heavier command. build:electron runs the server setup and then Electron Builder with the config file at build-setup/electron-builder.config.cjs, while build:dir-only produces an unpacked directory instead of an installer, which is the quicker option when you only want to check that packaging works.

npm run build:dir-only

Where the desktop wrapper gets in your way

The most concrete limitation is stated in the README itself: the executable does not autoupdate. If you ship a modified shell to a team, you own the distribution problem, because the built-in update paths cover the server and the UI but not the Electron layer. For a project whose whole value is convenience, that is a real gap, and it is acknowledged rather than hidden.

The second constraint is the repository boundary. Anything about interception behaviour is out of scope here by design, and the README redirects bugs, feature requests and feedback to github.com/httptoolkit/httptoolkit. Opening a shell issue for a proxy problem wastes a round trip. The third is licensing friction for anyone modifying and redistributing. The desktop source is AGPL-3.0, and the README describes a dual arrangement for the binary downloads: AGPL-3.0 for those who want to modify and redistribute within that license, or Creative Commons Attribution-NoDerivatives 4.0 for those who do not need those rights and want to avoid concerns about AGPL. NoDerivatives is the operative word. If your plan is to fork the shell, strip the branding and ship it, the second option does not cover you, and that is a licensing question for your own counsel rather than something this repository answers.

Finally, the shell is not the only way to run HTTP Toolkit, and the README says so: you can run the server as a standalone tool and open the UI hosted at app.httptoolkit.tech in any browser. If you only need the proxy, the Electron layer is overhead, not a feature.

Desktop app versus server plus browser, and the Pro question

The genuine alternative is the one the README names: run httptoolkit-server by itself and point a browser at the hosted UI. The difference is not cosmetic. With the desktop build you get one process to launch, the server lifecycle managed for you, and a packaged UI that does not depend on a remote page load. With the server-plus-browser route you get a plain CLI process you can run on a headless machine or inside a container, and you choose the browser. The trade-off is that you now manage the server yourself: start it, stop it, and keep it current, since the oclif auto-update behaviour described in the README is a property of the server, not of the shell.

The related searches around this project include HTTP Toolkit Pro and HTTP Toolkit free. Nothing in this repository's README or package.json describes a Pro tier, a pricing model or a paid feature set, so treat the desktop shell as a build target and check the product site for anything commercial. Similarly, searches for an APK or an iOS build have no answer here: the README lists Windows, Linux and Mac as the platforms this repository builds for.

Maintenance, releases and what an upgrade costs you

The repository is not archived and the last push was on 2026-09-10, which is recent. Releases are cut from tagged main builds on GitHub Actions and published as GitHub releases; the most recent listed are v1.27.1 on 2026-08-13, v1.27.0 on 2026-08-07 and v1.26.1 on 2026-06-10. The package.json version is 1.27.2, and config.httptoolkit-server-version is also 1.27.2, so the shell and the server it bundles are kept in lockstep at that point in the tree.

Upgrade cost for a contributor is mostly dependency churn in the Electron and Electron Builder stack, plus whatever the server setup script needs. The project pins its Node version through .nvmrc, and the build scripts assume the TypeScript toolchain (tsc, tsx, tsc-watch) is installed. There is a Playwright test target: npm test runs server:setup, then build:src, then playwright test, so end-to-end checks exercise the packaged shell rather than a mocked one. That is a heavier loop than unit tests, and it is the honest cost of working on a wrapper whose job is process orchestration. The AGPL-3.0-or-later license field in package.json is the one to check before you redistribute anything you build.

Editorial conclusion

Contributors who want to change the desktop shell, add an installer format or a target platform belong here; anyone who just wants to debug HTTP traffic should install a release binary or run httptoolkit-server and open app.httptoolkit.tech instead. Before changing anything, read CONTRIBUTING.md, check the config.httptoolkit-server-version pinned in package.json, and confirm whether your change belongs in the shell or in httptoolkit-server, because the README draws that line explicitly.

Frequently asked questions

Official sources

1. httptoolkit/httptoolkit-desktop on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases