Running PAIR in a macOS standard (non-admin) account

[guynich]

I wanted PAIR confined to a sandboxed standard account rather than running
alongside my personal admin session. It works, with one caveat: getting there
needs a one-time admin step, after which PAIR itself runs entirely unprivileged.

Tested on MacBook Pro (M5 Pro) macOS 26.6.2. and MacBook Pro (Intel, 2020) macOS 15.8,
PAIR 0.1.1 from the .dmg.

Setup:

1. Download the PAIR .dmg.
2. Drag the app to ~/Applications in the standard account — not /Applications.
3. On first launch, I approved with admin rights - in retrospect I should have declined to skip Step 6.
4. Settings → Login Items & Extensions → Allow in the Background: toggle PAIR on.
5. Settings → Privacy & Security → Local Network: toggle PAIR on.
6. From an admin account, unload and remove the privileged helper:

To workaround Step 3.

sudo launchctl bootout system/com.nvidia.nvpair.helper
sudo rm /Library/LaunchDaemons/com.nvidia.nvpair.helper.plist
sudo rm /Library/PrivilegedHelperTools/com.nvidia.nvpair.helper

7. The helper is what opens PAIR's firewall ports, so if the macOS firewall is on,
   add PAIR manually under Settings → Network → Firewall → Options to allow incoming connections.
8. Reboot.

Verify nothing is running as root:

ps aux | grep -E "nvpair|PAIR" | grep -v grep

All listed processes should be owned by the standard user.

What I confirmed working afterwards: node discovery. pairing and chat completion
through the proxy at 11434.

Two things worth knowing:

Uninstall. The shipped uninstaller hardcodes /Applications/PAIR.app, so it
won't find an install under ~/Applications. Point it at the real path (not
tested), or clean up by hand.

VS Code port collisions. On the Intel Mac setup I saw VS Code auto-forward
PAIR's ports out from under it — 11434 (Ollama-compatible proxy), also 11435 and
14321. My fix in VS Code settings.json:

"remote.portsAttributes": {
  "11434": { "onAutoForward": "ignore" },
  "11435": { "onAutoForward": "ignore" },
  "14321": { "onAutoForward": "ignore" }
}

"remote.autoForwardPorts": false works too if you don't want forwarding at all
(not tested).

Question for the maintainers: is unprivileged operation intended to be supported,
or does removing the helper leave something silently degraded that I haven't
exercised yet? If it's supportable, a documented non-admin install path would be
useful for anyone sandboxing PAIR.

[sherief-nv]

unprivileged operation would be nice to have, but the manual opening of firewall ports takes away a lot from the core value of the product. I'm not sure how to reconcile these two, especially as more inference engine backends get added. What do you think?

[guynich]

Thanks for the fair point. Requiring user configuration of manual firewall rules per port, per backend, does challenge "it just works" goal. I only tried one backend above so didn't hit any issue.

I think unprivileged operation and no manual firewall step aren't inherently at odds unless the concept is root daemon or nothing. Asking the user for temporary root privileges during the install is reasonable, but installing a root process seems unnecessary.

I think there are other (untested) possibilities:

1. Make the privilege escalation one-time, not persistent.

Right now the helper looks like it runs continuously as a LaunchDaemon. If the firewall rule were instead set via a one-shot style prompt at install/first-run (such as "PAIR wants to make changes" dialog) you'd keep zero-config for the user without needing a permanently root-capable process. When a new back-end is added the one-shot prompt can appear again.

2. Sidestep the firewall rules with a NetworkExtension

Since PAIR already asks for local-network entitlements, a network extension could accept local connections without raw pf rules. New backends wouldn't add a new firewall surface at all, just new services behind the same extension.