Claude Code läuft auf einem eigenen Server am stabilsten, wenn jede Rolle ihren eigenen Arbeitsordner und ihre eigene tmux-Sitzung bekommt, in der claude remote-control dauerhaft läuft. Gesteuert wird dann vom Handy über die Claude-App oder über einen Slack-Bot je Rolle, wiederkehrende Aufgaben laufen als claude -p über Zeitpläne, und ein Git-Sync sichert den Arbeitsstand alle 15 Minuten. So arbeiten seit dem 11.10.2026 fünf meiner KI-Mitarbeiter auf einem kleinen Linux-Server in der Hetzner Cloud statt auf meinem Mac: Content, Büro, Marketing, SEO und Website. Der Server hat keinen offenen Port, Zugänge liegen verschlüsselt im Repository, und was nach außen wirkt, gebe ich weiter selbst frei.
Dieser Beitrag beschreibt meinen Aufbau, keine allgemeine Anleitung für jeden Server. Wenn du Claude Code noch nie installiert hast, starte mit Claude Code installieren: Windows, Mac, Linux.
Warum die Belegschaft vom Mac auf einen Server umgezogen ist
Bis Oktober 2026 liefen alle Mitarbeiter auf meinem Mac. Das Ziel des Umzugs war schlicht: Die Belegschaft läuft dauerhaft, auch wenn mein Mac aus ist, ich bediene sie vom Handy, und kein Port des Servers ist aus dem Internet erreichbar. Alles sollte reproduzierbar sein, der Server also mit Terraform und cloud-init jederzeit neu aufsetzbar, und die wenigen Handgriffe abgezählt dokumentiert.
Der Server
Die Belegschaft selbst liegt in einem Git-Repository: ein Ordner je Mitarbeiter mit Personalakte, Arbeitsanweisungen, Skills, Wissen und Auftragsordnern. Wie so ein Ordner aufgebaut ist, steht in KI-Mitarbeiter erstellen: so startest du.
Eine tmux-Sitzung je Mitarbeiter mit Remote Control
Jeder Mitarbeiter läuft in einer eigenen tmux-Sitzung, gestartet von einer systemd-Benutzereinheit in seinem Ordner. Darin läuft Claude Code im Server-Modus von Remote Control:
claude remote-control --name "Sebastian" --permission-mode acceptEdits \
--no-chrome --remote-control-session-name-prefix <präfix>
Damit taucht die Sitzung in der Claude-App unter „Code“ auf, und ich kann sie vom Handy aus steuern. Ausgeführt wird alles auf dem Server, die App ist nur die Fernbedienung. Drei Dinge haben sich dabei bewährt:
- tmux ist Pflicht. Die Claude-Code-Doku empfiehlt es selbst: Wer
claude auf einem entfernten Rechner startet, soll es in tmux oder screen starten, damit die Sitzung das Ende der SSH-Verbindung überlebt. Reinschauen geht mit tmux attach, verlassen mit Ctrl-b d, nie mit exit.
- Neustart durch systemd. Im Server-Modus gibt Claude Code nach rund zehn Minuten ohne Netz auf und beendet sich. Die Einheit startet ihn nach 30 Sekunden neu. Sitzungen lassen sich laut Doku etwa vier Stunden lang wiederaufnehmen; was danach verloren geht, ist nur die Sitzung, nicht die Arbeit, denn die liegt in Dateien.
- Einmalige Fragen vorher beantworten. Beim ersten Start fragt Claude Code, ob es dem Ordner vertrauen, Remote Control einschalten und wie es neue Sitzungen anlegen soll. Das beantworte ich beim ersten Start einmal per SSH.
Voraussetzung ist ein Claude-Abo mit Anmeldung über claude.ai; ein API-Schlüssel reicht für Remote Control nicht. Der Server ist mit meinem Team-Konto angemeldet, dort muss ein Owner Remote Control in den Admin-Einstellungen erst einschalten. Der Login gilt für alle Mitarbeiter auf dem Server; rotiert er, melde ich mich einmal per SSH neu an.
Slack als Alltagsweg
Remote Control ist gut für lange, interaktive Arbeit. Für den Alltag nutze ich Slack: Jeder Mitarbeiter hat einen eigenen Slack-Bot und einen eigenen Kanal. Dahinter läuft je Mitarbeiter ein kleiner Dienst, das Open-Source-Projekt claude-threads (Apache-2.0), der den Kanal mit einer Claude-Sitzung im Ordner des Mitarbeiters verbindet.
- Keine öffentliche Adresse. Die Bots nutzen den Socket Mode von Slack, der Server baut die Verbindung selbst auf.
- Ein Kanal ist eine Sitzung. Nach 30 Minuten Ruhe läuft sie aus, die nächste Nachricht nimmt sie wieder auf. Der Arbeitsstand liegt ohnehin in Dateien, nicht im Chat.
- Freigaben per Reaktion. Fragt Claude nach einer Erlaubnis für ein Werkzeug, beantworte ich das mit einer Emoji-Reaktion im Kanal. Aufträge und Freigaben nimmt jeder Bot nur von meinem eigenen Slack-Konto an; alle anderen Nachrichten im Kanal ignoriert er.
- Berichte in einen gemeinsamen Kanal. Ergebnisse von Zeitplänen und Fehlermeldungen landen in einem privaten News-Kanal.
Zwei Grenzen habe ich dabei gelernt: Der kostenlose Slack-Tarif erlaubt zehn installierte Apps (Stand Oktober 2026); mit den fünf Mitarbeiter-Bots war unser Workspace an dieser Grenze. Und Direktnachrichten an einen Bot gehen mit diesem Gateway in Slack nicht, nur der Kanal. Slack und Remote Control greifen auf denselben Ordner zu; denselben Auftrag führe ich deshalb nie in beiden gleichzeitig.
Zeitpläne und Läufe ohne Bildschirm: claude -p
Wiederkehrende Aufgaben, etwa ein morgendlicher Statusbericht, stehen in einer einzigen Datei mit Name, Mitarbeiter, Uhrzeit und dem Auftrag als Textdatei. Daraus erzeugt ein Skript systemd-Timer. Jeder Lauf startet Claude Code ohne Oberfläche:
claude -p --permission-mode acceptEdits --max-turns 60 --max-budget-usd 5 "$(cat auftrag.md)"
- Immer einen Berechtigungsmodus angeben. Ohne ihn startet ein Lauf im eingebauten Startmodus, und der kann laut Doku auch
auto sein. Ich lege ihn deshalb selbst fest. In einem Lauf ohne Bildschirm kann niemand eine Rückfrage beantworten; was eine Freigabe bräuchte, wird abgelehnt.
- Grenzen setzen.
--max-turns begrenzt die Schritte, --max-budget-usd die geschätzten Kosten. Beides gilt nur im Print-Modus.
- Ergebnis als Brief. Der Lauf legt sein Ergebnis als Datei im Postfach-Ordner des Mitarbeiters ab. Schlägt er fehl, geht ein Brief an Kai, meinen KI-Mitarbeiter für Führung, der die Berichte der anderen sichtet.
So laufen bei mir auch Vergleichstests mit und ohne ein Werkzeug: zwei getrennte Läufe mit claude -p, einer davon mit --disallowedTools, damit zum Beispiel die Werkzeuge eines MCP-Servers in diesem Lauf technisch gar nicht verfügbar waren.
Git-Sync statt Dateifreigabe
Alle 15 Minuten committet ein Timer die Ordner der Mitarbeiter auf dem Server, holt Änderungen per git pull --rebase und pusht in unser eigenes Git. Auf dem Mac ziehe ich wie gewohnt. Bei einem Konflikt bricht der Sync ab und schreibt einen Brief, statt etwas zu überschreiben; ein Force-Push ist ausgeschlossen.
Die wichtigste Regel dazu: Ein Mitarbeiter arbeitet entweder auf dem Mac oder auf dem Server, nie auf beiden. Im Ordner jedes umgezogenen Mitarbeiters liegt eine Hinweisdatei, die genau das sagt. Was sich je Rechner unterscheidet, also Pfade, verfügbare Werkzeuge und Meldewege, steht nicht in der gemeinsamen CLAUDE.md, sondern in einer CLAUDE.local.md, die Git ignoriert und die auf dem Server ein Installationsskript anlegt. So sind Mac und Server im Repository identisch.
Zugänge: verschlüsselt im Repository, entschlüsselt nur auf dem Server
Schlüssel für APIs, Webmaster-Konten und MCP-Server liegen mit SOPS verschlüsselt im Repository. Der Server hat einen eigenen age-Schlüssel als zweiten Empfänger; mein privater Schlüssel liegt nie auf dem Server. Bei der Installation entschlüsselt ein Skript die Zugänge des jeweiligen Mitarbeiters in eine .env und rendert Konfigurationsvorlagen wie eine .mcp.json, in der im Repository nur Platzhalter wie ${API_KEY} stehen. Die Zieldateien sind von Git ignoriert und nur für den Arbeitsbenutzer lesbar; das Skript bricht ab, wenn eine Zieldatei nicht ignoriert ist. Braucht ein Mitarbeiter einen Zugang nur kurz, entschlüsselt er ihn in ein temporäres Verzeichnis und löscht es danach.
Zusätzlich gilt das, was ich in Claude MCP Server einrichten beschrieben habe: Was ein Mitarbeiter nicht darf, sperre ich technisch. Löschende Werkzeuge eines MCP-Servers stehen als Deny-Regel in den Einstellungen, nicht als Bitte in der Arbeitsanweisung.
Was auf dem Server nicht geht
Die Freigabe-Regeln ändern sich durch den Server nicht. Was das Haus verlässt oder etwas verändert, ein Mailversand, ein Deploy, eine Anzeige, geht nur mit meinem ausdrücklichen Wort raus, und der Mitarbeiter hält das Wort mit Zeitpunkt im Protokoll fest. Wer welche Rolle hat, steht in KI-Belegschaft: 14 Mitarbeiter, ein Chef.
Häufige Fragen
Kann man Claude Code auf einem Server laufen lassen?
Ja. Claude Code ist ein Kommandozeilenprogramm und läuft auf Linux. Für dauerhafte Sitzungen startest du es in tmux, für die Fernsteuerung mit claude remote-control, für geplante Aufgaben mit claude -p. Remote Control braucht ein Claude-Abo mit Anmeldung über claude.ai, ein API-Schlüssel reicht dafür nicht. Auf dem Server nutze ich ein Team-Konto, für das die kommerziellen Bedingungen von Anthropic gelten. Pro und Max sind laut Anthropic für gewöhnliche, persönliche Nutzung ausgelegt; für Zeitpläne rund um die Uhr in einer Firma nimm ein Team- oder Enterprise-Konto oder einen API-Schlüssel.
Wie steuere ich Claude Code vom Handy?
Mit Remote Control. Auf dem Server läuft claude remote-control, die Sitzung erscheint in der Claude-App unter „Code“, und du schreibst dort wie in einem Chat. Ausgeführt wird alles auf dem Server. Auf Team- und Enterprise-Konten muss ein Owner die Funktion vorher in den Admin-Einstellungen einschalten.
Warum tmux für Claude Code?
Weil die Sitzung sonst endet, sobald die SSH-Verbindung abbricht. In tmux läuft Claude Code weiter, und du kannst dich jederzeit wieder einklinken und zusehen. Die Claude-Code-Doku empfiehlt tmux oder screen für genau diesen Fall.
Was kostet so ein Server?
Bei mir 10,49 Euro netto im Monat für den Server (Hetzner CAX21, Stand Oktober 2026), dazu das Daten-Volume und Speicher für Backups. Das Claude-Abo kommt dazu, der Server ersetzt es nicht. Auf dem Server nutze ich ein Team-Konto, für das die kommerziellen Bedingungen von Anthropic gelten. Pro und Max sind laut Anthropic für gewöhnliche, persönliche Nutzung ausgelegt; für Zeitpläne rund um die Uhr in einer Firma nimm ein Team- oder Enterprise-Konto oder einen API-Schlüssel. Die Rechenarbeit des Modells läuft weiter bei Anthropic, auf dem Server laufen nur Claude Code, die Werkzeuge und die Dateien.
Ist das sicher?
Sicherer als ein Rechner mit offenem SSH-Port, aber nicht ohne Risiko. Bei mir antwortet von außen kein Port, Zugang gibt es nur über ein privates Netz, die Daten liegen verschlüsselt, die Zugänge mit SOPS, und der Arbeitsbenutzer hat kaum Root-Rechte. Das schützt nicht vor allem; deshalb sind gefährliche Werkzeuge zusätzlich technisch gesperrt.
Wie du weitermachst
Fang nicht mit dem Server an, sondern mit einem Mitarbeiter, der auf deinem Rechner zuverlässig arbeitet. Erst wenn Ordner, Arbeitsanweisungen und Freigaben stehen, lohnt der Umzug. Den Einstieg beschreibt Claude Code: Anleitung für Einsteiger. Wie ich meine Mitarbeiter aufbaue, führe und auf den Server bringe, zeige ich in meiner Community Claude Practitioners.
