ClashBar Review: A Native macOS Front End for mihomo

Why ClashBar Places mihomo Behind a Menu Bar

ClashBar addresses a specific gap between command-line proxy cores and larger desktop proxy clients. It keeps the operational surface inside the macOS menu bar, where users can import or update configurations, select nodes, test latency, inspect rules and connections, and manage the macOS system proxy. Its target user is someone running mihomo on a Mac who does not want to keep a conventional application window open for routine network controls.

The interface is built with SwiftUI and AppKit, while mihomo supplies the proxy core. That division matters. ClashBar does not present itself as a replacement proxy engine. Its role is to control configuration and runtime state around mihomo, then expose that state through a native macOS client. The documented pages include Proxy, Rules, Connections, Logs, and System.

The System page handles more than visual preferences. It includes language, menu bar behavior, ports, `allow-lan`, and `ipv6`. Proxy contains the controls users need most often, including configuration, operating mode, system proxy state, nodes, latency, and providers. Rules provides rule statistics and filtering, Connections permits filtering and closing active connections, and Logs supports level and keyword filters. This design reduces the distance between a user action and the proxy setting it changes, although it does not remove the need to understand mihomo configuration files.

How ClashBar Connects Configuration, mihomo, and macOS Proxy State

ClashBar stores runtime data under `~/Library/Application Support/clashbar`. When a release includes mihomo, the application copies the bundled core into `~/Library/Application Support/clashbar/core/mihomo`. This separation keeps the application package distinct from mutable runtime files and gives the core a stable location that ClashBar can manage after installation.

The configuration flow begins in the Proxy page. A user selects an existing profile or imports one, starts or restarts the core, and chooses `Rule`, `Global`, or `Direct`. Nodes can then be selected and tested. The README presents an explicit order: confirm that a node is usable before enabling the system proxy. That sequence reduces accidental activation of an unavailable route, but it still depends on the imported configuration and the selected mihomo behavior.

System proxy integration is implemented through a helper installed into a system directory. macOS asks for an administrator password when system proxy control is enabled for the first time. The README says the helper remains installed after the application is updated, avoiding the need to recreate it for every app upgrade. Login-item permission is separate. ClashBar can be configured to start at login, but macOS may require the user to allow the helper in Login Items.

Only one mihomo or Clash client should own the system proxy at a time. Running two clients with competing proxy settings can make the active route ambiguous and complicate diagnosis. Connections and filtered logs are therefore not decorative monitoring features. They are the documented tools for determining what the current core is doing after mode, node, or system proxy changes.

Installing ClashBar and Completing the First Proxy Setup

ClashBar requires macOS 13 or later. The README documents Homebrew Cask installation as the primary command path. This installs the cask, but it does not create a proxy configuration or confirm that macOS has granted the necessary helper permissions.

The documented installation command is:

brew tap Sitoi/tap
brew install --cask clashbar

After installation, the documented first-use sequence is performed in the application. Click the menu bar icon to open the panel. In Proxy, select or import a configuration. Use `Start` or `Restart` to launch the core, then select `Rule`, `Global`, or `Direct`. Switch to a node, run its latency test, and enable the system proxy only after confirming that the node works.

Users who prefer a disk image can download a `.dmg` from the GitHub Releases page and drag `ClashBar.app` into `/Applications`. This location is not cosmetic. The README says system proxy support depends on the packaged `.app`, so running it from a temporary Downloads or archive location may prevent the expected integration.

The first system proxy activation prompts for an administrator password and installs the helper in a system directory. macOS may separately require ClashBar's helper to be allowed under Login Items. The documented removal commands distinguish an ordinary uninstall from a complete removal that also clears data:

brew uninstall --cask clashbar
brew uninstall --zap --cask clashbar

Use the first command for normal cask removal and the `--zap` form when the associated data should also be removed.

Building ClashBar with SwiftPM and an Optional Embedded Core

The repository uses a Makefile around SwiftPM build scripts. Its stated development requirements are Xcode or Swift 6.2 or later, and macOS 13 or later. A default build produces `dist/ClashBar.app` without mihomo included. That default makes the no-core package smaller according to the README, but it also means the resulting application is not self-contained with respect to the proxy engine.

The documented build commands are:

make build
make build WITH_CORE=1
make dist WITH_CORE=1

`make build` invokes the repository's app packaging script with `PREPARE_MIHOMO_BINARY=0`, `BUNDLE_MIHOMO_BINARY=0`, and `REQUIRE_MIHOMO_BINARY=0`. Setting `WITH_CORE=1` passes `1` to those variables, preparing, bundling, and requiring mihomo. `make dist WITH_CORE=1` creates the app and disk image package.

The Makefile also exposes `TARGET_ARCH`, `APP_VERSION`, `BUILD_NUMBER`, `RELEASE_OPTIMIZE_FOR_SIZE`, and `STRIP_BINARIES`. Those controls affect architecture selection, application metadata, optimization, and packaged binaries. The README does not document automated release signing, notarization, entitlement changes, or a rollback procedure, so source builders should not assume those release operations are covered by the listed targets.

Operational Limits of the macOS Menu Bar Model

ClashBar is restricted to macOS 13 and later. The repository and documented installation paths provide no Windows, Linux, or mobile packages. It is therefore the wrong choice for users who need one proxy interface across several operating systems.

System proxy control has several environmental dependencies. The application must be packaged in `/Applications`, the first activation needs administrator authorization, and macOS may ask for Login Items approval. The helper is intended to survive application updates, but a malformed toggle can still require turning the setting off and on again or restarting the core. These are operational boundaries imposed by macOS integration, not optional setup details.

The no-core build makes another assumption. Because the default output does not include mihomo, the core still has to be available and compatible with the control process. The `WITH_CORE=1` path packages the engine and places it in the documented runtime directory, but the README does not describe automatic recovery when the core is missing, fails validation, or becomes incompatible after a manual update.

Configuration quality also remains a user responsibility. The application can filter rules, update providers, display logs, and close connections, but the README does not state that it repairs malformed subscriptions or validates every remote provider before use. Latency testing is evidence about one measurement at one time, not proof that every destination will remain reachable. For policy-heavy users, the rule and log views are useful, but migrating expertise from another mihomo interface still depends on understanding the underlying configuration.

ClashBar Compared with Running mihomo Separately

The closest documented alternative is to run mihomo as a separate core rather than place the full ClashBar interface between the user and that core. This is not an unrelated product comparison. The README explicitly warns that another mihomo or Clash client may take over the system proxy, which confirms that users can operate in a multi-client environment.

Direct mihomo operation separates the engine from the desktop control layer. That can suit users who already manage YAML configuration and process lifecycle through scripts or another established interface. The trade-off is that the ClashBar documentation cannot be used to promise matching menu bar node controls, connection filtering, log search, Login Items handling, or administrator helper installation. A direct setup may also require the user to arrange process startup and macOS proxy changes separately.

ClashBar instead packages that operational layer in a native interface and integrates with macOS system proxy and login startup. The README also lists ClashMac.app, Clash Verge.app, and Clash Party.app in a size comparison, with ClashBar.app without a core shown as 3 MB. Those are Finder display values and the README labels them as reference figures, so they should not be treated as independent benchmarks. They explain why ClashBar emphasizes its no-core build, but they do not establish a complete feature comparison with those clients.

Maintenance Signals, GPL-3.0, and Upgrade Work

The repository is not archived. Its last push was on 2026-10-13, and the listed releases include v0.3.6 on 2026-09-30, v0.3.5 on 2026-09-30, and v0.3.4 on 2026-09-23. Those dates show recent repository and release activity, but they do not by themselves establish how long system compatibility will remain stable.

ClashBar is licensed under GPL-3.0. For adopters who distribute the application or create and distribute modified versions, the relevant point is to review GPL-3.0 source-availability, notice, and license obligations before packaging it. This is not legal advice. If a build bundles mihomo, the README does not state the core's exact license or provide a third-party notices file, so that packaging needs separate license review rather than an assumption based only on ClashBar's identifier.

The normal application upgrade path depends on how it was installed. Homebrew users can update through their cask workflow, while disk-image users can replace the app manually. The helper is documented as remaining installed across app updates, but the user may still need to allow Login Items after a new macOS release. Runtime files live under Application Support, and the no-core and embedded-core layouts differ. Users who maintain custom builds should account for changes to `Package.swift`, the `Sources/` tree, `Scripts/`, and the `Makefile` rather than treating ClashBar as a configuration-only app.

Editorial conclusion

Adopt ClashBar if you want a macOS-native menu bar interface for mihomo and are comfortable managing configurations and system integration on macOS 13 or later. Do not choose it if you need a documented cross-platform client or automatic VPN-style system-wide tunnel control. Verify first that your configuration works with the selected mihomo build, only one proxy client owns the system proxy, and ClashBar is installed in `/Applications`.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. Sitoi/ClashBar on GitHub