Claude Code und ChatGPT Codex auf dem Linux-Server einrichten: Schritt für Schritt

Diese Anleitung führt von einem frisch installierten Debian- oder Ubuntu-Server zu einem arbeitsfähigen KI-Agenten, der Logs auswertet, Konfigurationen prüft und Wartungsaufgaben ausführt. Wir richten Claude Code (Anthropic) und Codex CLI (OpenAI, das Kommandozeilenwerkzeug hinter ChatGPT) ein, beide unter einem eigenen Benutzer mit begrenzten Rechten, und zeigen Gemini CLI (Google) als dritte Möglichkeit. Alle Befehle wurden auf einem KernelHost-KVM-Rootserver mit Debian 13 und Ubuntu 24.04 durchgespielt. Was ein AI Managed Server grundsätzlich ist und welche Architekturen es gibt, steht im Beitrag AI Managed Server: KI-Agenten sicher verbinden.

Stand September 2026. Die Werkzeuge entwickeln sich schnell; prüfen Sie Schalter im Zweifel mit claude --help, codex --help beziehungsweise gemini --help.

Voraussetzungen

• Ein Rootserver mit Debian 12 oder 13 beziehungsweise Ubuntu 22.04 oder 24.04 und Root-Zugriff per SSH. Auf AlmaLinux und Rocky Linux sind die Schritte gleich, nur die Paketbefehle heißen dnf statt apt.
• Grundabsicherung erledigt: SSH-Login per Schlüssel, Firewall, automatische Sicherheitsupdates. Die Checkliste für neue Rootserver deckt das ab.
• Ein Konto bei Anthropic (Claude Pro, Max oder Team) oder ein API-Schlüssel, ein ChatGPT-Konto (Plus, Pro oder Team) oder ein OpenAI-API-Schlüssel. Sie brauchen nur eines davon, wenn Sie nur ein Werkzeug einrichten wollen.
• Ausgehendes HTTPS zu api.anthropic.com und api.openai.com. Auf KernelHost-Servern ist das ab Werk der Fall, eine restriktive eigene Firewall muss es erlauben.

Welcher Server reicht für einen KI-Agenten?

Ein KI-Agent braucht auf dem Server keine besondere Hardware und keine GPU, denn das Sprachmodell läuft beim Anbieter. Auf dem Server laufen nur das Kommandozeilenwerkzeug und Node.js, zusammen meist wenige hundert Megabyte Arbeitsspeicher während einer Sitzung. Für einen Server, auf dem sonst wenig läuft, genügen 2 vCPU und 4 GB RAM. Betreibt der Server nebenher Webseiten, Datenbanken oder Gameserver, planen Sie für den Agenten rund 1 GB Arbeitsspeicher Reserve ein. Ein KVM-Rootserver von KernelHost ist in rund 30 Sekunden bereitgestellt, wird PrePaid ohne Mindestlaufzeit abgerechnet und eignet sich damit auch als Testsystem, auf dem Sie den Agenten erst einmal ausprobieren.

Schritt 1: Eigenen Benutzer anlegen und sudo begrenzen

Der Agent läuft nie als root. Er bekommt ein eigenes Konto und über eine sudo-Allowlist genau die Befehle, die er braucht. Beginnen Sie mit wenigen, lesenden Befehlen und erweitern Sie die Liste, wenn eine Aufgabe es wirklich erfordert.

sudo adduser --disabled-password --gecos "KI-Agent" aiagent
sudo tee /etc/sudoers.d/aiagent >/dev/null <<'EOF'
aiagent ALL=(root) NOPASSWD: /usr/bin/journalctl *, /usr/bin/systemctl status *, /usr/bin/systemctl restart nginx, /usr/bin/apt-get update, /usr/bin/apt-get upgrade -y, /usr/bin/tail *, /usr/bin/df *, /usr/bin/ss *
EOF
sudo chmod 440 /etc/sudoers.d/aiagent
sudo visudo -cf /etc/sudoers.d/aiagent

Die letzte Zeile prüft die Syntax. Ein Fehler in einer sudoers-Datei kann sudo für alle sperren, deshalb gehört die Prüfung immer dazu. --disabled-password sorgt dafür, dass sich niemand mit Passwort als aiagent anmelden kann; Sie wechseln später mit sudo -iu aiagent in das Konto. Wie sudo-Benutzer grundsätzlich funktionieren, erklärt der Beitrag sudo-Benutzer unter Linux anlegen.

Schreibrechte gezielt vergeben statt Editor per sudo

Soll der Agent Dateien in /etc ändern, geben Sie ihm nicht nano per sudo frei (damit ließe sich jede Datei editieren, auch /etc/sudoers), sondern arbeiten Sie mit einer Gruppe und gezielten Schreibrechten, zum Beispiel setfacl -m u:aiagent:rw /etc/nginx/sites-available/meine-seite.conf. Für den Anfang reicht es völlig, wenn der Agent Änderungen vorschlägt und Sie sie übernehmen.

Dasselbe gilt für Befehle mit Platzhaltern in der Allowlist. /usr/bin/tail * erlaubt dem Agenten, jede Datei zu lesen, auf die root Zugriff hat, auch Dateien mit Zugangsdaten. Wer das nicht möchte, schreibt die erlaubten Pfade aus, etwa /usr/bin/tail -n 200 /var/log/nginx/error.log.

Schritt 2: Node.js 22 installieren

Beide Werkzeuge laufen mit Node.js. Claude Code verlangt mindestens Version 18, Codex CLI mindestens 22, deshalb installieren wir 22 LTS. Die Paketquellen von Debian 12 liefern eine zu alte Version; NodeSource liefert die aktuelle:

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt-get install -y nodejs
node --version
npm --version

Alternative ohne Root-Rechte: nvm

Wer keine Skripte aus dem Internet mit Root-Rechten ausführen möchte, nimmt nvm im Home-Verzeichnis des Agent-Benutzers; das ist dann komplett ohne Root-Rechte möglich. Den Installationsbefehl für nvm übernehmen Sie aus dem README des Projekts, danach genügen drei Zeilen:

nvm install 22
nvm alias default 22
node --version

Details und weitere Wege stehen in der Anleitung zu Node.js auf Debian.

Schritt 3: Claude Code installieren und anmelden

Ab hier arbeiten wir im Konto des Agenten:

sudo -iu aiagent
curl -fsSL https://claude.ai/install.sh | bash
claude --version

Der native Installer legt Claude Code unter ~/.local/bin ab und hält sich selbst aktuell. Alternativ geht es über npm mit npm install -g @anthropic-ai/claude-code; schlägt das mit EACCES fehl, hilft der Abschnitt zur Fehlerbehebung weiter unten.

Anmeldung auf einem Server ohne Browser

Beim ersten Start von claude fragt das Werkzeug nach der Anmeldung. Mit einem Claude-Konto öffnet es normalerweise den Browser; auf einem Server ohne Browser zeigt es eine Adresse und einen Code an, den Sie auf Laptop oder Smartphone bestätigen. Die Anmeldung gilt danach für diesen Benutzer auf diesem Server, bis Sie sich abmelden.

API-Schlüssel für Skripte und Cronjobs

Für Skripte und Cronjobs ist ein API-Schlüssel die bessere Wahl:

echo 'export ANTHROPIC_API_KEY="sk-ant-..."' >> ~/.bashrc
chmod 600 ~/.bashrc
source ~/.bashrc
claude -p "Antworte nur mit OK" 

Der Schlüssel liegt damit nur im Home-Verzeichnis des Agent-Benutzers, das andere Benutzer nicht lesen können. Legen Sie ihn in der Anthropic-Konsole mit einem monatlichen Ausgabenlimit an, dann kann eine Sitzung, die aus dem Ruder läuft, nicht teuer werden. Den Schlüssel selbst schreiben Sie nie in eine Aufgabe an den Agenten und nie in eine Datei, die er ausgeben soll.

Schritt 4: Claude Code für den Server konfigurieren

Die Regeldatei CLAUDE.md

Claude Code liest beim Start eine Datei CLAUDE.md im aktuellen Verzeichnis. Dort stehen die Regeln, die für jede Sitzung gelten. Legen Sie im Home-Verzeichnis des Agenten ein Arbeitsverzeichnis mit dieser Datei an:

mkdir -p ~/server && cd ~/server
cat > CLAUDE.md <<'EOF'
# Regeln für diesen Server
- Dies ist ein Produktionsserver (Debian 13, nginx, PHP-FPM, MariaDB).
- Lesende Befehle (journalctl, systemctl status, tail, df, ss) sind jederzeit erlaubt.
- Vor jedem schreibenden Befehl kurz erklären, was er ändert, und auf Freigabe warten.
- Nie Pakete entfernen, nie Dateien unter /var/lib löschen, nie Benutzer anlegen oder löschen.
- Passwörter, Schlüssel und Kundendaten nie in Ausgaben wiederholen.
- Am Ende jeder Aufgabe eine Zusammenfassung in drei Sätzen liefern.
EOF

Die Datei wächst mit. Immer wenn der Agent etwas anders macht, als Sie es wollen, gehört die Korrektur als neue Regel hinein. Nach einigen Wochen spiegelt sie die Arbeitsweise auf Ihrem Server ziemlich genau wider.

Die Allowlist in settings.json

Dazu kommt eine Allowlist der Werkzeuge, damit Claude Code lesende Befehle ohne Rückfrage ausführt und alles andere anfragt. Die Datei ~/.claude/settings.json gilt für den Benutzer:

mkdir -p ~/.claude
cat > ~/.claude/settings.json <<'EOF'
{
  "permissions": {
    "allow": [
      "Bash(sudo journalctl:*)",
      "Bash(sudo systemctl status:*)",
      "Bash(sudo tail:*)",
      "Bash(df:*)",
      "Bash(free:*)",
      "Bash(ss:*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(sudo rm:*)",
      "Bash(dd:*)",
      "Bash(mkfs:*)"
    ]
  }
}
EOF

Die Deny-Liste ist ein zusätzliches Netz, keine Mauer: Ein Befehl lässt sich auf viele Arten schreiben. Die eigentliche Grenze zieht die sudo-Allowlist aus Schritt 1, denn was der Benutzer nicht darf, darf auch der Agent nicht.

Die erste Aufgabe interaktiv

Jetzt die erste Aufgabe, interaktiv:

cd ~/server && claude
> Fasse die Fehler aus journalctl der letzten 24 Stunden zusammen und nenne die drei häufigsten Ursachen.

Unbeaufsichtigt per Cronjob

Und dieselbe Aufgabe unbeaufsichtigt, etwa als täglicher Cronjob um 7 Uhr, dessen Ergebnis per E-Mail kommt:

0 7 * * * cd /home/aiagent/server && /home/aiagent/.local/bin/claude -p "Fasse Fehler und Warnungen aus journalctl der letzten 24 Stunden zusammen. Nenne Dienst, Uhrzeit und wahrscheinliche Ursache." --allowedTools "Bash(sudo journalctl:*)" 2>&1 | mail -s "Tagesbericht Server" admin@example.com

Der Schalter -p startet Claude Code ohne interaktive Sitzung, --allowedTools begrenzt die Werkzeuge auf genau das, was der Lauf braucht. Schreibende Aktionen gehören nicht in unbeaufsichtigte Läufe. Wie Cronjobs grundsätzlich eingerichtet werden, steht im Beitrag Cronjob unter Linux einrichten.

Schritt 5: Codex CLI (ChatGPT) installieren und anmelden

Installation und Anmeldung

Codex CLI ist das Werkzeug von OpenAI, das die Modelle hinter ChatGPT auf die Kommandozeile bringt. Installation im selben Benutzerkonto:

npm install -g @openai/codex
codex --version

Die Anmeldung läuft mit dem ChatGPT-Konto (Plus, Pro oder Team): codex starten, „Sign in with ChatGPT" wählen und die angezeigte Adresse auf einem Gerät mit Browser öffnen. Für Skripte setzen Sie stattdessen einen API-Schlüssel aus der OpenAI-Plattform:

echo 'export OPENAI_API_KEY="sk-..."' >> ~/.bashrc
source ~/.bashrc

Sandbox und Genehmigungsmodus in config.toml

Codex bringt eine eigene Sandbox und einen Genehmigungsmodus mit. Beides wird in ~/.codex/config.toml festgelegt; für einen Produktionsserver ist diese Kombination sinnvoll:

mkdir -p ~/.codex
cat > ~/.codex/config.toml <<'EOF'
approval_policy = "on-request"
sandbox_mode = "workspace-write"
EOF

workspace-write erlaubt Schreibzugriffe nur im aktuellen Arbeitsverzeichnis, on-request lässt den Agenten für alles darüber hinaus um Erlaubnis fragen. Die Stufe danger-full-access hebt beides auf und gehört nicht auf ein Produktionssystem.

Regeln in AGENTS.md

Regeln wie in CLAUDE.md liest Codex aus einer Datei AGENTS.md im Arbeitsverzeichnis; Sie können denselben Inhalt verwenden:

cp ~/server/CLAUDE.md ~/server/AGENTS.md
cd ~/server && codex "Prüfe, ob alle aktivierten systemd-Dienste laufen, und liste die fehlgeschlagenen mit der letzten Fehlermeldung auf."

Für unbeaufsichtigte Läufe gibt es codex exec "Aufgabe", das Gegenstück zu claude -p.

Schritt 6: Gemini CLI als dritte Möglichkeit

Gemini CLI ist das Kommandozeilenwerkzeug von Google und funktioniert nach demselben Prinzip. Es läuft ebenfalls mit Node.js und wird im selben Benutzerkonto installiert:

npm install -g @google/gemini-cli
gemini --version

Beim ersten Start von gemini melden Sie sich mit einem Google-Konto an, für Skripte setzen Sie einen API-Schlüssel in der Umgebungsvariable GEMINI_API_KEY. Die Regeln liest Gemini CLI aus einer Datei GEMINI.md im Arbeitsverzeichnis, auch hier können Sie den Inhalt der CLAUDE.md übernehmen. Unbeaufsichtigte Läufe starten Sie mit gemini -p "Aufgabe". Welches der drei Werkzeuge Sie nutzen, ist vor allem eine Frage des Kontos, das Sie ohnehin haben: Die Arbeitsweise auf dem Server ist bei allen dreien gleich, und Sie können mehrere nebeneinander betreiben.

Alternative: Der Agent läuft auf Ihrem Rechner und arbeitet per SSH

Wer nichts auf dem Server installieren möchte, startet Claude Code oder Codex auf dem Laptop und lässt den Agenten Befehle über SSH absetzen. Dafür bekommt der Server einen eigenen SSH-Schlüssel des Agent-Benutzers, und in CLAUDE.md steht die Regel, alle Serverbefehle mit ssh aiagent@server voranzustellen. Das funktioniert für gelegentliche Wartung gut, längere Aufgaben und Cronjobs laufen aber besser direkt auf dem Server. Wie die SSH-Anbindung mit eigenem Schlüssel, Host-Alias und Freigaben im Detail aussieht und nach welchem Ablauf der Agent dann auf Produktivsystemen deployt, zeigt der Praxisbericht KI mit dem Server verbinden.

Schritt 7: Absichern und Grenzen setzen

• Snapshot oder Backup vor jeder Sitzung, in der etwas geändert werden soll. Die Backup-Strategie für Server zeigt, wie das automatisch läuft.
• Genehmigungsmodus anlassen. --dangerously-skip-permissions bei Claude Code und danger-full-access bei Codex sind für Wegwerf-VMs gedacht.
• Geheimnisse außerhalb des Zugriffs. Der Agent-Benutzer darf .env-Dateien, Datenbankpasswörter und Kundendaten nicht lesen können. Was er liest, geht zum Anbieter.
• Kostenlimit für jeden API-Schlüssel in der Konsole des Anbieters setzen.
• Nachvollziehbarkeit: etckeeper installieren, damit jede Änderung unter /etc in Git landet, und die Zusammenfassungen des Agenten aufheben.
• Eingehend ändert sich nichts. Beide Werkzeuge brauchen nur ausgehendes HTTPS. Firewall, Fail2ban und der DDoS-Schutz des Hosters bleiben unverändert.

Die ersten Aufgaben: fünf sinnvolle Aufträge

Die besten ersten Aufgaben sind solche, die viel Lesen und kein Risiko bedeuten. Sie zeigen schnell, wie gründlich der Agent arbeitet, und liefern sofort einen Nutzen:

• Logbericht: „Fasse die Fehler und Warnungen der letzten 24 Stunden zusammen, gruppiert nach Dienst, mit der wahrscheinlichen Ursache."
• Dienste prüfen: „Liste alle fehlgeschlagenen systemd-Dienste mit der letzten Fehlermeldung auf und erkläre, was jeweils zu tun wäre. Ändere nichts."
• Speicherplatz: „Zeige, welche Verzeichnisse am meisten Platz belegen, und schlage vor, was gefahrlos aufgeräumt werden kann." Hintergrund dazu im Beitrag Festplatte voll unter Linux.
• Updates: „Welche Pakete haben ausstehende Sicherheitsupdates, und welche Dienste müssen danach neu gestartet werden?"
• Webserver: „Prüfe die nginx-Konfiguration auf Fehler und veraltete Einstellungen und erkläre jede Fundstelle."

Erst wenn diese Analysen stimmen, lohnt es sich, dem Agenten schreibende Aufgaben zu geben, und zwar zuerst auf einem Testsystem.

Typische Fehler und Lösungen

Die Werkzeuge aktuell halten

Claude Code aktualisiert sich nach der Installation mit dem nativen Installer selbst. Die über npm installierten Werkzeuge bringen Sie mit einem Befehl auf den neuesten Stand:

npm update -g @openai/codex @google/gemini-cli
codex --version
gemini --version

Neue Versionen ändern gelegentlich Schalter oder Standardeinstellungen. Lesen Sie nach einem Update kurz die Änderungshinweise, bevor Sie unbeaufsichtigte Läufe weiterlaufen lassen, und prüfen Sie den nächsten Tagesbericht auf Auffälligkeiten.

Fazit

Ein KI-Agent auf dem Server ist in einer Stunde eingerichtet: Benutzer, sudo-Allowlist, Node.js, Werkzeug, Regeln. Die eigentliche Arbeit steckt in den Grenzen, und die sind hier bewusst eng gezogen. Erweitern Sie sie Schritt für Schritt, wenn eine Aufgabe es verlangt, nie pauschal. Auf einem KernelHost-Rootserver oder Dedicated Server ist dafür nichts freizuschalten: Root-Zugriff, freie Distributionswahl und ausgehende Verbindungen sind Standard.

Wie ein Agent danach auf Produktivsystemen deployt, mit Sicherung, Rückweg und Freigaben, beschreibt der Praxisbericht KI mit dem Server verbinden.

Kurz zusammengefasst

• Claude Code, Codex CLI und Gemini CLI laufen auf jedem Linux-Server mit Node.js 22, eine GPU ist nicht nötig.
• Der Agent bekommt einen eigenen Benutzer mit sudo-Allowlist und läuft nie als root.
• Regeln stehen in CLAUDE.md, AGENTS.md oder GEMINI.md, lesende Befehle kommen in die Allowlist, alles andere braucht eine Freigabe.
• Für Cronjobs und Skripte ist ein API-Schlüssel mit Ausgabenlimit der saubere Weg, unbeaufsichtigte Läufe bleiben lesend.
• Backup vor jeder Sitzung, Geheimnisse außerhalb des Zugriffs, Genehmigungsmodus an.
• Auf KernelHost-Servern sind Root-Zugriff, freie Distributionswahl und ausgehende Verbindungen ab Werk vorhanden.