Claude Code Remote Mac Deployment: 2026 SSH Guide

A one-year OAuth token is available for CI, scripts, and other environments without interactive browser login, but it must be handled as a secret.

Winner: a dedicated remote Mac when the project needs Xcode, Simulator, Keychain, signing tools, or another macOS-only dependency. For a normal cross-platform project, keep Claude Code on the system already used for development. Claude Code remote Mac deployment should begin with an isolated account and key-based SSH access, then continue with project permissions, sandbox boundaries, credential controls, and a recoverable session.

This guide is for:

• Windows or Linux developers who need Claude Code to operate macOS-only tools.
• Mobile developers who want to isolate AI coding work from a primary Mac.
• Platform engineers who need a repeatable, recoverable, and removable remote development node.

Last updated August 17, 2026. Configuration details were checked against the official Claude Code and Apple documentation available on that date.

Start with the project dependency decision

Do not rent or provision a remote Mac merely because Claude Code runs well in a terminal. The deciding evidence is the project dependency list.

A remote Mac is justified when the task requires one or more of these capabilities:

• Xcode builds, archives, or signing workflows.
• iOS or macOS Simulator.
• Apple Keychain access for development certificates or secure credentials.
• macOS-specific package behavior.
• Apple SDKs, platform frameworks, or command-line tools unavailable on Linux.
• A persistent macOS node for scheduled builds or repeatable validation.

A remote Mac is usually unnecessary when the project is a standard web service, backend API, Python tool, Go service, JavaScript application, or containerized workload that already builds on Linux or Windows.

The hidden cost of choosing the wrong platform is not only the rental bill. It also includes dependency drift, a second credential store, another machine to patch, network latency during interactive work, and a larger attack surface for source code and signing assets.

Does a developer without a local Mac still have a viable route?

Yes. Claude Code can run over an SSH session on a real macOS host. The remote machine must provide a usable shell, the required development tools, network access, and an authentication path that does not depend on a browser callback reaching the remote terminal.

A useful decision rule is:

• If the project dependency list contains Xcode, Simulator, Keychain, or Apple signing tools, use a dedicated remote Mac.
• If the list contains only portable compilers, package managers, and tests, use the existing Linux or Windows environment.
• If the project is still uncertain, validate one small macOS-specific task before committing to a longer deployment.

Build the SSH foundation before installing Claude Code

Apple documents Remote Login as the macOS service for SSH and SFTP access. The service can be restricted to selected users instead of allowing every local account to connect. (Apple Remote Login settings)

Use a dedicated account such as buildagent rather than an administrator account used for personal work. The example below uses fictional names and paths.

On the Mac, open System Settings, choose General, then Sharing, and open the settings beside Remote Login. Turn it on and select Only these users. Add the dedicated account. Do not enable full disk access for remote users unless the project has a documented requirement for it. Apple warns that enabling remote access can reduce the security of the Mac.

From the client machine, create a key pair if one does not already exist:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_claude_remote

Copy the public key to the dedicated account through the approved provisioning method. Do not paste private keys into chat, tickets, repositories, screenshots, or shell history.

Create an SSH alias on the client:

Host cedar-mac
    HostName mac.example.invalid
    User buildagent
    IdentityFile ~/.ssh/id_ed25519_claude_remote
    IdentitiesOnly yes
    ServerAliveInterval 60
    ServerAliveCountMax 3

The hostname is intentionally fictional. Replace it only with the address issued for the remote Mac.

Connect once without disabling host-key verification:

ssh cedar-mac

Review the fingerprint through the provider’s trusted console or provisioning record. Do not accept a changed fingerprint simply because the connection fails. A changed fingerprint can indicate a rebuilt host, a changed address, or a man-in-the-middle risk.

A single successful login is not enough. Validate the complete SSH chain:

whoami
hostname
pwd
echo "$SHELL"
command -v git
command -v xcodebuild

Then test file transfer and reconnection:

printf "ssh validation\n" > /tmp/ssh-check.txt
scp /tmp/ssh-check.txt cedar-mac:/tmp/ssh-check.txt
ssh cedar-mac 'cat /tmp/ssh-check.txt'
ssh cedar-mac 'exit'
ssh cedar-mac 'echo reconnect-ok'

The expected result is an isolated user, the intended host, a known shell, working file transfer, and a clean reconnect. If any of these fail, stop before installing Claude Code. Otherwise, later failures become difficult to attribute.

How should SSH access be limited?

Limit access at three layers: the Mac account, the SSH key, and the network path. Use a dedicated account, one key per operator or automation identity, and a provider or firewall rule that exposes SSH only to approved source networks where possible.

The official Apple Remote Login procedure should be the reference for the current macOS interface. Use the ProxyMac console to review the access method and machine details when the remote host is supplied through ProxyMac.

Install Claude Code and choose the right authentication path

Claude Code’s official installation documentation lists the native installer as the recommended method for macOS and provides a shell installation command. After installation, the documentation recommends checking both the version and the diagnostic output. (Claude Code setup documentation)

Run the installer inside the remote SSH session:

curl -fsSL https://claude.ai/install.sh | bash

Start a new shell if the installer reports that the command path changed. Then verify:

claude --version
claude doctor

The version output is an acceptance record, not a performance claim. Store it with the deployment notes so that a future update can be compared against the known-good state.

There are two separate authentication paths.

Interactive developer authentication

For personal interactive work, start Claude Code from the project directory:

cd ~/work/sample-app
claude

The first launch normally opens a browser login. An SSH session may not be able to complete the local callback. Claude Code’s official authentication guide says the terminal can provide a login URL to copy into a local browser, and some flows may ask for a code to be pasted back into the terminal. (Claude Code authentication guide)

This route is suitable when a developer is present and can approve permission prompts. It is not the same as a CI credential.

Claude Code stores credentials in the encrypted macOS Keychain on macOS. That is useful, but it does not make the host universally safe. Anyone with effective access to the account, the Keychain session, or the machine’s administrative controls may still affect the environment.

Script and CI authentication

For scripts or CI jobs where browser login is unavailable, the official documentation describes claude setup-token. It generates a one-year OAuth token for supported subscription plans. The token is printed rather than saved automatically, so the operator must place it in a protected secret store. (Claude Code authentication guide)

Do not put the token in:

• A Git repository.
• CLAUDE.md.
• A shell history file.
• A command pasted into a shared terminal recording.
• A screenshot or build log.
• A project settings file committed to source control.

For automation, inject the secret at runtime and remove it from the environment after the job when the runner design allows it. Keep interactive credentials and automation credentials separate. A developer’s subscription login should not become a shared team secret.

Also inspect environment precedence. If ANTHROPIC_API_KEY is already present, it can take precedence after approval and cause an unexpected account or organization mismatch. Check the active status inside Claude Code and remove stale variables from the shell profile when they are not required.

Initialize the project as a controlled macOS workspace

Do not launch Claude Code from the home directory. Create a bounded work area and place the repository inside it.

mkdir -p ~/work
cd ~/work
git clone git@example.invalid:team/sample-app.git
cd sample-app

The repository address is fictional. Use the organization’s approved Git authentication method. Confirm the identity before allowing an agent to change files:

git config user.name
git config user.email
git status

Check that the required macOS toolchain is visible in a non-interactive shell:

command -v xcodebuild
xcodebuild -version
command -v git
command -v ruby
command -v node

Do not assume that a tool available in an interactive shell will also be available to Claude Code. SSH startup files, shell choice, and login configuration can change the executable path. Record the output from the shell that actually starts Claude Code.

Add a project-level CLAUDE.md with explicit operating rules:

# Project instructions

- Work only inside this repository.
- Do not read or modify files under ~/.ssh, ~/.aws, or ~/Library/Keychains.
- Do not access production configuration.
- Run the unit test command after source changes.
- Run the macOS build validation command only when requested.
- Do not create commits unless the operator asks.
- Prefer small, reversible edits.

Claude Code uses project files such as CLAUDE.md as session context, and its terminal workflow can inspect files, run commands, modify code, and execute tests. (Claude Code workflow documentation)

Start with a small task that can be reverted. For example:

• Add one test for an existing function.
• Correct a clearly isolated documentation error.
• Change one non-sensitive configuration value on a temporary branch.
• Run the project’s existing test command.
• Review the diff.
• Revert the change.

This task proves more than installation. It confirms that Claude Code can read the intended repository, edit only the expected path, execute the required command, and stop when the requested scope is complete.

Combine permissions and sandboxing instead of trusting prompts

Permissions and sandboxing solve different problems. Claude Code permissions decide which tools, files, or domains the agent may use. Sandboxing provides operating-system-level limits for Bash commands and child processes. The official documentation recommends using both as defense in depth. (Claude Code permissions documentation)

Start with explicit rules. The exact settings syntax should be checked against the current official documentation before publication because configuration fields can change.

The policy should follow this order:

• Deny: SSH keys, cloud credential directories, signing assets, production files, deployment secrets, and destructive commands outside the workspace.
• Ask: Network access, dependency installation, changes to build configuration, and commands that may alter generated artifacts.
• Allow: Read and edit operations inside the repository, the project’s test command, and safe inspection commands.

A deny rule should protect the most sensitive paths even if a prompt asks for access. A permission rule is not a complete network boundary. For example, blocking a dedicated fetch tool does not necessarily block curl or wget if Bash remains available. The official administration documentation specifically separates permission rules from sandbox network controls. (Claude Code administration documentation)

Enable sandboxing from Claude Code when the deployment supports it:

/sandbox

Choose the mode that matches the workflow. For a managed node, decide whether sandbox startup failure should stop execution rather than silently continue without isolation. Claude Code documents sandbox.failIfUnavailable for deployments that require sandboxing as a security gate. (Claude Code sandboxing documentation)

Test the boundary with safe probes:

printf "inside-workspace\n" > ./sandbox-check.txt
cat ./sandbox-check.txt
cat ~/.ssh/id_ed25519
curl https://example.invalid

The first command should be allowed if the workspace is writable. The sensitive file request should be denied or require an explicit refusal path. Network behavior should match the configured domain policy. Delete the test file after validation.

How can Claude Code’s file and command access be restricted on a remote Mac?

Use project permission rules for tool and path decisions, then add sandbox filesystem and network restrictions for Bash enforcement. Do not rely on CLAUDE.md alone. Instructions can guide behavior, but enforcement belongs in permission and sandbox configuration.

Keep the session alive and recoverable

An SSH connection is a transport layer, not a session manager. A closed laptop, unstable network, or terminal timeout can end the visible connection while the remote process continues or stops depending on how it was launched.

Use tmux for an interactive development session:

tmux new -s claude-work
cd ~/work/sample-app
claude

Detach with the tmux command sequence, then reconnect later:

ssh cedar-mac
tmux attach -t claude-work

Claude Code documents a tmux compatibility issue: without additional configuration, Shift+Enter may submit instead of inserting a newline, while notifications and progress updates may not reach the outer terminal. The documented settings use allow-passthrough, extended keys, and terminal feature configuration. (Claude Code terminal configuration)

A minimal configuration may look like this:

set -g allow-passthrough on
set -s extended-keys on
set -as terminal-features 'xterm*:extkeys'

Apply it with:

tmux source-file ~/.tmux.conf

What happens when SSH disconnects during a Claude Code task?

The recovery path depends on whether Claude Code is running inside a persistent terminal session. With tmux, reconnect to the Mac and attach to the existing session. Without it, assume the interactive process may have ended and inspect the repository state before starting again.

Never assume a partially completed edit is safe. After reconnecting, run:

git status
git diff

Review the working tree before issuing a new instruction. This prevents duplicate edits, conflicting fixes, or an accidental continuation from an unknown state.

For long-running automated work, use a CI-oriented authentication design instead of leaving a personal interactive session unattended. Keep the job logs, secret injection, repository checkout, and cleanup steps separate from the developer’s terminal workflow.

Run the launch acceptance check

A remote Mac is ready for real work only when the complete path has passed. The acceptance record should include the following checks:

• SSH key login works without falling back to a shared password.
• The account is the intended dedicated user.
• The host fingerprint matches the trusted record.
• Git can fetch the test repository through the approved method.
• Claude Code installation passes claude --version and claude doctor.
• Interactive authentication or automation authentication works through the selected path.
• macOS-specific commands such as xcodebuild are visible from the Claude Code shell.
• The project instructions are present and limited to the required scope.
• A small code change can be made, tested, reviewed, and reverted.
• Sensitive file reads are denied or require the expected approval.
• Sandbox network and filesystem rules produce the expected result.
• A tmux session survives terminal closure and can be reattached.
• A Mac restart has a documented recovery path.
• Credentials, temporary files, and test artifacts can be removed.

The final test should use a real but reversible project task. Do not validate only with echo, pwd, or a successful login. A useful acceptance task reads existing code, changes one isolated file, runs the project test command, performs one required macOS validation, and produces a reviewable diff.

What should be checked before putting a remote Claude Code Mac into service?

Check identity, authentication, toolchain discovery, repository scope, permissions, sandbox behavior, recovery, and cleanup. If any security test gives an unexpected result, keep the node in staging and fix the boundary before running production-adjacent work.

The environment should also have a retirement procedure. Remove the SSH key, disable or delete the dedicated account, revoke tokens, clean temporary files, archive the final diff, and record the Claude Code update policy. For account and access operations, keep the provider-side recovery details available through the ProxyMac help center.

For teams, the practical choice is usually determined by duration and workload. A short validation task may justify a temporary remote Mac. A recurring Xcode build, signing workflow, or always-on AI development node may justify a longer rental period. Review the current ProxyMac plans and billing options only after the project has passed the SSH, permission, and toolchain checks.

A local Windows or Linux setup remains cheaper and simpler for portable code, but it cannot replace Xcode, Simulator, Keychain behavior, or macOS signing tools. A virtualized or improvised macOS environment adds compatibility, licensing, hardware, and maintenance risks. For projects that genuinely require those Apple-specific capabilities, a real remote Mac removes the most fragile part of the setup while keeping the machine separate from the developer’s primary workstation.

The strongest path is to deploy the smallest isolated environment that can complete one reversible task. If SSH recovery, Claude Code permissions, and the required macOS toolchain all pass, move to a longer-lived node. If they do not, fix the deployment before paying for more capacity or exposing production credentials.