Einrichten einer Remote-Box für Agentic Coding

Der minimale Stack zum Betrieb von Claude Code auf einer Remote-Box besteht aus einem Linux-VPS oder einer dauerhaft laufenden Maschine, Tailscale für ein privates WireGuard-Mesh ohne Port-Forwarding oder dynamisches DNS, tmux für persistente Terminal-Sessions, die Verbindungsabbrüche überstehen, sowie mosh oder SSH als Verbindungsschicht — alles kostenlos, kombinierbar und unabhängig von den aktuellen Wrapper-Tools. Dieser Leitfaden führt durch diesen Stack von Anfang bis Ende und behandelt dabei den häufigen Fall, den bestehende Anleitungen überspringen: einen Coding-Agenten auf einem Cloud-VPS oder einer Spare-Box, abgesichert und von einem Laptop oder Smartphone aus ferngesteuert.

Das eigentliche Problem ist die Persistenz. Wenn Sie einen Coding-Agenten lokal ausführen und Ihren Laptop schließen, stirbt die Session. Eine Remote-Box hält den Agenten über Verbindungsabbrüche hinweg am Leben, gibt Ihnen Kontrolle und kalkulierbare Kosten gegenüber einer verwalteten Plattform und ermöglicht es Ihnen, die Arbeit von überall aus zu steuern. Der Haken — der überall zu wenig thematisiert wird — ist, dass eine Box, auf der ein Agent mit Shell-Zugriff und API-Keys läuft, eine ernsthafte Angriffsfläche darstellt. Deshalb stellt dieser Leitfaden die Sicherheit an erste Stelle, anstatt sie nachträglich anzuhängen.

Warum eine Remote-Box, und DIY vs. die Alternativen

Eine Remote-Box ist die richtige Wahl, wenn Sie einen Coding-Agenten benötigen, der Verbindungsabbrüche übersteht, unbeaufsichtigt läuft und von jedem Gerät aus erreichbar ist — ohne die Nutzungsgebühren einer Plattform zu zahlen oder deren Sandbox-Beschränkungen akzeptieren zu müssen. Der Preis dafür ist operativer Natur: Sie sind für Sicherheit, Verfügbarkeit und das Einspielen von Updates verantwortlich. Für Entwickler, die bereits mit SSH und Git vertraut sind, ist dieser Kompromiss in der Regel lohnenswert.

Bevor Sie anfangen zu bauen, entscheiden Sie, welcher der drei folgenden Ansätze zu Ihnen passt. Die Landschaft hat sich Anfang 2026 verändert, und die ältere Formulierung „Sie brauchen tmux und SSH, um Claude Code remote zu nutzen” ist inzwischen unvollständig.

Anthropic hat natives Remote Control als Research-Preview und Cloud Remote Sessions Anfang 2026 ausgeliefert (CLI v2.1.x, Stand Mitte 2026). Remote Control verwendet ausschließlich ausgehende HTTPS-Verbindungen — keine eingehenden Ports — um Ihnen die Steuerung einer Session vom Smartphone aus zu ermöglichen. Das ist durchaus nützlich, aber es handelt sich um eine einzelne Session, die endet, sobald das Terminal, das sie gestartet hat, geschlossen wird. Claude Code selbst läuft als CLI-Tool ohne Hintergrunddienst für interaktive Sessions; der offene Feature-Request für einen Headless-Daemon-Modus bestätigt, dass das Schließen des Terminals die Session beendet. Für Always-on-, Headless- oder Multi-Projekt-Setups bauen Sie auf dauerhaften Primitiven auf und schichten Komfort-Tools darüber.

Die Kategorie der verwalteten Plattformen existiert und ist gut finanziert, aber für einen Entwickler, der bereits in SSH und Git zu Hause ist, bietet eine selbst gehostete Box mehr Kontrolle bei geringeren Kosten. Dieser Leitfaden behandelt den DIY-Weg.

Die zwei Muster: tmux vs. systemd

Es gibt zwei grundlegend verschiedene Ziele, die Leser regelmäßig verwechseln und die unterschiedliche Setups erfordern. Das Ausführen eines CLI-Coding-Agenten wie Claude Code in einer Session, an die man sich an- und abkoppelt, ist das tmux-Muster. Das Hosten eines Agenten als dauerhaft verfügbaren HTTP-Dienst, der über eine API erreichbar ist, ist das systemd-Muster. Das falsche zu wählen ist der häufigste strukturelle Fehler bei Remote-Agent-Setups.

Verwenden Sie tmux, wenn Sie den Agenten beobachten und steuern möchten — Prompts eingeben, Aktionen bestätigen, Ausgaben lesen. Verwenden Sie systemd, wenn der Agent ein Dienst ist, der Anfragen entgegennimmt und ohne angeschlossenen Benutzer läuft. Die meisten Personen, die Claude Code interaktiv betreiben, wollen tmux. Die meisten Personen, die einen Agenten hinter einer API bereitstellen, wollen systemd. Manche Setups verwenden beides.

Claude Code Remote ausführen: Der kanonische kostenlose Stack

Der kanonische kostenlose Stack zum Remote-Betrieb von Claude Code besteht aus einer Linux-Box, Tailscale als private Netzwerkschicht, OpenSSH plus mosh für die Verbindung und tmux für persistente Sessions. Dieser Abschnitt enthält die direkt einsetzbare Setup-Sequenz. Führen Sie die Sicherheitshärtung im nächsten Abschnitt durch, bevor Sie die Box als produktiv betrachten.

Tailscale installieren

Tailscale baut ein WireGuard-verschlüsseltes Mesh zwischen Ihren Geräten auf: Nach der Installation erhält Ihre Remote-Box eine stabile 100.x.x.x-Adresse, die von jedem authentifizierten Gerät erreichbar ist, ohne Firewall-Ports zu öffnen, dynamisches DNS zu konfigurieren oder Ihren Router anzufassen. Das zugrunde liegende Protokoll von Tailscale ist WireGuard, und der kostenlose Personal-Plan deckt bis zu 6 Benutzer mit unbegrenzt eigenen Geräten ab, gemäß der Preisüberarbeitung vom April 2026 — überprüfen Sie die aktuellen Limits, bevor Sie sich darauf verlassen.

Installieren Sie es auf der Remote-Box gemäß der offiziellen Installationsdokumentation:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

Der Befehl tailscale up gibt eine Authentifizierungs-URL aus. Öffnen Sie diese, melden Sie sich an, und die Box tritt Ihrem Tailnet bei. Führen Sie tailscale ip -4 aus, um die 100.x.x.x-Adresse zu erhalten. Installieren Sie Tailscale auf Ihrem Laptop und Smartphone auf dieselbe Weise, authentifizieren Sie sie beim selben Konto, und alle drei Geräte können sich nun direkt gegenseitig erreichen.

Ein Vorbehalt, der Setups lautlos zum Scheitern bringt — den wir selbst erlebt haben: Aktivieren Sie nicht Tailscales eingebauten SSH-Server mit tailscale up --ssh, wenn Sie mosh verwenden möchten. Tailscale SSH betreibt einen eigenen SSH-Server, nicht OpenSSH, und mosh muss mosh-server über echtes OpenSSH starten und dessen Ausgabe parsen, um eine Session zu initialisieren — was Tailscale SSH nicht unterstützt. Halten Sie OpenSSH installiert und laufend neben Tailscale, damit mosh sich verbinden kann.

SSH und mosh einrichten

SSH gibt Ihnen die Shell; mosh hält sie über instabile Mobilverbindungen nutzbar, indem es IP-Wechsel und Roaming übersteht. mosh benötigt einen UDP-Port im Bereich 60000–61000, der erreichbar sein muss, gemäß der mosh-Dokumentation. Über ein Tailscale-Mesh ist dieser Bereich zwischen authentifizierten Geräten bereits erreichbar, sodass keine Router-Konfiguration erforderlich ist.

Installieren Sie mosh sowohl auf dem Server als auch auf Ihrem Client:

sudo apt update && sudo apt install -y mosh tmux

Verbinden Sie sich von Ihrem Laptop aus über die Tailscale-Adresse:

mosh youruser@100.x.x.x

Wenn mosh keine Verbindung herstellen kann, fallen Sie auf einfaches ssh youruser@100.x.x.x zurück, um zu bestätigen, dass die Box erreichbar ist, und überprüfen Sie dann, ob OpenSSH (nicht Tailscale SSH) antwortet.

Persistente tmux-Sessions erstellen

tmux ist das, was den Agenten am Leben hält, nachdem Sie die Verbindung getrennt haben. Starten Sie eine Session, führen Sie Claude Code darin aus, koppeln Sie sich ab, und der Agent arbeitet weiter; koppeln Sie sich später von jedem Gerät aus wieder an, um ihn zu überprüfen oder zu steuern.

Benennen Sie tmux-Sessions nach dem Projekt, nicht nach dem Tool. Verwenden Sie tmux new-session -s myproject statt tmux new-session -s claude — wenn Sie drei Agenten über drei Repos hinweg betreiben, muss tmux ls Ihnen sagen, welche Session welche ist:

tmux new-session -s myproject
# innerhalb der Session:
cd ~/code/myproject
claude
# Abkoppeln mit Ctrl-b und dann d

Das Flag -s benennt die Session. Koppeln Sie sich von überall mit tmux attach -t myproject wieder an, oder listen Sie alles Laufende mit tmux ls auf. Dieser Abkoppel-und-Wiederankoppel-Zyklus ist die gesamte interaktive Remote-Agenten-Schleife: Schließen Sie Ihren Laptop, koppeln Sie sich über mosh von Ihrem Smartphone wieder an, lesen Sie, was der Agent getan hat, und geben Sie ihm die nächste Anweisung.

Die Sicherheits-Baseline

Eine Remote-Box, auf der ein Coding-Agent läuft, ist ein hochwertiges Angriffsziel: Sie enthält Shell-Zugriff, API-Keys und häufig Repository-Zugangsdaten. Das Binden des Agent-Ports an 0.0.0.0 auf einem öffentlichen VPS, selbst kurzzeitig für einen Smoke-Test, gefährdet alle drei. Härten Sie die Box, bevor Sie ihr etwas anvertrauen. Dieser Abschnitt ist nicht optional.

Nur SSH-Keys

Deaktivieren Sie die Passwort-Authentifizierung, sodass der einzige Zugang über einen Key erfolgt, den Sie besitzen. Bearbeiten Sie /etc/ssh/sshd_config und setzen Sie:

PasswordAuthentication no
PermitRootLogin no

Die Direktive PasswordAuthentication no deaktiviert die Passwort-Anmeldung, und PermitRootLogin no blockiert direktes Root-SSH — beides dokumentiert im sshd_config-Handbuch. Ein häufiger Fehler ist das Bearbeiten der falschen Datei; diese Direktiven gehören in /etc/ssh/sshd_config, nicht in eine Client-Konfiguration. Wenden Sie die Änderungen mit sudo systemctl restart ssh an. Bestätigen Sie, dass Ihr Key in einer separaten Session funktioniert, bevor Sie die aktuelle schließen, damit ein Tippfehler Sie nicht aussperrt.

Das private Mesh privat halten

Das Mesh von Tailscale ist bereits authentifiziert, aber Sie können mithilfe von Tailscale ACLs festlegen, welche Geräte welche Ports erreichen dürfen. Eine ACL-Richtlinie schränkt den Datenverkehr zwischen markierten Geräten ein — zum Beispiel, indem nur Ihr Laptop und Smartphone die Agent-Box erreichen dürfen und sonst nichts im Tailnet. Für ein Single-User-Setup ist das Standard-„Alles innerhalb Ihres Tailnets erlauben” vernünftig; fügen Sie ACLs hinzu, wenn andere Personen oder nicht vertrauenswürdige Geräte das Netzwerk teilen.

Den Agenten niemals an 0.0.0.0 binden

Wenn Sie einen lokal gebundenen Dienst testen, verwenden Sie curl http://127.0.0.1:9000/health vom Server selbst, anstatt vorübergehend an 0.0.0.0 zu binden. Auf einem VPS ohne Firewall-Regel, die Port 9000 blockiert, setzt diese eine Änderung Ihren Agenten für die gesamte Laufzeit des Prozesses dem öffentlichen Internet aus. Binden Sie an 127.0.0.1 und erreichen Sie den Dienst über Tailscale oder einen Reverse Proxy — niemals direkt.

Secrets aus der Unit-Datei heraushalten

Tragen Sie API-Keys niemals in die Environment=-Zeile einer systemd-Unit-Datei ein — sie erscheinen in der Ausgabe von systemctl show. Verwenden Sie EnvironmentFile=/etc/myagent/secrets.env, um die Werte aus der Unit-Datei und der systemctl show-Ausgabe herauszuhalten, gemäß der systemd.exec-Dokumentation. Sichern Sie die Datei ab:

sudo mkdir -p /etc/myagent
sudo chmod 640 /etc/myagent/secrets.env
sudo chown root:myagent /etc/myagent/secrets.env

Seien Sie präzise darüber, was Ihnen das bringt: EnvironmentFile= hält Secrets aus der Unit-Datei und der systemctl show-Ausgabe heraus, aber nach dem Laden bleiben die Werte in der Umgebung des laufenden Prozesses und über D-Bus lesbar. Für echten Geheimnisschutz verwenden Sie systemds LoadCredential=, dokumentiert im systemd-Credentials-Leitfaden, der Zugangsdaten über ein eingeschränktes Verzeichnis statt über die Prozessumgebung übergibt.

Einen Dienst-Agenten am Laufen halten: Die systemd-Unit

Für einen Agenten, der als dauerhaft verfügbarer HTTP-Dienst läuft statt als interaktive Session, verwenden Sie eine systemd-Unit, die an 127.0.0.1 gebunden ist, mit Restart=always. Das ist das systemd-Muster: Der Dienst startet beim Hochfahren, startet bei einem Absturz neu, schreibt Logs ins Journal und berührt niemals direkt einen öffentlichen Port. EnvironmentFile= ist eine langjährige systemd-Kerndirektive, die in jeder aktuellen systemd-Version verfügbar ist, gemäß der systemd.exec-Dokumentation.

Erstellen Sie /etc/systemd/system/my-agent.service:

[Unit]
Description=My Agent Service
After=network.target

[Service]
User=myagent
Group=myagent
WorkingDirectory=/home/myagent/app
EnvironmentFile=/etc/myagent/secrets.env
ExecStart=/home/myagent/app/venv/bin/uvicorn main:app --host 127.0.0.1 --port 9000
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Jede Direktive hat ihren Zweck. After=network.target wartet auf die Netzwerkverfügbarkeit. Das Ausführen unter einem dedizierten User/Group begrenzt den Schaden, falls der Agent kompromittiert wird. EnvironmentFile= lädt Secrets aus der abgesicherten Datei. ExecStart startet den Server direkt aus dem virtualenv des Projekts — ohne Wrapper-Skripte — gebunden an 127.0.0.1, sodass der Port niemals öffentlich erreichbar ist. Restart=always mit RestartSec=5 bringt den Dienst fünf Sekunden nach jedem Absturz wieder hoch.

Aktivieren und starten Sie ihn:

sudo systemctl daemon-reload
sudo systemctl enable --now my-agent
sudo systemctl status my-agent

Um den Dienst sicher zugänglich zu machen, schalten Sie einen Reverse Proxy vor den localhost-gebundenen Port. Ein nginx proxy_pass zu 127.0.0.1 hält das Backend von außen direkt unerreichbar, während TLS am Rand terminiert wird:

server {
    listen 443 ssl;
    server_name agent.example.com;

    ssl_certificate     /etc/letsencrypt/live/agent.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/agent.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:9000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Stellen Sie das Zertifikat mit Certbot bereit, das die Ausstellung und Erneuerung von Let’s Encrypt-Zertifikaten automatisiert. Für ein Single-User-Setup benötigen Sie oft gar keinen öffentlichen Hostnamen — den Dienst über Tailscale unter 100.x.x.x:9000 von authentifizierten Geräten aus zu erreichen, vermeidet die öffentliche Angriffsfläche vollständig.

Die Box vom Smartphone aus erreichen

Sie erreichen einen Remote-Agenten vom Smartphone aus auf dieselbe Weise wie vom Laptop — über Tailscale, mit einem Terminal-Client oder einem Browser-Terminal davor. Die Tooling-Landschaft bewegt sich hier schnell, Stand Mitte 2026; betrachten Sie diese als optionale Erweiterungen, nicht als tragende Infrastruktur.

Die dauerhaften Optionen sind ein mobiler SSH-Client (mehrere unterstützen persistente Verbindungen und Key-basierte Authentifizierung) plus tmux, oder mosh für Verbindungen, die Netzwechsel überstehen. Darüber hinaus gibt es Browser-Terminal-Tools. ttyd stellt ein Terminal über das Web bereit. vibetunnel (MIT-lizenziert, Mac-first mit einem plattformübergreifenden Linux-npm-Build) proxyt ein Terminal in den Browser und wurde für die Überwachung von Claude Code-Agenten entwickelt, mit Remote-Zugriff über Tailscale. Wenn Sie ein Browser-Terminal betreiben, halten Sie es an localhost gebunden und erreichen Sie es über Tailscale — ein Web-Terminal öffentlich zugänglich zu machen ist derselbe 0.0.0.0-Fehler in anderer Form.

Claude Codes eigenes natives Remote Control deckt den leichtgewichtigen Fall ab: ausgehende HTTPS-Verbindungen, Steuerung vom Smartphone, keine eingehenden Ports. Es ist der schnellste Weg, eine einzelne laufende Session zu beeinflussen. Der DIY-Stack bleibt das Mittel der Wahl, wenn die Arbeit jedes einzelne Terminal überdauern soll.

Der tägliche Workflow

Die tägliche Redeploy-Schleife auf einer Remote-Box besteht aus drei Befehlen: Code pullen, Dienst neu starten, Logs verfolgen. Für einen systemd-verwalteten Agenten sieht das so aus:

cd ~/app && git pull origin main
source venv/bin/activate && pip install -r requirements.txt
sudo systemctl restart my-agent
journalctl -u my-agent -f

git pull holt den neuesten Code, die Abhängigkeitsinstallation nimmt neue Anforderungen auf, systemctl restart startet den Dienst neu, und journalctl -u my-agent -f verfolgt die Dienst-Logs in Echtzeit, damit Sie einen sauberen Start bestätigen können — journalctl liest das systemd-Journal, dokumentiert auf freedesktop.org. Für einen interaktiven tmux-Agenten ist die Schleife noch einfacher: mit tmux attach -t myproject wieder ankoppeln, git pull ausführen und den Agenten weitermachen lassen.

Fazit

Bauen Sie auf den Primitiven auf, die länger bestehen als die Wrapper: SSH und Tailscale für das Netzwerk, tmux für Sessions, die Sie steuern, systemd für Dienste, die unbeaufsichtigt laufen, und eine Sicherheits-Baseline, die den Agent-Port vom öffentlichen Internet fernhält. Wählen Sie bewusst das tmux-Muster oder das systemd-Muster, je nachdem, ob Sie einen Agenten steuern oder einen hosten, härten Sie die Box, bevor Sie ihr API-Keys anvertrauen, und schichten Sie dann natives Remote Control oder ein Browser-Terminal als Komfort-Schicht darüber. Beginnen Sie mit einer frischen Linux-Box und dem obigen Tailscale-Installationsbefehl — der Rest ist von dort aus kombinierbar.

FAQs

Warum stirbt mein Agent immer, wenn ich mich von SSH trenne?

Eine einfache SSH-Session bindet den Prozess des Agenten an Ihr Terminal, sodass das Schließen der Verbindung ein Hangup-Signal sendet, das ihn beendet. Führen Sie den Agenten stattdessen innerhalb einer tmux-Session aus: Starten Sie sie mit tmux new-session -s myproject, starten Sie den Agenten, und koppeln Sie sich dann mit Ctrl-b gefolgt von d ab. Der Prozess läuft weiterhin auf dem Server, und Sie koppeln sich später von jedem Gerät aus mit tmux attach -t myproject wieder an.

Wann sollte ich Claude Codes natives Remote Control anstelle eines DIY-Setups mit tmux und SSH verwenden?

Verwenden Sie natives Remote Control, wenn Sie nur eine einzelne laufende Session von Ihrem Smartphone oder Browser aus ohne Infrastrukturaufwand steuern müssen, da es ausgehende HTTPS-Verbindungen verwendet und keine eingehenden Ports öffnet. Es ist auf eine einzelne Session beschränkt und endet mit dem Terminal, das es gestartet hat. Für Always-on-, Headless- oder Multi-Projekt-Arbeit, die Verbindungsabbrüche überstehen muss, bauen Sie stattdessen den DIY-Stack auf SSH, Tailscale, tmux und systemd auf.

Funktioniert mosh über ein Tailscale-Netzwerk?

Ja, mosh funktioniert über ein Tailscale-Mesh, da der benötigte UDP-Port-Bereich 60000 bis 61000 zwischen authentifizierten Geräten bereits erreichbar ist, sodass keine Router-Konfiguration erforderlich ist. Der einzige Fehlerfall ist das Aktivieren von Tailscales eigenem SSH-Server mit tailscale up --ssh, was OpenSSH ersetzt; mosh muss mosh-server über echtes OpenSSH starten, um eine Session zu initialisieren, halten Sie also OpenSSH installiert und laufend neben Tailscale.

Was ist der Unterschied zwischen EnvironmentFile und LoadCredential für Secrets in systemd?

EnvironmentFile lädt Werte aus einer externen Datei, sodass sie aus der Unit-Datei und der systemctl show-Ausgabe herausgehalten werden, aber die Werte bleiben in der Umgebung des laufenden Prozesses und über D-Bus lesbar. LoadCredential ist stärker, da es Secrets über ein eingeschränktes Verzeichnis statt über die Prozessumgebung übergibt und sie so außerhalb der Reichweite der Prozessumgebung hält. Verwenden Sie EnvironmentFile für Konfiguration und LoadCredential für echte Secrets.