Claude Code auf dem Remote-Mac bereitstellen: SSH 2026

Die offizielle Claude-Code-Dokumentation trennt Berechtigungsregeln und Sandboxing als zwei eigene Schutzschichten. Daraus folgt die wichtigste Entscheidung: Benötigt das Projekt Xcode, den Simulator, Keychain oder andere macOS-Werkzeuge, ist ein eigener Remote-Mac die passende Umgebung. Für ein rein plattformübergreifendes Projekt genügt dagegen meist das vorhandene System. Claude Code sollte dort nicht einfach nach dem ersten SSH-Login gestartet werden. Zuerst gehören ein unabhängiger Benutzer, Schlüsselzugriff, ein kontrolliertes Arbeitsverzeichnis, getrennte Anmeldedaten und eine wiederaufnehmbare Sitzung eingerichtet.

Zuletzt aktualisiert am 17.08.2026; die technischen Angaben wurden anhand der aktuellen Claude-Code-Dokumentation und der Apple-Anleitung für die entfernte Anmeldung geprüft.

Diese Anleitung ist für drei Gruppen gedacht:

• Windows- und Linux-Entwickler, die macOS-exklusive Werkzeuge benötigen.
• Mobile-Entwickler, die AI-Coding-Aufgaben vom lokalen Arbeitsgerät isolieren möchten.
• Plattform- und DevOps-Teams, die einen reproduzierbaren, prüfbaren und später wieder entfernbaren Claude-Code-Knoten bereitstellen.

Remote-Mac oder vorhandenes System: Die Projektabhängigkeiten entscheiden

Ein Remote-Mac ist nicht automatisch die bessere Wahl. Der entscheidende Nachweis steht in der Projektabhängigkeitsliste.

Projektmerkmal	Vorhandenes Windows- oder Linux-System	Remote-Mac mit macOS
Node.js-, Python-, Go- oder Rust-Projekt ohne macOS-Bindung	Meist ausreichend	Zusätzliche Kosten und Verwaltung vermeiden
Xcode-Projekt mit Build, Signing oder Simulator	Nicht ausreichend für den vollständigen Workflow	Geeignet
Zugriff auf macOS-Keychain oder Apple-Signierungswerkzeuge	Nur eingeschränkt oder nicht verfügbar	Geeignet, sofern die Benutzer- und Systemrechte korrekt eingerichtet sind
Lang laufende Agent-Aufgaben und nächtliche Tests	Abhängig von lokaler Verfügbarkeit	Sinnvoll als dauerhaft erreichbarer Knoten
Sensible Produktionszugänge im selben Benutzerprofil	Hohes Trennungsrisiko	Nur mit separatem Konto und klaren Sperrregeln vertretbar

In der Praxis entstehen mindestens drei unterschätzte Probleme:

1. Werkzeugverfügbarkeit: Ein Linux-Runner kann Quellcode prüfen, aber keinen vollständigen Xcode-, Simulator- oder macOS-Signing-Ablauf ersetzen.
2. Rechtevermischung: Wird Claude Code im persönlichen Administratorprofil gestartet, können Projektdateien, Konfigurationen, SSH-Schlüssel und lokale Geheimnisse zu nah beieinanderliegen.
3. Sitzungsinstabilität: Eine einmalige SSH-Verbindung beweist nicht, dass ein Auftrag nach Terminalabbruch, Netzwechsel oder einem Neustart sauber fortgesetzt werden kann.

Hinzu kommen Datenschutz- und Betriebskosten. Ein Remote-Mac muss erreichbar sein, aktualisiert werden, Backups des Codes erhalten und nach Ende des Projekts wieder bereinigt werden. Bei einem gemieteten Knoten sollten deshalb Datenschutz- und Auftragsbedingungen vor der Übertragung vertraulicher Repositories geprüft werden.

Hinweis: „Remote“ bedeutet nicht automatisch „Cloud-Ausführung“. Bei dieser Anleitung läuft Claude Code auf dem echten Mac. SSH überträgt die Terminalsteuerung; Projektdateien und lokale Werkzeuge bleiben auf dem Zielsystem, sofern der Arbeitsablauf sie nicht ausdrücklich an externe Dienste sendet.

Erste Phase: Den Mac für eine diagnostizierbare SSH-Kette vorbereiten

Apple nennt für die entfernte Anmeldung den Pfad Apple-Menü → Systemeinstellungen → Allgemein → Freigabe → Entfernte Anmeldung. Dort kann der Zugriff auf bestimmte Benutzer begrenzt werden. Apple weist außerdem darauf hin, dass Remote Login den Mac weniger sicher machen kann. Sie sollten deshalb nicht „Alle Benutzer:innen“ wählen, wenn ein einzelner Arbeitsaccount genügt. Die vollständige Vorgehensweise steht in der Apple-Dokumentation zu Remote Login.

Schritt 1: Einen unabhängigen Arbeitsaccount festlegen

Verwenden Sie für Claude Code einen eigenen Account, zum Beispiel devagent. Die folgenden Namen, Adressen und Pfade sind absichtlich fiktiv:

ssh devagent@mac-build.example.invalid

Der Account sollte nur die Rechte erhalten, die das Projekt benötigt. Ein Administratorzugang ist für die alltägliche Codebearbeitung nicht erforderlich. Benötigt ein Installationsschritt erhöhte Rechte, sollte dieser bewusst außerhalb des normalen Agentenlaufs ausgeführt werden.

Erstellen Sie außerdem ein Arbeitsverzeichnis, das nicht das gesamte Benutzerverzeichnis umfasst:

mkdir -p "$HOME/workspaces/sample-app"
cd "$HOME/workspaces/sample-app"

Schritt 2: Schlüsselzugriff statt Passwortroutine einrichten

Auf dem Verwaltungsgerät wird ein SSH-Schlüsselpaar erzeugt. Der private Schlüssel bleibt dort und wird niemals in ein Repository, einen Screenshot oder eine Chatnachricht kopiert.

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_remote_mac
ssh-copy-id -i ~/.ssh/id_ed25519_remote_mac.pub devagent@mac-build.example.invalid

Falls ssh-copy-id auf dem Ausgangssystem nicht vorhanden ist, kann der öffentliche Schlüssel über eine bereits erlaubte Passwortanmeldung in ~/.ssh/authorized_keys eingetragen werden. Danach sollte der Zugriff mit einem Alias in ~/.ssh/config vereinheitlicht werden:

Host sample-mac
    HostName mac-build.example.invalid
    User devagent
    IdentityFile ~/.ssh/id_ed25519_remote_mac
    IdentitiesOnly yes

Die Verbindung erfolgt danach mit:

ssh sample-mac

Beim ersten Kontakt muss der Hostschlüssel geprüft werden. Ein unbekannter oder unerwartet geänderter Fingerabdruck ist kein Detail, das übersprungen werden sollte. Er kann auf eine Neuinstallation hindeuten, aber auch auf eine fehlerhafte oder manipulierte Verbindung.

Schritt 3: Nicht nur den Login, sondern die Kette prüfen

Führen Sie mindestens diese vier Prüfungen aus:

Prüfung	Beispiel	Erwartetes Ergebnis
Interaktiver Login	ssh sample-mac	Shell startet unter dem vorgesehenen Benutzer
Dateiübertragung	sftp sample-mac	Testdatei lässt sich in das Arbeitsverzeichnis übertragen
Wiederverbindung	SSH beenden und erneut starten	Alias und Schlüssel funktionieren erneut
Shell-Umgebung	echo "$SHELL"; command -v git	Erwartete Shell und Werkzeuge werden gefunden

Prüfen Sie zusätzlich:

whoami
pwd
git --version
printf '%s\n' "$PATH"

Ein häufiger Fehler entsteht durch unterschiedliche Umgebungen für interaktive und nicht interaktive Shells. Ein Werkzeug, das in einer Terminal-App funktioniert, muss nicht automatisch über einen entfernten Befehl oder aus Claude Code heraus gefunden werden. Pfade für Homebrew, Xcode Command Line Tools und Projektmanager gehören daher ausdrücklich in die Diagnose.

Zweite Phase: Claude Code installieren und die Anmeldung trennen

Die offizielle Installationsanleitung empfiehlt nach der Installation zwei Prüfungen:

claude --version
claude doctor

claude doctor arbeitet laut Dokumentation als schreibgeschützte Diagnose und meldet unter anderem Installations- und Einstellungsfehler. Die Installationsart sollte im Team festgelegt werden. Eine native Installation kann Aktualisierungen anders verwalten als eine Installation über Homebrew oder einen anderen Paketmanager. Für produktive Build-Knoten ist eine ungeplante Aktualisierung nicht immer wünschenswert; Release-Kanal und Wartungsfenster sollten dokumentiert werden. Details stehen in der offiziellen Setup-Anleitung.

Schritt 4: Persönliche Anmeldung und Automatisierung nicht vermischen

Für eine persönliche, interaktive Sitzung wird Claude Code gestartet und anschließend der Anmeldevorgang über den Browser verwendet:

claude

Bei einer SSH-Sitzung kann der Browser-Callback nicht auf dem Remote-Mac landen. Das ist kein Grund, einen Token in die Shell-Historie zu schreiben. Öffnen Sie den Login im lokalen Browser, folgen Sie dem vorgesehenen Anmeldeablauf und prüfen Sie anschließend in Claude Code den aktiven Status.

Für Skripte und CI-Aufgaben sieht der offizielle Ablauf anders aus:

claude setup-token
export CLAUDE_CODE_OAUTH_TOKEN='TOKEN_NUR_IN_DER_LAUFZEIT'

Die Claude-Code-Dokumentation beschreibt diesen OAuth-Token als für ein Jahr gültig und ausschließlich für Modellanfragen vorgesehen. Er wird vom Befehl nicht dauerhaft gespeichert. Für automatisierte Jobs sollte der Wert über den Secret Store des CI-Systems oder eine geschützte Laufzeitumgebung bereitgestellt werden, nicht über .zshrc, ein Git-Repository oder eine sichtbare Kommandozeile. Die Unterschiede zwischen interaktiver Anmeldung und Automatisierung sind in der offiziellen Authentifizierungsdokumentation beschrieben.

Die macOS-Keychain kann die lokale Credential-Verwaltung unterstützen, ersetzt aber keine Projektisolation. Ein Agent, der auf ein Arbeitsverzeichnis zugreifen darf, sollte nicht automatisch auch Zertifikate, Umgebungsdateien oder Produktionskonfigurationen lesen können.

Erfahrung aus der Einrichtung: Wenn eine Anmeldung unerwartet fehlschlägt, prüfen Sie zuerst ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN und den aktiven Profilstatus. Eine gesetzte Umgebungsvariable kann einen vorhandenen Browser-Login überlagern. Geheimnisse gehören weder in die Ausgabe eines Screenshots noch in eine dauerhaft geladene Shell-Datei.

Dritte Phase: Projekt, Toolchain und CLAUDE.md kontrolliert initialisieren

Nach dem Login wird das Repository in das zuvor angelegte Arbeitsverzeichnis übertragen. Verwenden Sie für sensible Projekte eine abgesicherte Git-Authentifizierung und speichern Sie keine privaten Schlüssel im Projekt.

cd "$HOME/workspaces/sample-app"
git clone git@example.invalid:team/sample-app.git .
git config user.name "Remote Build User"
git config user.email "build-user@example.invalid"

Danach wird geprüft, ob der macOS-spezifische Werkzeugpfad verfügbar ist:

command -v xcodebuild
command -v simctl
command -v git
command -v node

Bei Xcode-Projekten sollte mindestens ein harmloser Diagnoseaufruf erfolgen, bevor Claude Code Änderungen vornehmen darf:

xcodebuild -version
xcrun simctl list devices

Die konkrete Ausgabe hängt von der installierten macOS- und Xcode-Version ab und sollte vor der Veröffentlichung erneut gegen die Zielumgebung geprüft werden. Eine feste Versionsnummer gehört nicht in eine Anleitung, wenn sie nicht für den jeweiligen Knoten verifiziert wurde.

Schritt 5: Arbeitsregeln im Projekt festhalten

Legen Sie eine projektbezogene CLAUDE.md an:

# Projektregeln

- Bearbeiten Sie nur Dateien unter src/, tests/ und docs/.
- Führen Sie vor jedem Commit die definierten Tests aus.
- Lesen oder ändern Sie keine .env-, Zertifikats- oder Produktionsdateien.
- Verwenden Sie für iOS-Builds nur das dokumentierte xcodebuild-Skript.
- Führen Sie keine Veröffentlichung und kein Pushen ohne ausdrückliche Freigabe aus.

Projektweite Regeln gehören in CLAUDE.md oder .claude/CLAUDE.md. Gemeinsam genutzte Einstellungen können in .claude/settings.json liegen. Lokale, nicht zu veröffentlichende Anpassungen gehören in .claude/settings.local.json. Die Claude-Code-Dokumentation zu Einstellungen beschreibt diese Ebenen und ihre Priorität.

Starten Sie Claude Code zunächst im Plan-Modus:

claude --permission-mode plan

Lassen Sie den Agenten nur eine kleine, rücksetzbare Aufgabe analysieren. Geeignet sind etwa ein fehlender Test, eine klar abgegrenzte Dokumentationsänderung oder eine einzelne kleine Fehlerkorrektur. Vor der Ausführung muss nachvollziehbar sein:

• Welche Dateien gelesen wurden.
• Welche Dateien geändert werden sollen.
• Welcher Testbefehl ausgeführt wird.
• Wie die Änderung zurückgerollt werden kann.

Vierte Phase: Dateien, Befehle und Netzwerkzugriffe begrenzen

Die Berechtigungen von Claude Code unterscheiden zwischen allow, ask und deny. Ablehnungsregeln werden vor Erlaubnisregeln ausgewertet. Diese Reihenfolge ist entscheidend: Eine allgemeine Erlaubnis darf keine Sperre für Geheimnisse aushebeln. Ein mögliches Projektprofil sieht so aus:

{
  "permissions": {
    "allow": [
      "Bash(git status)",
      "Bash(git diff)",
      "Bash(xcodebuild -scheme SampleApp test *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(rm *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./Certificates/**)",
      "Read(./config/production/**)"
    ]
  }
}

Die offiziellen Beispiele für permissions.deny nennen unter anderem .env-, Secret- und Credential-Dateien. Die Regeln verhindern nicht nur das absichtliche Öffnen; passende Dateien werden laut Dokumentation auch aus Dateisuche und Discovery ausgeschlossen. Prüfen Sie die konkrete Syntax in der Dokumentation zu Berechtigungen.

Schutzebene	Zweck	Beispiel für die Abnahme
Projektpfad	Arbeitsbereich klein halten	Claude findet Dateien außerhalb des Repositories nicht
Permission-Regeln	Aktionen bewusst erlauben, bestätigen oder sperren	git push fragt nach Bestätigung
Sandbox	Bash auf Datei- und Netzwerkgrenzen beschränken	Unerlaubter Host oder Pfad wird blockiert
Secret-Verwaltung	Tokens und Zertifikate aus dem Projekt fernhalten	Kein Secret liegt in Git oder Shell-Historie

Aktivieren Sie anschließend die Sandbox. Claude Code dokumentiert die Einstellung sandbox.enabled; mit sandbox.failIfUnavailable kann ein Start verhindert werden, wenn die Sandbox nicht verfügbar ist. Für einen sicherheitskritischen Knoten ist ein stiller Fallback auf unsandboxierte Befehle eine schlechte Überraschung.

Beispiel:

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

Testen Sie drei Fälle:

1. Eine normale Dependency-Installation oder ein erlaubter Testlauf.
2. Der Leseversuch auf .env oder einen Zertifikatspfad.
3. Ein Befehl außerhalb des Arbeitsverzeichnisses oder gegen einen nicht erlaubten Netzwerkhost.

Der erste Fall muss funktionieren. Die beiden anderen müssen blockiert oder ausdrücklich zur Bestätigung vorgelegt werden. Die Sandbox-Dokumentation von Claude Code weist darauf hin, dass unsandboxierte Wiederholungen separat eingeschränkt werden können.

Fünfte Phase: SSH-Unterbrechungen und lange Aufgaben beherrschbar machen

Ein SSH-Terminal ist kein Sitzungsmanager. Für längere Aufgaben sollte Claude Code in einer kontrollierten tmux-Sitzung laufen:

tmux new -s claude-work
cd "$HOME/workspaces/sample-app"
claude

Nach einer Unterbrechung:

ssh sample-mac
tmux attach -t claude-work

Claude Code dokumentiert für tmux drei relevante Einstellungen:

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

Diese Optionen verbessern unter anderem Benachrichtigungen, Fortschrittsanzeigen und die Unterscheidung von Shift+Enter. Die vollständigen Hinweise stehen in der offiziellen Terminal-Konfiguration.

Wichtig ist die Unterscheidung zwischen tmux, lokal gespeicherten Sitzungen und Remote Control:

Methode	Was bleibt erhalten?	Geeignet für
Normales SSH-Terminal	Nur die aktuelle Verbindung	Kurze Befehle
tmux	Der laufende Terminalprozess auf dem Mac	Längere interaktive Aufgaben
claude --resume	Eine lokale Claude-Code-Sitzung anhand ihrer Historie	Fortsetzung auf demselben Knoten
Remote Control	Zugriff auf einen laufenden lokalen Prozess über Claude-Oberflächen	Steuerung von einem anderen Gerät

Remote Control ist kein Ersatz für einen beendeten Prozess. Die offizielle Dokumentation beschreibt, dass der lokale Prozess weiterlaufen muss. Ein geschlossenes Terminal, beendetes Claude Code oder ein längerer Netzwerkausfall kann die Sitzung beenden. Ein OAuth-Token aus claude setup-token reicht außerdem nicht für Remote-Control-Sitzungen. Für eine robuste SSH-Arbeitsumgebung bleibt tmux deshalb die klarere Basisschicht.

Was muss vor dem produktiven Einsatz geprüft werden?

Die Abnahme sollte nicht mit „SSH funktioniert“ enden. Verwenden Sie eine kleine echte Aufgabe, die sich vollständig zurücksetzen lässt.

Abnahmepunkt	Test	Freigabekriterium
Identität	whoami, pwd, Hostalias	Richtiger Benutzer und richtiger Mac
Installation	claude --version, claude doctor	Keine nicht behobenen Diagnosefehler
Projektzugriff	Repository lesen und Branch prüfen	Nur der vorgesehene Arbeitsbereich
Änderung	Kleine Codeänderung mit Test	Diff ist nachvollziehbar und rücksetzbar
macOS-Toolchain	xcodebuild oder projektbezogener Befehl	Tool wird aus der Agentenumgebung gefunden
Geheimnisse	Zugriff auf .env, Zertifikate und Produktionspfade	Erwartete Sperre greift
Unterbrechung	SSH trennen, erneut verbinden, tmux anhängen	Aufgabe bleibt kontrollierbar
Rückbau	Account, Schlüssel und Credentials entfernen	Kein Zugriff bleibt unbeabsichtigt bestehen

Vor der Übergabe an ein Team sollten Sie außerdem festlegen, wann Claude Code aktualisiert wird. Native Installationen können sich automatisch aktualisieren; Installationen über Paketmanager verlangen je nach Methode einen anderen Wartungsprozess. Für CI/CD ist ein dokumentierter Update-Kanal wichtiger als die vermeintlich neueste Version.

Wenn ein Mietknoten später nicht mehr benötigt wird, gehören der Entzug des SSH-Schlüssels, die Entfernung des Benutzerkontos, die Bereinigung von Tokens, die Archivierung der Änderungen und die Prüfung von GitHub- oder GitLab-Zugangsdaten zum Rückbau. Für Kontozugänge und technische Fragen kann die ProxyMac-Hilfe als zusätzlicher Bezugspunkt dienen.

Ein vorhandener Windows- oder Linux-Rechner bleibt für reine Backend-, Skript- und Bibliotheksprojekte oft die wirtschaftlichere Lösung. Er scheitert jedoch an Xcode, Simulator, macOS-Signing und bestimmten Keychain-Abläufen. Ein eigener lokaler Mac bietet maximale Kontrolle, bindet aber Kapital, Wartungszeit und Hardware an ein Projekt, das vielleicht nur vorübergehend einen macOS-Knoten benötigt. Für solche Fälle ist die Miete eines Remote-Mac über ProxyMac die flexiblere Zwischenlösung: Der Knoten kann zunächst mit einer kleinen, rücksetzbaren Aufgabe geprüft und anschließend nur so lange betrieben werden, wie Toolchain, Sitzungsstabilität und Projektlaufzeit es rechtfertigen. Die verfügbaren Zugangs- und Verwaltungsoptionen finden Sie auf der ProxyMac-Anmeldeseite.