Give Claude Code Its Own Mac: A Practical Guide to Isolated Agent Delegation
If you’ve used --dangerously-skip-permissions in Claude Code, you already know the tradeoff: the agent stops asking before every Bash or Edit call, and it gets a lot faster — right up until it does something you didn’t want, on the machine that also holds your browser sessions, SSH keys, and personal files. ykdojo’s guide takes the obvious but rarely-executed fix and writes down every step: give Claude a machine with nothing to lose.
The idea connects to a point we made in our post on human-in-the-loop fatigue — the fix for supervision burnout is moving the checkpoint from individual actions to a boundary around the whole task. A dedicated machine is that boundary taken to its logical extreme: instead of a git branch or a sandbox container, it’s an entire computer the agent can’t escape from.
The core setup: SSH and passwordless sudo
The bones of it are a spare Mac wiped clean, with SSH enabled (sudo systemsetup -setremotelogin on) and passwordless sudo configured via a /etc/sudoers.d entry — verified with visudo -cf before you trust it, since a typo there can lock you out of sudo entirely. You connect from your main Mac over key-based SSH to the target’s local hostname (scutil --get LocalHostName), which is more stable across reboots than its DHCP-assigned IP.
Two details matter more than they look:
- Don’t sign into an Apple ID on the target. No iCloud, no synced data, no accidental bleed-through from your main identity.
- Use a separate GitHub account for the target’s
gh auth loginand Claude login, not your primary one — so a runaway agent action can’t touch your real repos or org permissions.
From there, installing Claude Code is one SSH one-liner, and a pmset call keeps the target from sleeping so it’s reachable whenever you need it.
Computer use: the part that actually needs a workaround
Shell access alone covers a lot, but the guide’s more interesting contribution is getting computer use — screenshots plus mouse/keyboard control — working over SSH at all. macOS gates Screen Recording and Accessibility permissions to the GUI session, and an SSH process isn’t part of one. The fix is a LaunchAgent that keeps a tmux server alive inside the actual logged-in session; SSH-based Claude sessions attach to that tmux server and inherit its access to the display.
Two of the permission grants can’t be scripted — macOS requires an in-person click on the target for Screen Recording and Accessibility — so budget five minutes at the machine the first time you set this up. After that, everything (ic for a new session, ic vnc for Screen Sharing, ic rc for phone-based Remote Control) runs from your main Mac or your phone.
One rough edge worth knowing about before you hit it: Terminal.app can’t receive the OSC52 clipboard escape sequences Claude emits, so selecting and copying a snippet from the remote session often won’t land in your local clipboard. Cmd-A then Cmd-C to grab the whole visible screen is the documented workaround — not elegant, but it’s a five-second habit once you know it’s needed.
Reaching it from anywhere
For access outside your home network, the guide uses Tailscale to build a peer-to-peer WireGuard tunnel between your phone or laptop and the target Mac — no port forwarding, no public IP exposure. With MagicDNS on, you can drop the .local suffix and reach the machine by bare hostname from anywhere Tailscale is running. It’s worth turning on device approval in the Tailscale admin console and disabling key expiry on the target, so it doesn’t silently drop off the network after its ~180-day key rotation.
What this setup actually costs you
| Layer | Requirement |
|---|---|
| SSH + shell control | Free — just the spare Mac |
| Computer use (screenshots, mouse/keyboard) | Claude Pro or Max subscription |
| Claude in Chrome (browser automation) | Direct Anthropic plan: Pro, Max, Team, or Enterprise |
| Remote access from any network | Tailscale, free tier is enough for personal use |
Where to stop
Not every step in the guide is worth doing on day one. If you mainly want a safe place to run --dangerously-skip-permissions sessions unattended, the SSH and passwordless-sudo setup alone gets you there — that’s the whole risk boundary. Computer use, Screen Sharing, and Chrome automation are additive layers for when the agent needs to drive a GUI app, not prerequisites for the core benefit. Add them when a specific task needs them, not because the guide lists them.
The one tradeoff worth sitting with: passwordless sudo plus --dangerously-skip-permissions is a genuinely elevated permission level, and it’s only a reasonable one because the machine has nothing on it worth protecting. That constraint is the entire safety model — if you ever put personal data or production credentials on the target Mac “just this once,” you’ve quietly rebuilt the exact risk this setup exists to avoid.
Source: “Setting up your spare Mac for Claude Code to control” by ykdojo, discussed on Hacker News.