For fleet rollouts (JAMF, Intune, Mosyle, Kandji, Workspace ONE), HiveMind ships as a signed, notarized macOS .pkg. It’s a single file you push as a payload, with no interactive installer and no per-machine setup. This page walks through JAMF. The same .pkg works in any MDM that can deploy a package.
Get the package
Download hivemind-darwin-arm64.pkg from the latest release. The package is signed and notarized by Weights and Biases, Inc. (Team ID 5DTHBP38WM), so Gatekeeper accepts it on any managed Mac.
It installs to a system location and registers a per-user background service:
| Path | What it is |
|---|
/usr/local/hivemind/bin/hivemind | The daemon binary |
/Library/LaunchAgents/com.wandb.hivemind.plist | LaunchAgent that runs the daemon |
/etc/paths.d/hivemind | Puts the binary on PATH |
/usr/local/hivemind/uninstall.sh | Bundled uninstaller |
/Library/LaunchAgents/ (not a user’s home folder), the install works unattended and the daemon starts at the next login for any user on the machine, with no login script or policy trigger needed.
Deploy with JAMF
- Upload the package. In JAMF Pro, go to Settings > Computer Management > Packages and add
hivemind-darwin-arm64.pkg.
- Create a policy. Under Computers > Policies, create a new policy with the Packages payload and add the HiveMind package with action Install.
- Set a trigger. Recurring Check-in (or Enrollment Complete for new devices) installs it across the fleet without user interaction.
- Scope it. Target the smart or static computer group you want to cover, then save.
That’s the whole rollout. On a machine where a user is already logged in, the daemon starts immediately. Otherwise it starts at their next login.
Auto-upgrade is on by default
Once installed via the package, the daemon keeps itself up to date. It checks for new releases on a timer and, when one is available, verifies the download’s signature and Team ID before swapping the binary in place and restarting itself. You don’t need to re-push the package for upgrades. Deploy once and devices stay current.
In-place upgrades need the daemon’s user to be able to write the install dir. When a user is logged in at install time the installer assigns it to them. An unattended push (nobody logged in) instead makes the dir admin-group-writable, so the primary user on a managed Mac, typically a local admin, still auto-upgrades with no further action. Only when the daemon runs as a non-admin user does it need a hand: hivemind doctor flags it and hivemind doctor --fix grants access. You can also skip auto-upgrade and manage versions by re-pushing the .pkg.
hivemind config set daemon.auto_upgrade off
| Value | Behavior |
|---|
apply | Download and install upgrades automatically (default for the package) |
notify | Log that an upgrade is available, but don’t install |
off | Never check for upgrades |
Suppress the background-item notification
On macOS 13 and later, the first time the daemon’s LaunchAgent loads, the user sees a “Background items added” notification. To pre-approve HiveMind across the fleet so this never appears, push a Service Management - Managed Login Items configuration profile that trusts the vendor.
In JAMF, create a configuration profile with the Service Management - Managed Login Items payload and add a rule of one of these types:
| Rule type | Value | Notes |
|---|
| Team Identifier | 5DTHBP38WM | Trusts everything signed by Weights and Biases, most stable |
| Label | com.wandb.hivemind | Pins to this specific background service |
Authentication
The daemon authenticates each user against GitHub, trying silent methods first (SSH key signature, git credential helper, gh CLI) and falling back to a browser login only when none is available. On a typical developer Mac with GitHub already set up, no action is needed. For headless or shared machines, see Bots & service accounts for token-based auth.
Uninstall
The package bundles an uninstaller. Push it as a JAMF policy with a Files and Processes > Execute Command payload, or run it directly:
sudo /usr/local/hivemind/uninstall.sh
~/.hivemind/. To remove that too:
Verify a rollout
On a sample device after the push:
# Binary present
ls -l /usr/local/hivemind/bin/hivemind
# LaunchAgent registered for the logged-in user
launchctl print "gui/$(id -u)/com.wandb.hivemind" | head -5
# Full health check
hivemind doctor
launchctl print step reports “Could not find service,” the user hasn’t logged in since install yet. Wait for their next login, or run hivemind doctor for a fuller diagnosis. hivemind doctor also confirms auto-upgrade can write the install dir. If it can’t (a non-admin user on an unattended install), hivemind doctor --fix repairs it. 
