Control Claude Code on another Mac, without the cloud
I work across two Macs. One is the laptop I carry around, the other stays on a desk and has the projects, the builds and the long-running jobs. For a while, “work on the other Mac” meant screen sharing, SSH, or walking over to it.
What I actually wanted was simpler: to stay in the Claude Code session I already had open and say “on the other Mac, run the tests in this project and fix what fails.” So I built claude-bridge, a small open-source tool that does exactly that.
What claude-bridge does
claude-bridge lets a Claude Code session on one Mac (the controller) run tasks in Claude Code on another Mac (the worker). You ask in plain English, and the work happens in real Claude Code sessions on the worker, inside folders you allowed in advance.
- No cloud relay. It doesn’t use Claude Code’s Remote Control or cloud sessions. The two Macs talk directly.
- No public URL. Traffic stays inside your own Tailscale network, which is encrypted and free for personal use.
- Resumable. Every task returns a session ID, so you can continue the same remote conversation across several requests, or open it on the worker with
claude --resume.
It’s about 600 lines in total: two Python files and an install script.
How it works
There are two pieces, one on each Mac.
On the worker: a tiny HTTP daemon
bridge_daemon.py is an HTTP server written with Python’s standard library only, so there’s nothing to install. When a task arrives, it starts Claude Code in headless mode:
claude -p --output-format stream-json --verbose --permission-mode acceptEdits [--resume <session-id>]It reads the streamed events as they come in, keeps a short progress log for the controller to poll, and writes the full transcript to ~/.claude-bridge/tasks/. The installer registers it as a launchd agent, so it starts at login and restarts itself if it crashes.
On your Mac: an MCP server
bridge_mcp.py is an MCP server that you add to Claude Code once. It gives Claude five tools:
| Tool | What it does |
|---|---|
remote_health | Checks the worker is reachable and shows its allowed folders and permission mode |
remote_run | Starts a task, optionally continuing a session, and waits for it up to a time limit |
remote_task | Follows a long-running task and returns its result |
remote_tasks | Lists recent tasks with their session IDs |
remote_cancel | Stops a running task |
So when you type “on the remote Mac, run the tests,” your local Claude decides to call remote_run, the MCP server sends the request over Tailscale, and the worker’s Claude does the work. Long tasks keep running in the background, and your Claude checks back on them with remote_task.
Security: what keeps this from being a remote shell for strangers
A tool that runs an AI agent on your computer from somewhere else deserves some suspicion, including from its author. These are the guardrails:
- Private network only. The daemon binds to the worker’s Tailscale IP, so it isn’t reachable from the internet or from the Wi-Fi you’re on.
- A bearer token on every request. It’s generated on install, stored with
chmod 600, and compared in constant time. - Allowed folders. Tasks can only run inside the folders you pass with
--root. Anything else is rejected before Claude starts. - Careful permissions by default. The remote Claude runs headless, so it can’t stop and ask you. By default it uses
acceptEdits: it can read and edit files, but Bash commands that you haven’t pre-approved are denied. You can pre-approve specific ones, such asBash(git:*)orBash(npm:*). - Full access is opt-in twice.
bypassPermissionsonly works if the worker was installed with--allow-bypassand the controller asks for it.
The honest limit: anyone who has both the token and access to your Tailscale network can run Claude on the worker. Treat the token like a password, and rotate it if it leaks.
Setting it up
You need macOS, Tailscale signed in to the same account on both Macs, Claude Code logged in on both, and uv on the controller. The README has every step and a troubleshooting table; this is the short version.
1. On the worker Mac, install the bridge and choose which folders it may use:
git clone https://github.com/Jenish109/claude-bridge.git ~/claude-bridge
cd ~/claude-bridge
./install_remote.sh --root ~/ProjectsIt finishes by printing a claude mcp add command with the worker’s address and token.
2. Give it Full Disk Access. This is the step people miss. Without it, any task that touches Desktop, Documents or Downloads quietly hangs on a macOS privacy prompt that nobody is there to click. The installer prints the exact paths to add under System Settings → Privacy & Security → Full Disk Access.
3. On your Mac, clone the repo and run the printed command:
claude mcp add claude-bridge --scope user \
-e BRIDGE_URL=http://<worker-tailscale-ip>:8765 \
-e BRIDGE_TOKEN=<token-from-worker> \
-- uv run -q --script ~/claude-bridge/bridge_mcp.py4. Restart Claude Code so it loads the new tools, then try:
Check the remote Mac's health.
On the remote Mac, go to ~/Projects/myapp, run the tests and fix any failures.
Continue that remote session and commit the changes.One request at a time works best, and paths are always paths on the worker, not on your own Mac.
Things I learned building it
- macOS privacy prompts are the real enemy of headless tools. Nothing errors; the process just waits forever. Printing the exact Full Disk Access paths from the installer saved more debugging than any code change. They also change when Claude Code updates and moves its binary.
- Session IDs are the whole trick. Because
claude -pcan resume a session, “now commit that” works across separate requests, and the worker keeps the full context. - Small beats clever. The daemon has no dependencies and the MCP server uses one. That makes the whole thing easy to read before you trust it with your machine, which I’d recommend doing.
Questions
Does it work both ways?
No. The controller sends tasks and the worker runs them. For each Mac to control the other, install it twice, once in each direction.
Does it need Claude Code’s Remote Control or a cloud account?
No. It only needs Claude Code logged in on both Macs and a free Tailscale account. The connection between the Macs never leaves your private network.
Does it work on Linux or Windows?
It’s built for macOS. The daemon is plain Python, but the installer uses launchd and the setup steps are Mac-specific.
Is it free?
Yes. The code is on GitHub. Remote tasks use the worker’s Claude Code login, the same as running claude there yourself.
If you try it, I’d love to hear what you use it for. Issues and pull requests are welcome on GitHub.
Want something like this for your team?
claude-bridge is one MCP server for one problem. The same approach works for your own systems: Claude that can read your database, call your internal API, or check your deploys, with access you control. I build custom MCP servers and Claude Code workflows, starting at $500.
Tell me which tools your team uses and I’ll reply with what’s worth building.
Prepared with AI assistance using the primary sources linked in the article. Guidance checked on 13 October 2026.