Tailscale SSH on Mac: Three Variants, One Sandbox Error

I went looking for a blog topic in tailscale status and found a warning I had been scrolling past for three months:

Warning: client version "1.98.5-t295179bf2" != tailscaled server version "1.98.1-t2f4c02ee6-g0cd07359c"

Pulling on that line showed that this Mac mini runs three separate Tailscale installs at once, that the one I described in two earlier posts as "the Tailscale on this box" has been logged out since 10 June, and that the only reason SSH works here at all is macOS Remote Login. If you are trying to turn on Tailscale SSH on a Mac and getting an error about sandboxed GUI builds, the same three-way split is almost certainly what you are looking at. Tailscale documents it, but the CLI does not tell you which of the three it is talking to, and I had it wrong in print.

Three Tailscales on one Mac

ps aux on 11 September 2026 shows three processes with the name in them. Their file timestamps give the order they arrived, and I have no record of who ran the second and third; the repo, the commit log and the last 30 days of transcripts have no trace of the commands, so the timestamps are the whole story.

The fifteen minutes between the second and third rows read like someone installing the CLI, discovering it needed a daemon, and running sudo tailscaled install-system-daemon from the Tailscaled-on-macOS wiki page, which is exactly what that command does: copy the binary to /usr/local/bin, write the plist, start the job. The state file it created, /Library/Tailscale/tailscaled.state, has not been modified since that minute. Nobody ever ran tailscale up against it. It has been a root process with an open socket and no identity for 93 days.

Which one does the CLI talk to?

This is the part the warning hides. Two daemons are listening: the system extension on a random localhost port, and the open-source daemon on /var/run/tailscaled.socket. The Homebrew CLI has to pick one, and tailscale debug local-creds says which:

$ tailscale debug local-creds
curl -u:e511cd8aa073edc85029 http://localhost:49238/localapi/v0/status

$ tailscale --socket /var/run/tailscaled.socket status
Logged out.

The pick is not random. In client/local/local.go the default dialer first calls safesocket.LocalTCPPortAndToken(), and only if that fails does it fall back to the unix socket. On macOS that function reads a file named sameuserproof-<port> from /Library/Tailscale, which the GUI's extension writes on every start; the comment in safesocket_darwin.go spells out the three cases, "Mac App Store (macOS), standalone notarized (macsys), or a separate CLI (tailscale) that was built or downloaded." So whenever a GUI variant is installed, a downloaded or brewed CLI will address the GUI, and the open-source daemon is reachable only by naming its socket. The version warning is the one visible symptom: the CLI is 1.98.5, the extension it reached is 1.98.1, and cli.go prints the mismatch once per invocation. It is a real mismatch, not the short-versus-long build string false positive tracked in issue #19708.

Why the GUI cannot be an SSH server

None of this would matter if all three variants could do the same things. They cannot, and the difference that sends people searching is the SSH server. Tailscale's own macOS variants page has a comparison table; the rows that decide a headless Mac are these, copied on 11 September 2026:

The Tailscale SSH page says the same thing in one sentence: the server component is available on Linux and on "macOS open source tailscale + tailscaled CLI devices," nothing else. The error people hit on a GUI install is The Tailscale SSH server does not run in sandboxed Tailscale GUI builds. The explanation, from a Tailscale contributor in January 2025 on issue #4518, is that the network extension runs as root but inside Apple's sandbox, so it cannot open a terminal as your user; doing it properly would mean shipping a separate LaunchDaemon, XPC between it and the extension, and a root-escalation UI, and the App Store variant can never have it under the store's rules. That issue is a good measure of how many people walk into this. Opened 25 April 2022, still open, 43 comments from 31 accounts through 4 June 2026, and the year with the most comments is 2025 with 13, not 2022. Of the 43, twelve quote the sandboxed error, eleven mention the Homebrew route, and eight land on the same workaround I am on: turn on macOS Remote Login and use plain ssh across the tailnet. Three of the sandboxed-error reports are from May 2026 on Standalone 1.96.5, and one of them had already enabled Remote Login and got the error anyway, which is the tell: Remote Login is a different door, it does not make the Tailscale door open.

The open-source route has its own traps

The daemon that can be an SSH server is the one nobody recommends for a desktop. The variants page says tailscaled on macOS "is only recommended for unattended installs managed by experienced macOS system administrators." Three things from the record:

• Issue #18957, closed March 2026: the Homebrew build advertised SSH, prefs showed RunSSH: true, and connections hung anyway. The cause was an SSH policy with "action": "check", which had started requiring hardware attestation that the open-source Mac build does not have, so the control server never delivered the policy at all. The fix was changing the ACL action, not the client.
• MagicDNS: the wiki says "you need to set 100.100.100.100 as your DNS server yourself," and a December 2025 comment on #4518 frames the choice as GUI with names but no SSH server, versus Homebrew with an SSH server but no names. A patch for the Homebrew DNS gap was proposed in February 2026 and was still an unofficial branch in June.
• Path shadowing: brew info tailscale on this box warns that tailscaled is "shadowed by /usr/local/bin/tailscaled." The Homebrew formula and the wiki's install-system-daemon put daemons in two different places, and running one by name gets you whichever is first in $PATH.

And the thing the variants page warns about, running the App Store and Standalone builds together, is not the combination I have. Standalone plus open-source is not mentioned. Nothing objected when the second daemon was installed, and the CLI quietly preferred the GUI from then on.

What I got wrong in print

Two of my posts describe this machine's Tailscale as a LaunchDaemon. In the FileVault lockout postmortem I wrote that "Tailscale on this box is the standalone build, a LaunchDaemon at /Library/LaunchDaemons/com.tailscale.tailscaled.plist." In the server setup guide I wrote that the same plist was "serving three nodes." Both sentences took the only non-Apple plist in that folder as the thing answering on the tailnet. It is not. The plist is the logged-out open-source daemon; the tailnet address is served by the system extension, which is registered with launchd as a network extension, not as a LaunchDaemon. I have added a correction to both posts. The distinction between the two kinds of launchd job is one I had already written about in LaunchAgent versus LaunchDaemon, and I still misread it when the folder had one plist in it.

The correction also changes a claim about recovery. The variants table says the Standalone build does not run before login, and the wiki says the open-source daemon does, "letting you VNC to your computer after a power outage." My recovery timeline from September had the console login at 17:35 and Tailscale sessions at 17:43, which matches a build that waits for a user. Had the June daemon been logged in, the sequence after a FileVault unlock might have looked different. I am not testing that on the machine I am typing through.

What actually carries SSH here

Remote Login is on, nc -z 127.0.0.1 22 succeeds, and Screen Sharing on port 5900 is off. Every session into this box is OpenSSH over the WireGuard tunnel the extension maintains, the pattern the monitor-less setup relies on. Path quality is fine for that: tailscale ping to the MacBook Pro on the same LAN answers in 13 ms direct via 192.168.20.116:41641, and tailscale netcheck puts the nearest relay in Tokyo at 38.5 ms, so a relayed session would cost about 25 ms more. What the tailnet gives me is the address and the key exchange; what answers on it is Apple's sshd. Tailscale SSH, the feature, has never run on this machine.

Two loose ends stay loose on purpose. The idle daemon should go, and sudo tailscaled uninstall-system-daemon is the one-line way to do it, but the rule for this machine is that nothing touching remote access changes without the owner watching, and that includes a root daemon that currently does nothing. The app is also stuck on 1.98.1 while Homebrew lists 1.102.3 as current: the bundle enables Sparkle's automatic checks, the last check ran on 4 September, and no key turns automatic install on, so the update presumably sits in a dialog on a display nobody looks at. I have not seen that dialog, because there is no monitor, which is the same reason the KVM question keeps coming back.

If the client is not a Mac at all, the remote access Mac mini comparison lists which of eleven routes work from Windows, iPad and Linux, and why a plain VNC viewer is refused by this machine.

Sources and method: the three-install inventory, timestamps, prefs, socket paths, debug local-creds output, ping and netcheck figures were read on this Mac mini on 11 September 2026 under macOS 26.4.1 with the Homebrew CLI 1.98.5 and Standalone app 1.98.1; the research note keeps the raw output. No setting was changed and tailscale set --ssh was not run here, so the sandboxed-build error text is quoted from the May 2026 comments on issue #4518 rather than reproduced. Source references are to the main branch of tailscale/tailscale on the same day. The 43-comment tally is a keyword count over the full comment list from the GitHub API, one issue, not a survey of every Tailscale forum. The comparison rows are copied from Tailscale's macOS variants page as published that day and can change with a release.