Hot take: most people cheering the viral claude-controls-mac guide don’t actually need it. If you’re running Claude Code on your daily driver and it’s been fine, a spare-Mac rig won’t magically make you 10x more productive. What it will do is let you flip on the --dangerously-skip-permissions flag without lying awake wondering whether your ~/.ssh folder is still intact.
That’s the honest pitch. And it’s why the guide by ykdojo hit ~80 points on Hacker News when it surfaced – it turns a scary flag into a shrug.
Why containers and cloud VMs fall short for Claude Code on Mac
The obvious counter is “just run it in Docker.” I tried that path. So did the author of the viral guide. Containers work up to a point – but they still run on your main machine, which means network requests the agent sends still go through your main machine, and there are real limitations on what the container can do. If you want the agent to open a real macOS app – Xcode, Unity, a browser with your actual login profiles – a Linux container isn’t going to get you there.
Cloud VMs solve the isolation part but introduce a different tax: latency, egress fees, and a machine that can’t touch iCloud, iMessage, or anything else tied to your Apple ID. A spare Mac sits in a weird sweet spot – physically isolated, native to macOS, and free if you already own one gathering dust. Whether that calculus works for you depends entirely on whether you have the hardware already.
The setup, reframed as four decisions (not sixteen steps)
Every tutorial on this topic gives you the same numbered march: create account, enable SSH, install tmux, add Tailscale. That’s fine, but it hides the decisions that actually matter. Here are the four you need to make before you touch a keyboard.
Decision 1: Which user account model?
The guide’s default: a fresh local account with no personal data and no Apple ID signed in, so the agent has nothing sensitive to reach. That’s the safest option. One commenter on the Hacker News thread went further – useradd agent and su agent, so Claude can blow up its own files but not yours. Either works. What you should not do is reuse your daily account “just for testing.”
Decision 2: SSH-only, or Claude mobile app too?
SSH from your main Mac is the boring, reliable path. If you want to trigger tasks from your phone at the coffee shop, you’ll want Claude Code Remote Control on top. The catch: --dangerously-skip-permissions has no effect inside Remote Control sessions. Even if you pass it at startup, every tool call still requires manual approval from your phone. The DataCamp tutorial on Remote Control makes this explicit – the phone workflow is “babysit from anywhere,” not “fire and forget.”
Decision 3: Pro plan or Max plan?
As of writing, the ykdojo setup requires a Claude Pro or Max subscription – the free tier won’t cut it. Pro is enough for a single-session rig. Run parallel agents on the same box and you’ll hit usage caps faster than expected.
Decision 4: Local network only, or Tailscale?
Same Wi-Fi is simplest. Tailscale (or another mesh VPN) is what you want if you’ll be away from home and don’t want to open ports on your router. The guide covers both paths.
The actual setup: a beginner walkthrough
Assuming both Macs are on the same Wi-Fi and you’ve made the four decisions above, this is the minimum viable path.
- On the spare Mac: System Settings → Users & Groups → add a new Standard user (no Apple ID). Log in as that user once so the home folder gets created.
- Enable Remote Login: System Settings → General → Sharing → toggle on Remote Login. Note the hostname (
<user>@<target-host>.local). - Install Homebrew and tmux on the spare Mac:
brew install tmux. Then install Claude Code via npm. - Log into Claude Code once from the spare Mac’s Terminal so the auth token is saved.
- From your main Mac, run the guide’s setup script over SSH:
ssh -t <user>@<target-host>.local 'curl -fsSL https://raw.githubusercontent.com/ykdojo/claude-controls-mac/main/setup-computer-use.sh -o setup-computer-use.sh && bash setup-computer-use.sh'This installs the LaunchAgent (a persistent tmux server) and enables the built-in computer-use tool.
- Grant Screen Recording and Accessibility permissions in System Settings on the spare Mac. Don’t skip this – the next section explains exactly why it matters.
That’s the happy path. Now for the parts nobody warns you about.
The LaunchAgent+tmux hack: what it’s actually doing (and why)
This is the piece that’s glossed over in every walkthrough, and it’s the most important thing to understand. macOS gates screen capture and keyboard input behind Screen Recording and Accessibility permissions – and those permissions are tied to the GUI login session, not to any shell process. An SSH connection is a separate context entirely. Start Claude Code from that SSH shell and the agent literally cannot see or click anything on the desktop.
Translation: the permissions Apple granted are locked to the desktop session you see on screen. Your SSH shell is a stranger at the door.
The workaround is a LaunchAgent that keeps a tmux server alive inside the GUI session on a fixed socket. Every Claude session you create there inherits the GUI session’s permissions and can reach the display. You attach to that tmux server over SSH – you’re not giving SSH access to the desktop directly, you’re using SSH as a keyhole into a tmux session that’s already inside the GUI.
This is also why auto-login must be enabled and the screen can’t be locked. The GUI session has to be alive and awake for the trick to work.
Three gotchas most tutorials skip
These are the ones I wish someone had flagged before I lost an evening.
| Gotcha | What happens | Fix |
|---|---|---|
| Workspace inside iCloud Drive | Files in iCloud-synced folders can be evicted from local storage mid-run, causing unpredictable read failures on long agentic sessions. | Put the project in ~/agent-work or similar – outside ~/Documents and ~/Desktop. |
| launchd env vars | launchd processes don’t inherit your shell environment. Claude Code works in Terminal, then silently fails at boot because the env vars aren’t there. | Add EnvironmentVariables keys to the plist, or source a wrapper script that exports them. |
| Remote Control timeout | Network outages longer than roughly 10 minutes trigger a session exit. Come back from lunch, session is dead. | Wrap the process in tmux (the guide does this anyway) so Claude Code can respawn cleanly. |
One thing that doesn’t fit neatly in the table above: as of June 2026, there’s an active malware campaign targeting exactly the audience reading this article. Zscaler traced a campaign running June 12-19, 2026 that used 22 unique Google Ads campaign IDs – search terms included “claude code” – tricking users into copy-pasting a Base64-obfuscated curl command into Terminal, which installed a credential stealer called MacSync Stealer. If you’re following any Claude Code install guide, verify the URL points to github.com/anthropics or a source you actually trust. Don’t paste blind.
Pro tip: Before enabling
--dangerously-skip-permissionson the spare Mac, do a dry run for a full afternoon without the flag. Watch what Claude tries to do. If anything would have been blocked, tighten the sandbox before you take off the training wheels.
A realistic first task
Once everything is wired up, resist the urge to test with something meaningful. Give the agent something small and reversible: “Clone this public repo, run the tests, and write a summary of what failed to ~/agent-work/report.md.”
Watch it from your main Mac via VNC or Screen Sharing. Note where it hesitates, where it does something surprising, and how long a full loop actually takes. That’s your baseline – everything from here is tuning.
When to skip this whole thing
Honest answer: the spare-Mac play is a bring-your-own-hardware move. It’s clever when you already have the machine. If you don’t have a second Mac sitting idle, the economics are harder to justify – cloud dev boxes are flexible, need no physical space, and you pay only when you’re using them. Neither option is obviously right for everyone; it depends on what you already own and how much you trust a remote box with your workflows.
FAQ
Do I need Claude Max, or is Pro enough?
Pro works fine for a single agent. Max is for parallel sessions.
Can I run this without keeping a user logged in on the spare Mac?
Technically yes over pure SSH, but the moment you want computer-use – screenshots, clicks, keyboard input – you’re stuck. macOS scoped the Screen Recording permission to the GUI session, not to SSH processes. That session has to be active and unlocked. Enable automatic login for the agent account, disable sleep, and leave it. It’s the least fragile setup, even if it feels counterintuitive to leave a machine permanently logged in.
Is Claude Code Remote Control the same as this spare-Mac setup?
No. Remote Control lets your phone view and approve a Claude session on any machine, but you still tap approve for each tool call. The spare-Mac setup exists so you can safely turn approvals off. Use both together for the fullest workflow – the spare Mac handles the unsafe flag, Remote Control handles the visibility.
Next step: if you have a spare Mac gathering dust, clone the repo, read setup-computer-use.sh end to end before running it, and then run it. Don’t skip the read step. That’s the whole discipline this setup is meant to teach.