Codex CLI & Codex Remote Control unter Linux: Installation, Konfiguration und Remote-Zugriff 2026

OpenAI Codex muss längst nicht mehr nur im Browser oder in einer Entwicklungsumgebung verwendet werden. Mit der Codex CLI arbeitet der Coding-Agent direkt im Linux-Terminal, kann vorhandene Projekte analysieren, Dateien verändern, Befehle ausführen und Entwicklungsaufgaben automatisieren.

Noch interessanter wird es mit Codex Remote Control und den inzwischen verfügbaren Remote-Workflows. Codex kann auf Entwicklungsrechnern und entfernten Systemen arbeiten, während Aufgaben von einem anderen Gerät verfolgt, ergänzt oder freigegeben werden.

Gerade für Systemadministratoren, Linux-Nutzer und Entwickler mit eigenen Servern entsteht dadurch ein mächtiges Werkzeug. Allerdings gibt es dabei eine wichtige Besonderheit:

Codex CLI unter Linux und Codex Remote sind zwei unterschiedliche Komponenten.

Und genau an dieser Stelle entstehen aktuell viele Missverständnisse. In dieser Anleitung installieren wir deshalb nicht nur die Codex CLI vollständig unter Debian und Ubuntu, sondern konfigurieren sie sicher und betrachten anschließend die verschiedenen Möglichkeiten, einen Linux-Rechner oder Linux-Server in einen Codex-Remote-Workflow einzubinden.

Wer die Codex CLI noch nicht kennt, findet die reine Installation und Grundnutzung ausführlich im Artikel Codex CLI unter Linux installieren und richtig nutzen (Zum Artikel). Dieser Spezial-Beitrag hier baut darauf auf und konzentriert sich auf sichere Konfiguration sowie den Remote- und Smartphone-Workflow.

Was ist die Codex CLI?

Die Codex CLI ist der Terminal-Client von OpenAI Codex. Codex kann damit direkt innerhalb eines lokalen Repositorys arbeiten. Der Agent kann Dateien untersuchen, Änderungen durchführen, lokale Entwicklungswerkzeuge verwenden und Befehle starten. Zusätzlich unterstützt die CLI beispielsweise interaktive Sitzungen, Code Reviews, Websuche, MCP-Server, Plugins, Skills und automatisierte Aufrufe über codex exec.

Ein typischer Aufruf sieht zunächst ganz unspektakulär aus:

cd ~/projekte/meine-app
codex

Danach befindet man sich jedoch nicht einfach in einem gewöhnlichen Chat. Codex kennt das aktuelle Arbeitsverzeichnis und kann – abhängig von den vergebenen Berechtigungen – direkt mit den darin enthaltenen Dateien und Werkzeugen arbeiten. Das macht Codex besonders interessant für Softwareentwicklung, Linux-Administration, Fehlersuche, Code Reviews, Refactoring, Tests, Dokumentation, Git-Workflows, CI/CD, Automatisierung, Serveradministration und DevOps-Aufgaben.

Codex CLI und Codex Remote Control: Wo liegt der Unterschied?

Bevor wir mit der Installation beginnen, müssen wir drei Begriffe voneinander trennen.

1. Codex CLI

Die CLI läuft direkt auf dem jeweiligen System: Linux → Codex CLI → Projektdateien, Git, Shell, Compiler, Tests, lokale Tools. Codex arbeitet also dort, wo auch das Repository beziehungsweise die Infrastruktur liegt.

2. Codex Remote

Codex Remote ist die Benutzeroberfläche, mit der laufende Codex-Arbeit von anderen Geräten aus verfolgt und gesteuert werden kann. OpenAI beschreibt unter anderem folgende Möglichkeiten: Aufgaben starten, laufende Aufgaben beobachten, Rückfragen beantworten, Befehle freigeben, Ergebnisse überprüfen, Diffs ansehen, Modelle wechseln und weitere Anweisungen senden.

Dabei bleiben Dateien, Zugangsdaten, Berechtigungen und Entwicklungswerkzeuge auf dem ausführenden Rechner. Zwischen den autorisierten Geräten wird der Status über eine sichere Relay-Infrastruktur übertragen.

3. codex remote-control

Zusätzlich enthält die Codex CLI inzwischen einen eigenen Befehl: codex remote-control. Die aktuelle OpenAI-Dokumentation kennzeichnet ihn jedoch als Experimental.

Verfügbar sind unter anderem codex remote-control (Remote Control im Vordergrund starten), codex remote-control start (den lokalen Codex App-Server als Daemon mit aktiviertem Remote Control starten), codex remote-control stop (den Dienst wieder stoppen) und codex remote-control pair (einen kurzlebigen Pairing-Code erzeugen).

Das klingt zunächst so, als könne man damit jeden Linux-Server direkt mit der ChatGPT-App koppeln. Ganz so einfach ist es derzeit jedoch nicht.

Funktioniert Codex Remote Control direkt auf Linux?

Hier ist der Stand im August 2026 besonders wichtig. Die offizielle OpenAI-Anleitung für den normalen Remote-Workflow nennt aktuell macOS und Windows als unterstützte Remote-Hosts. Die Einrichtung mit einem Smartphone beginnt dort in der ChatGPT-Desktop-App und ausdrücklich nicht über die Codex CLI oder IDE-Erweiterung.

Das bedeutet: Smartphone (Codex Remote) → Mac/Windows mit ChatGPT Desktop → SSH → Linux-Server (Codex CLI). Dieser Aufbau ist derzeit der dokumentierte und besonders interessante Weg, einen Linux-Server remote mit Codex zu verwenden.

OpenAI dokumentiert gleichzeitig den experimentellen CLI-Befehl codex remote-control, der von verwalteten Remote-Control-Clients und SSH-Remote-Workflows verwendet wird. Daraus folgt: codex remote-control sollte unter Linux aktuell nicht automatisch mit dem vollständig unterstützten Smartphone-Remote-Setup gleichgesetzt werden. Da diese Funktion aktiv weiterentwickelt wird, kann sich das künftig ändern.

Voraussetzungen für Codex unter Linux

Für unsere Installation benötigen wir lediglich ein aktuelles Linux-System mit Internetzugang. Diese Anleitung eignet sich beispielsweise für Debian, Ubuntu, Linux Mint, Proxmox-basierte Entwicklungsmaschinen, virtuelle Linux-Server, VPS und dedizierte Entwicklungsserver.

Zunächst sollte das System aktualisiert werden:

sudo apt update
sudo apt upgrade -y

Hilfreiche Standardwerkzeuge:

sudo apt install curl git openssh-client ca-certificates -y

Für einen Server, auf den später per SSH zugegriffen werden soll, benötigen wir zusätzlich:

sudo apt install openssh-server -y

Anschließend prüfen:

systemctl status ssh

Codex CLI unter Linux installieren

OpenAI empfiehlt für Linux inzwischen einen Standalone-Installer:

curl -fsSL https://chatgpt.com/codex/install.sh | sh

Der gleiche Installer kann später auch zum Aktualisieren der CLI verwendet werden. Danach prüfen wir zunächst, ob der Befehl vorhanden ist:

codex --version

Falls Codex nach der Installation noch nicht gefunden wird, sollte zunächst eine neue Shell geöffnet beziehungsweise das Benutzerprofil neu geladen werden, beispielsweise mit source ~/.bashrc oder source ~/.profile. Anschließend: which codex.

Codex aktualisieren

Auch für ein Update kann der Installer erneut verwendet werden:

curl -fsSL https://chatgpt.com/codex/install.sh | sh
codex --version

Gerade bei Funktionen wie Remote Control lohnt es sich, Codex regelmäßig zu aktualisieren, da diese Bereiche derzeit aktiv weiterentwickelt werden.

Codex unter Linux anmelden

Für lokale Codex-Arbeit unterstützt OpenAI zwei grundlegende Authentifizierungsmethoden: Anmeldung über ChatGPT und Anmeldung über einen OpenAI API-Key. Die ChatGPT-Anmeldung eignet sich besonders für interaktive Nutzung, während API-Key-Authentifizierung beispielsweise für bestimmte Automatisierungs- und CI/CD-Szenarien interessant sein kann.

Variante 1: Anmeldung mit ChatGPT

codex login

Codex startet anschließend den Authentifizierungsprozess. Nach erfolgreicher Anmeldung kann der Status geprüft werden:

codex login status

Variante 2: Anmeldung mit API-Key

Der API-Key sollte niemals direkt als Klartext im Befehl gespeichert oder in Shell-Historien kopiert werden. Stattdessen beispielsweise:

export OPENAI_API_KEY="DEIN_API_KEY"
printenv OPENAI_API_KEY | codex login --with-api-key

OpenAI weist darauf hin, dass bei API-Key-Authentifizierung die API-Nutzung nach den normalen API-Tarifen abgerechnet wird und einige Funktionen, die einen ChatGPT-Workspace voraussetzen, eingeschränkt sein können.

Anmeldung überprüfen

codex login status

Abmelden:

codex logout

Wo speichert Codex die Konfiguration?

Die zentrale benutzerspezifische Konfiguration befindet sich unter Linux in ~/.codex/config.toml. Projektbezogene Einstellungen können zusätzlich innerhalb eines Repositorys unter .codex/config.toml gespeichert werden. Eine systemweite Linux-Konfiguration kann unter /etc/codex/config.toml liegen.

OpenAI verwendet eine Prioritätsreihenfolge aus Kommandozeilenparametern, Projektkonfiguration, Profilen, Benutzerkonfiguration, Systemkonfiguration und schließlich den eingebauten Standardwerten.

Codex unter Linux sicher konfigurieren

Wir erstellen zunächst das Konfigurationsverzeichnis:

mkdir -p ~/.codex
nano ~/.codex/config.toml

Für die meisten lokalen Entwicklungsumgebungen ist folgende Ausgangskonfiguration sinnvoll:

approval_policy = "on-request"
sandbox_mode = "workspace-write"

cli_auth_credentials_store = "auto"

web_search = "cached"

Damit erhält Codex genügend Möglichkeiten für normale Entwicklungsarbeiten, ohne sofort uneingeschränkten Zugriff auf das komplette System zu bekommen.

Was bedeutet sandbox_mode?

Der Sandbox-Modus bestimmt, was Codex auf dem System tun darf. OpenAI unterscheidet unter anderem sandbox_mode = "read-only" (Codex darf Dateien lesen, aber nicht einfach verändern), sandbox_mode = "workspace-write" (Codex kann innerhalb des Arbeitsbereichs Dateien bearbeiten und typische lokale Befehle ausführen) und sandbox_mode = "danger-full-access" (die Sandbox-Grenzen werden aufgehoben).

OpenAI empfiehlt für normale lokale Automatisierung die Kombination sandbox_mode = "workspace-write" mit approval_policy = "on-request" anstatt uneingeschränkten Vollzugriff zu vergeben.

Warum danger-full-access problematisch ist

Folgende Konfiguration:

sandbox_mode = "danger-full-access"
approval_policy = "never"

bedeutet praktisch: Der Agent darf ohne Sandbox und ohne vorherige Rückfrage arbeiten. Auf einem Entwicklungscontainer kann das in besonderen Fällen akzeptabel sein. Auf einem produktiven Linux-Server wäre es jedoch eine ausgesprochen weitreichende Berechtigung – besonders gefährlich, wenn der entsprechende Benutzer Zugriff besitzt auf /etc, /var, /root, Docker, Kubernetes, Datenbanken, SSH Keys, Cloud Credentials, Produktionssysteme oder Backups.

Der bessere Ansatz lautet: Nicht Codex mehr Rechte geben, sondern Codex innerhalb einer sinnvoll begrenzten Umgebung arbeiten lassen.

Warum die Linux-Sandbox besonders interessant ist

Unter Linux setzt Codex für seine Sandbox aktuell standardmäßig unter anderem auf Bubblewrap (bwrap) und seccomp. Dadurch werden Aktionen nicht lediglich durch die Anweisungen des KI-Modells begrenzt, sondern zusätzlich auf Betriebssystemebene eingeschränkt. Die aktive Sandbox kann sogar getestet werden:

codex sandbox linux

Das ist besonders für Administratoren interessant, die genau nachvollziehen möchten, welche Grenzen tatsächlich greifen.

Empfohlene Codex-Konfiguration für Linux

Für einen normalen Entwicklungsserver würde ich beispielsweise mit folgender Konfiguration beginnen:

approval_policy = "on-request"
approvals_reviewer = "user"

sandbox_mode = "workspace-write"

allow_login_shell = false

cli_auth_credentials_store = "auto"

web_search = "cached"

[sandbox_workspace_write]
network_access = false

Die Idee dahinter: Änderungen im Projekt sind erlaubt, Aktionen außerhalb der Sandbox müssen genehmigt werden, Netzwerkzugriffe für ausgeführte Programme sind zunächst deaktiviert, Login-Shells werden zusätzlich eingeschränkt und kritische Entscheidungen bleiben beim Benutzer. OpenAI beschreibt workspace-write zusammen mit on-request ebenfalls als risikoärmere Konfiguration für lokale Automatisierung.

Erstes Projekt mit Codex öffnen

Jetzt erstellen oder öffnen wir ein Repository:

mkdir -p ~/projects
cd ~/projects
git clone https://example.com/mein-projekt.git
cd mein-projekt
codex

Innerhalb der Codex CLI stehen verschiedene Kommandos zur Verfügung: /status zeigt die aktuelle Konfiguration, /permissions zeigt beziehungsweise verändert Berechtigungen, /model ermöglicht die Modellauswahl und /review startet einen Code Review.

OpenAI empfiehlt außerdem, vor umfangreicheren Agentenaufgaben Git-Checkpoints zu verwenden, damit Änderungen zuverlässig zurückgesetzt werden können.

AGENTS.md erstellen

Eine meiner wichtigsten Empfehlungen für Codex ist eine Projektanweisung. Innerhalb Codex mit /init kann eine AGENTS.md angelegt werden, in der sich Projektregeln dokumentieren lassen. Beispielsweise:

# Projektregeln

- Produktionssysteme niemals automatisch verändern.
- Vor Datenbankänderungen immer Backup prüfen.
- Keine Zugangsdaten in Git speichern.
- Vor Git Commit Tests ausführen.
- Bestehende APIs nicht ohne ausdrückliche Anweisung verändern.
- Keine Änderungen außerhalb dieses Repositorys durchführen.
- Bei riskanten Änderungen zuerst einen Plan erstellen.

Gerade bei größeren Projekten ist eine solche Datei enorm wertvoll.

Codex Remote Control auf Linux prüfen

Nach der Installation können wir prüfen, ob die aktuelle CLI Remote Control enthält:

codex remote-control --help

Der direkte Start erfolgt mit codex remote-control. Der Prozess läuft dann im Vordergrund.

Codex Remote Control als Daemon starten

Alternativ:

codex remote-control start

Danach kann der Dienst wieder beendet werden:

codex remote-control stop

OpenAI beschreibt diese Funktion derzeit ausdrücklich als experimentell. Deshalb würde ich sie auf produktiven Systemen aktuell nicht als kritische Infrastruktur voraussetzen.

Pairing-Code erzeugen

Wenn der Remote-Control-Daemon läuft, kann ein kurzlebiger Pairing-Code erzeugt werden:

codex remote-control pair

Für Skripte oder automatisierte Verarbeitung kann auch JSON ausgegeben werden:

codex remote-control pair --json

Laut OpenAI enthält die JSON-Ausgabe unter anderem pairingCode, manualPairingCode, environmentId und expiresAt.

Wichtig bleibt jedoch: Der dokumentierte Smartphone-Remote-Workflow wird derzeit über die ChatGPT-Desktop-App eingerichtet und nicht direkt über die Linux-Codex-CLI.

Die derzeit sinnvollste Remote-Architektur für Linux

Für Administratoren ist deshalb aktuell folgende Architektur besonders interessant: Ein Smartphone mit ChatGPT-App und Codex Remote verbindet sich über einen sicheren Relay mit einem Mac oder Windows-Rechner, auf dem die ChatGPT-Desktop-App mit Codex läuft. Von dort führt eine SSH-Verbindung zum eigentlichen Linux-Server mit Debian oder Ubuntu, auf dem die Codex CLI zusammen mit Git und den Projekten liegt.

Damit befindet sich das eigentliche Projekt weiterhin auf Linux. Der Mac- oder Windows-Rechner dient lediglich als Remote-Gateway beziehungsweise Desktop-Host.

Linux-Server für Codex Remote über SSH vorbereiten

Auf dem Linux-Server:

sudo apt update
sudo apt install openssh-server git curl -y

SSH aktivieren:

sudo systemctl enable --now ssh
systemctl status ssh

Anschließend Codex installieren und anmelden:

curl -fsSL https://chatgpt.com/codex/install.sh | sh
codex login

Das ist wichtig, weil die Desktop-App beim Zugriff auf einen SSH-Host den Codex App Server auf diesem Remote-System startet. Der Befehl codex muss deshalb innerhalb der Login-Shell des Remote-Benutzers im PATH vorhanden sein.

Eigenen Benutzer für Codex verwenden

Für Server empfehle ich dringend, nicht direkt als root mit Codex zu arbeiten. Stattdessen:

sudo adduser codex
sudo mkdir -p /srv/codex-projects
sudo chown codex:codex /srv/codex-projects

root verwaltet weiterhin System und Dienste, während ein separater Benutzer codex-user ausschließlich für die Entwicklungsprojekte zuständig ist. Damit können wir die Rechte des Agenten bereits auf Betriebssystemebene erheblich begrenzen.

SSH-Key für den Codex-Server einrichten

Auf dem Client:

ssh-keygen -t ed25519

Public Key übertragen:

ssh-copy-id codex@server.example.com

Danach testen:

ssh codex@server.example.com

Passwortloser Zugriff über SSH-Key ist für diesen Workflow wesentlich sinnvoller als ständig Passwörter einzugeben.

SSH-Konfiguration anlegen

Auf dem Rechner mit der ChatGPT-Desktop-App:

nano ~/.ssh/config

Beispiel:

Host codex-dev
    HostName server.example.com
    User codex
    IdentityFile ~/.ssh/id_ed25519

Danach:

ssh codex-dev

OpenAI verwendet genau solche konkreten SSH-Aliase zur automatischen Erkennung von Remote-Hosts.

Linux-Server in Codex hinzufügen

In der ChatGPT-Desktop-App: Settings → Connections → SSH → Add. Danach den zuvor angelegten SSH-Host auswählen. Anschließend kann beispielsweise ein Projektverzeichnis wie /srv/codex-projects/meine-app verwendet werden.

Die Codex-Unterhaltung läuft dann gegen das Remote-Dateisystem, die Remote-Shell, die dort installierten Werkzeuge und die dort vorhandenen Dependencies. OpenAI beschreibt ausdrücklich, dass Remote-Projekt-Chats auf dem entfernten Host Befehle ausführen sowie Dateien lesen und verändern können.

Jetzt kommt das Smartphone ins Spiel

Der Smartphone-Zugriff wird auf dem unterstützten Desktop-Host eingerichtet. In der ChatGPT-Desktop-App: Settings → Connections → Control this Mac or PC → Set up / Add. Daraufhin wird ein QR-Code angezeigt, den man mit dem Smartphone scannt. Beide Geräte müssen mit demselben ChatGPT-Konto beziehungsweise Workspace verbunden sein. Danach erscheint der Host im Bereich Remote der ChatGPT-App.

Ergebnis: Linux-Entwicklung vom Smartphone steuern

Damit wird ein beeindruckender Workflow möglich. Du sitzt beispielsweise nicht mehr am Arbeitsplatz und entdeckst einen Fehler. Über das Smartphone startest du:

Analysiere den Fehler im Backend. Prüfe zuerst die Logs und die letzten Git-Änderungen. Führe noch keine Änderungen durch, sondern erkläre mir zunächst die wahrscheinlichste Ursache.

Codex arbeitet dabei auf dem Linux-Server. Anschließend könnte Codex einen Fix vorbereiten. Wenn eine Aktion eine Freigabe benötigt, kann diese ebenfalls remote überprüft werden. OpenAI beschreibt Remote ausdrücklich als Möglichkeit, Aufgaben vom Smartphone aus zu starten, Fortschritte zu verfolgen, Aktionen freizugeben und Diffs sowie Testergebnisse zu überprüfen.

Sicherheitsregel Nummer 1: Kein root

Ein häufiger Fehler bei KI-Agenten lautet sudo codex. Das ist auf einem Server selten eine gute Idee. Codex sollte nur genau auf die Bereiche zugreifen können, die für seine Aufgabe notwendig sind.

Sicherheitsregel Nummer 2: Produktionssysteme trennen

Ein professioneller Aufbau könnte so aussehen: Codex → Development → Tests → Git Commit → Staging → Review → Deployment → Production. Nicht: Codex → Production.

Gerade Remote Control verleitet dazu, Aufgaben schnell vom Smartphone aus freizugeben. Doch eine Freigabe auf dem Handy bleibt technisch betrachtet eine Freigabe für einen echten Befehl auf einem echten System.

Sicherheitsregel Nummer 3: Git verwenden

Vor umfangreichen Änderungen:

git status
git add .
git commit -m "Checkpoint before Codex changes"

Jetzt Codex arbeiten lassen. Danach:

git diff
git status

Erst danach committen.

Sicherheitsregel Nummer 4: Keine öffentlichen App-Server

Für Remote-Systeme gilt außerdem: Den Codex App Server nicht einfach mit einem öffentlichen Port ins Internet stellen. OpenAI empfiehlt für Remote-Verbindungen SSH beziehungsweise sichere Netzwerkmechanismen und warnt davor, App-Server-Transporte unauthentifiziert auf gemeinsam genutzten oder öffentlichen Netzwerken bereitzustellen. Für entfernte Netzwerke werden VPN- beziehungsweise Mesh-Networking-Lösungen einem direkt öffentlich erreichbaren App-Server vorgezogen.

Also nicht: Internet → Port 4500 → Codex App Server. Besser: VPN/SSH → Linux-Server → Codex.

Credentials unter Linux absichern

OpenAI kann Codex-Anmeldedaten unter anderem unter ~/.codex/auth.json speichern. Diese Datei enthält sensible Authentifizierungsinformationen und muss wie ein Passwort behandelt werden. OpenAI unterstützt außerdem die Konfiguration eines Credential Stores über cli_auth_credentials_store. Deshalb bietet sich cli_auth_credentials_store = "auto" an, oder – sofern vom jeweiligen System unterstützt – cli_auth_credentials_store = "keyring".

Headless Linux-Server ohne Browser anmelden

Gerade bei Servern gibt es häufig keinen grafischen Browser. OpenAI dokumentiert dafür mehrere Möglichkeiten, unter anderem die Weiterleitung des lokalen Authentifizierungsports über SSH. Vom lokalen Rechner:

ssh -L 1455:localhost:1455 user@server

Innerhalb dieser SSH-Sitzung:

codex login

Anschließend kann der angezeigte Login im lokalen Browser durchgeführt werden. Alternativ lässt sich auf vertrauenswürdigen Systemen ein bereits vorhandener Authentifizierungs-Cache übertragen. Da auth.json Zugangstoken enthält, sollte diese Datei jedoch niemals in Git gespeichert oder ungeschützt weitergegeben werden.

Typische Codex-Konfiguration für einen Development-Server

approval_policy = "on-request"
approvals_reviewer = "user"

sandbox_mode = "workspace-write"

allow_login_shell = false

cli_auth_credentials_store = "auto"

web_search = "cached"

[sandbox_workspace_write]
network_access = false

Damit haben wir eine relativ kontrollierte Ausgangslage.

Netzwerkzugriff nur bei Bedarf erlauben

Manche Projekte benötigen npm install, pip install oder beispielsweise apt-cache. Für ausgeführte Prozesse kann deshalb Netzwerkzugriff notwendig sein. Codex unterstützt dafür feinere Netzwerkregeln und Berechtigungsprofile. OpenAI empfiehlt grundsätzlich, Netzwerkzugriff möglichst gezielt freizugeben, anstatt der Sandbox pauschal vollständigen Zugriff zu geben. Das ist insbesondere relevant, wenn das Repository fremde oder potenziell manipulierte Inhalte enthält.

Codex niemals blind fremde Repositories ausführen lassen

Ein Repository kann nicht nur Quellcode enthalten. Darin können sich beispielsweise AGENTS.md, README, Shell-Skripte, Installationsskripte, package.json, Makefiles, CI-Konfigurationen oder MCP-Konfigurationen befinden. Ein kompromittiertes Projekt könnte versuchen, einen Agenten zu unerwünschten Aktionen zu bewegen.

Deshalb gilt auch für KI-Agenten das klassische Prinzip: Unbekannter Code bleibt unbekannter Code. Codex ersetzt keine Sicherheitsprüfung.

Sehr praktische Einsatzmöglichkeiten für Codex Remote unter Linux

Serverlogs analysieren

Analysiere die Fehler der letzten 30 Minuten in den Logs. Verändere noch nichts. Erstelle zuerst: 1. Fehlerursache, 2. betroffenen Dienst, 3. mögliche Folgen, 4. vorgeschlagenen Fix.

Docker-Probleme untersuchen

Prüfe den aktuellen Docker-Status und analysiere, warum der Container backend nicht startet. Keine Container löschen und keine Volumes verändern.

systemd-Fehler analysieren

Analysiere den Dienst nginx.service. Nutze systemctl und journalctl. Verändere keine Konfiguration, bevor du mir die Ursache erklärt hast.

Git-Änderungen prüfen

Analysiere alle Änderungen seit dem letzten Commit. Suche nach Bugs, Sicherheitsproblemen, Breaking Changes und fehlenden Tests.

Deployment vorbereiten

Prüfe, ob der aktuelle Branch bereit für Staging ist. Führe Tests aus und kontrolliere die Konfiguration. Kein Deployment durchführen.

Gerade diese letzte Anweisung ist entscheidend. Ein Agent muss nicht automatisch jeden möglichen Schritt durchführen.

Kann Codex Remote einen Linux-Server komplett administrieren?

Technisch kann Codex mit den Rechten des entsprechenden Benutzers sehr weitreichende Aufgaben durchführen. Ob Codex beispielsweise systemctl restart nginx ausführen kann, hängt von Sandbox, Benutzerrechten und Freigaben ab. Hat der Benutzer außerdem uneingeschränktes sudo, kann daraus schnell praktisch vollständiger Serverzugriff werden.

Für professionelle Umgebungen wäre daher beispielsweise eine beschränkte sudo-Konfiguration wesentlich sinnvoller. Etwa: codex darf systemctl status, journalctl und bestimmte Test-Skripte ausführen. Codex darf dagegen nicht userdel, rm auf Systemverzeichnissen, die Firewall deaktivieren, die SSH-Konfiguration verändern oder Produktionsdatenbanken löschen. Das Prinzip der minimal notwendigen Rechte – Least Privilege – wird durch KI-Agenten noch wichtiger.

Codex Remote ist kein SSH-Ersatz

Codex Remote sollte nicht als Ersatz für klassische Administration betrachtet werden. Besser ist die Kombination aus SSH, Git, Monitoring, Backups, Codex und Freigaberegeln. Codex ist dabei der intelligente Assistent innerhalb einer kontrollierten Umgebung – nicht die Sicherheitsarchitektur selbst.

Remote Control in Unternehmen

Bei Business- und Enterprise-Umgebungen kommen zusätzliche Richtlinien hinzu. OpenAI ermöglicht Administratoren unter anderem, Remote Control über Anforderungen beziehungsweise Workspace-Richtlinien zu beschränken. Beispielsweise existiert die Einstellung allow_remote_control = false, mit der Remote Control für verwaltete Benutzer deaktiviert werden kann. Auch Sandbox-Modi und Approval Policies können zentral eingeschränkt werden. Das ist besonders wichtig, wenn Codex auf internen Git-Repositories, Produktionscode, Kundendaten, Unternehmensservern oder CI/CD-Systemen verwendet wird.

Ist Codex Remote Control unter Linux schon produktionsreif?

Hier muss man unterscheiden. Die Codex CLI selbst ist ein regulärer Bestandteil der Codex-Plattform. Der CLI-Befehl codex remote-control wird in der aktuellen Entwicklerdokumentation hingegen weiterhin als Experimental geführt. Der normale Codex-Remote-Workflow über die ChatGPT-App ist inzwischen deutlich weiter entwickelt und unterstützt Remote-Aufgaben, Freigaben sowie SSH-basierte Entwicklungsumgebungen.

Für einen produktiven Linux-Workflow würde ich deshalb derzeit bevorzugen: ChatGPT Desktop → SSH → Linux Development Server → Codex CLI, anstatt einen experimentellen App Server direkt öffentlich bereitzustellen.

Meine empfohlene Architektur für Administratoren

Für einen kleinen bis mittleren Entwicklungsbetrieb könnte ein guter Aufbau so aussehen: Smartphone (ChatGPT Remote) → Admin-Workstation (ChatGPT Desktop) → SSH-Key → Linux-Dev-Server mit eigenem Benutzer codex, Codex CLI, Git und Docker, → Testumgebung → Staging → manuelle Freigabe → Production.

Damit verbinden wir die Geschwindigkeit eines Coding-Agenten mit klassischen Sicherheitsmechanismen.

Häufige Fehler bei Codex unter Linux

codex: command not found

Prüfen: which codex. Anschließend neue Shell starten oder source ~/.bashrc.

Anmeldung funktioniert auf dem Server nicht

Bei Headless-Systemen kann ein SSH-Port-Forwarding des Login-Callbacks helfen: ssh -L 1455:localhost:1455 user@server, danach codex login.

Remote-Host wird nicht gefunden

SSH-Konfiguration prüfen mit cat ~/.ssh/config, danach ssh codex-dev. Der Host muss zunächst mit dem normalen OpenSSH-Client erreichbar sein.

Codex ist über SSH nicht im PATH

Test: ssh codex-dev 'which codex'. Erwartet wird ein gültiger Pfad. Wenn nichts zurückgegeben wird, ist Codex in der Login-Shell des Remote-Benutzers nicht verfügbar – genau diese Voraussetzung nennt OpenAI für SSH-basierte Codex-Projekte.

Fazit: Codex CLI und Remote Control machen Linux zum KI-Arbeitsplatz

Mit der Codex CLI wird OpenAI Codex auf Linux zu weit mehr als einem Chatbot. Der Agent kann direkt mit Quellcode, Git, Shell-Befehlen, Tests, Build-Systemen, Logs und Entwicklungswerkzeugen arbeiten.

Richtig interessant wird es jedoch durch Remote-Workflows. Ein Linux-Server kann über SSH in Codex eingebunden werden, während Aufgaben anschließend beispielsweise über einen unterstützten Desktop-Host und die ChatGPT-App vom Smartphone aus überwacht, ergänzt und freigegeben werden können.

Für Systemadministratoren eröffnet das völlig neue Möglichkeiten. Gleichzeitig wächst aber auch die Verantwortung. Wer einem KI-Agenten Shell-Zugriff gibt, sollte dieselben Regeln anwenden wie bei jedem anderen administrativen Werkzeug: Least Privilege, Git, Backups, Sandbox, getrennte Entwicklungsumgebungen und kontrollierte Freigaben.

Die spannendste Entwicklung dürfte deshalb weniger sein, ob Codex noch mehr Befehle ausführen kann. Entscheidend wird sein, wie sicher wir KI-Agenten in unsere reale Infrastruktur integrieren.

Wie MCP dabei kontrolliert zusätzliche Werkzeuge und Datenquellen anbindet, erklärt der Artikel MCP einfach erklärt: Was ist das Model Context Protocol? (Zum Artikel).

FAQ: Codex CLI und Remote Control unter Linux

Läuft OpenAI Codex auf Linux?

Ja. Die Codex CLI kann direkt unter Linux installiert werden und arbeitet dort im Terminal mit lokalen Projekten, Git und vorhandenen Entwicklungswerkzeugen.

Wie installiere ich Codex CLI unter Ubuntu?

Mit dem offiziellen Standalone-Installer: curl -fsSL https://chatgpt.com/codex/install.sh | sh

Funktioniert Codex CLI auch unter Debian?

Ja. Die Codex CLI läuft unter Linux und kann auf einem Debian-System über den Linux-Installer eingerichtet werden.

Kann ich Codex vom Smartphone aus steuern?

Codex Remote ermöglicht das Starten, Begleiten und Freigeben von Codex-Arbeit über die ChatGPT-App. Der aktuell dokumentierte direkte Remote-Host-Workflow verwendet dafür die ChatGPT-Desktop-App auf macOS oder Windows.

Kann das eigentliche Projekt trotzdem auf Linux liegen?

Ja. Die ChatGPT-Desktop-App kann per SSH mit einem Linux-Host verbunden werden. Codex arbeitet anschließend mit dessen Dateisystem und Shell.

Was macht codex remote-control?

Der Befehl startet beziehungsweise verwaltet den lokalen Codex App Server mit Remote-Control-Funktion. OpenAI kennzeichnet diesen CLI-Befehl derzeit als experimentell.

Wie starte ich Codex Remote Control?

Im Vordergrund mit codex remote-control, als Daemon mit codex remote-control start, beenden mit codex remote-control stop.

Wie erzeuge ich einen Pairing-Code?

Mit codex remote-control pair, oder als JSON mit codex remote-control pair --json.

Sollte Codex als root laufen?

Für normale Entwicklungs- und Serveraufgaben sollte Codex nach Möglichkeit mit einem separaten Benutzer und minimal erforderlichen Rechten betrieben werden.

Wo liegt die Codex-Konfiguration?

Benutzerspezifisch unter ~/.codex/config.toml, projektbezogen unter .codex/config.toml und systemweit unter Linux unter /etc/codex/config.toml.

Welche Sandbox-Einstellung ist sinnvoll?

Für normale Entwicklungsarbeiten bietet sich häufig sandbox_mode = "workspace-write" zusammen mit approval_policy = "on-request" an. OpenAI führt diese Kombination als risikoärmere lokale Automatisierungskonfiguration auf.

Quellen und Aktualität

Artikelstand und Faktenprüfung: 18. August 2026. Dieser Artikel basiert auf der aktuell verfügbaren offiziellen OpenAI-Dokumentation zu Codex CLI, Konfiguration, Sandbox, Authentifizierung, Remote Control und SSH-Remote-Verbindungen. Besonders bei codex remote-control ist zu beachten, dass OpenAI die CLI-Funktion derzeit noch als experimentell kennzeichnet und sich Funktionsumfang beziehungsweise unterstützte Plattformen entsprechend verändern können.