Pandora-Box is an Electron front end for the Mihomo proxy core

A GUI wrapped around a core it does not contain

Pandora-Box is a lightweight, user-friendly cross-platform client for Mihomo, supporting multiple proxy protocols, automatic rule grouping and TUN mode, and it is designed for both casual and advanced users to easily manage and convert proxy subscriptions.

The important thing to understand from the start is the division. Pandora-Box is not a proxy implementation. Mihomo is the engine, hosted at github.com/MetaCubeX/mihomo, and this project is the interface around it. The repository topics list the protocol names the client is expected to handle, with anytls, clash, clash-meta, hy2, hysteria, shadowsocks, v2ray and vless, and also sub2clash, which is the subscription conversion side.

The build instructions make the structure explicit, because there are two codebases in the repository. The build has a Go step that produces a binary called px, described as the px backend, and the Go source lives in a src-go directory. The frontend is a separate build that produces the desktop app. The Go module path in the linker flags is github.com/snakem982/pandora-box/api, so the Go side is an API server that the UI talks to.

So the architecture is an Electron shell, a Vue renderer, and a Go process that embeds Mihomo and exposes it over an API. The TUN mode feature, which needs to create a network interface and route traffic, is a privileged operation, and having it run in a separate backend process rather than in the renderer is the reason the split exists.

The project is GPL-3.0 licensed, the default branch is v3, and the last push was on 2026-10-15.

Building it needs Node, Go and a CGO-free binary

The build instructions are short and complete.

The prerequisites are Node.js 18 or newer for building UI components or tooling, and Go 1.24 or newer for integration with Mihomo or backend modules. The sequence is:

# Install dependencies
npm install
cd src-go
go mod tidy

# Build px backend
CGO_ENABLED=0 go build -tags=with_gvisor -trimpath -ldflags "-X github.com/snakem982/pandora-box/api.Version=v-test" -o px(.exe)
cd ..

# Build desktop app
npm run package

# Run in dev mode
npm run start

Three details in that are worth pulling out. CGO_ENABLED=0 produces a static binary with no libc dependency, which is what lets one build run on every platform. The with_gvisor build tag enables the gVisor network stack inside the core, which matters for the transparent proxying that TUN mode depends on. And the -ldflags sets a Version variable through the api package path, so the backend can report which build it is.

The npm scripts show the Electron Forge workflow, with dev running vite, start running electron-forge start, package running electron-forge package, make producing the distributables and publish uploading them. The main entry point is .vite/build/main.js, and the build is configured by three Vite configs, vite.config.ts for the renderer, vite.main.config.ts for the main process and vite.preload.config.ts for the preload script. The forge.config.ts file holds the Electron Forge configuration.

The makers in devDependencies tell you which targets are built, with maker-deb, maker-dmg, maker-rpm, maker-wix and maker-zip, so Linux, macOS and Windows are all first class rather than one being an afterthought.

Three languages, one process tree

The repository layout is the clearest description of the design, and it has a distinct Electron shape.

There is src/ for the Vue renderer, src-electron/ for the Electron main and preload code, and src-go/ for the Go backend. Then build/ for the application icon and packaging assets, public/ for static files, doc/ for the documentation in three languages, and index.html at the root as the renderer entry point. The TypeScript configuration is a single tsconfig.json, and the ESLint configuration is .eslintrc.json.

The framework stack is Vue with Element Plus. The devDependencies include @vitejs/plugin-vue, eslint-plugin-vue with the vue parser and typescript-eslint, plus unplugin-auto-import, unplugin-icons and unplugin-vue-components, which is the modern Vue tooling set for auto-importing components and icons. The icon packages are @iconify-json/ep and @iconify-json/mdi, so the icon set is an iconify collection, and @element-plus/icons-vue is in the runtime dependencies alongside the Element Plus component library itself.

The internationalisation stack is in the runtime dependencies too, with @intlify packages, which is the Vue I18n family. That matches the documentation structure, with README.md at the root in three languages and doc/README.zh-CN.md, doc/README.en.md and doc/README.ru.md. A client for this kind of tool is used in regions where the language matters, and shipping three translations of the docs is a reasonable signal of where the audience is.

Electron itself is at 41, and the fuses plugin is present along with @electron/fuses, which is the mechanism for disabling Electron's own features such as the node integration in the renderer, a hardening step that a client handling proxy credentials has reason to take.

Releases move quickly and the numbering is unusual

The release history is worth reading carefully, because the version numbers do not line up with the package version in a way you would expect.

The releases are v1.0.23 from 2026-08-22, v1.0.24-pre2 from 2026-10-10 and v1.0.24-pre3 from 2026-10-15. The default branch is v3, which is a different scheme again, and the package.json in the repository says version 1.1.0. So there are three version numbers in play, the tag, the branch, and the manifest, and the tag is the one a user downloads.

The pre suffix is the important part. The two most recent releases are pre-releases, which means the current published build is a candidate rather than a settled release, and the last stable one is v1.0.23 from August. For a client that manages your network stack, that distinction is worth respecting, and it is also why the README points at the releases page rather than offering a stable channel.

The pre-release cadence is fast, two in five days for the same version, and the push to the repository was on the same day as the v1.0.24-pre3 tag, so the pre-releases are being cut from the tip as work lands rather than from a curated branch.

For a user, the practical advice is to decide which channel you want. A pre-release gets you the current work and the current bugs, a stable tag gets you a build that has been out for a while, and there is no nightly or beta channel named separately in the release list.

Where Pandora-Box is the wrong choice

The first limit is that it depends on something else entirely. The client is a front end for Mihomo, so if you want a proxy core you still need Mihomo, and the pairing is the thing to get right. The protocol list in the topics covers a wide range, and the client and the core have to agree on which of them are actually enabled.

The second is that this is a GUI with a process tree behind it. An Electron application plus a Go backend process is a lot of moving parts for something that fundamentally has to route packets, and TUN mode in particular needs elevated privileges to create a network interface. The README does not describe the permission model, the service installation, or how the backend is kept running across reboots, so the operational questions are the ones you will have to answer yourself.

The third is the stability of the current channel. The most recent published builds are pre-releases, the manifest version and the tag version disagree, and the default branch is named v3 while the tags are on a 1.0 line. A project with three version schemes in play is a project where you should know which commit you are running.

The fourth is the scope. The described features are subscription conversion, automatic rule grouping and TUN mode, plus protocol support. Anything beyond that, custom routing logic, per-domain policy scripting, traffic analysis, is not what this project is for.

The fifth is worth stating plainly because it applies to the whole category. A proxy client is only as legitimate as the traffic you put through it, and the tools in this space are used both for accessing services that are blocked and for routing around corporate networks on a laptop you are authorised to configure. That is not a criticism of this project's quality, but it is the reason to use the tool only within the boundaries of your own network and your own service agreements, and the reason a GPL project with a public issue tracker is the shape you want for something that touches your system network configuration.

Editorial conclusion

Pandora-Box suits someone who already uses Mihomo and wants a graphical way to manage subscriptions, rules and the TUN mode instead of editing YAML by hand, and it is the wrong tool if you want a lightweight command line setup or a proxy core of its own, since it ships no core and depends entirely on Mihomo. Before installing, check that the Mihomo build you pair it with matches the protocol set it advertises, and note the release naming, since the current 1.0.24 pre-releases are published as pre tags rather than as stable versions.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. snakem982/Pandora-Box on GitHub