Betreiben Sie Codex CLI mit mehreren Repositorys nicht in einem gemeinsam genutzten Konto mit weitreichenden Rechten. Für den produktiven Betrieb brauchen Sie ein eigenes Systemkonto, getrennte Arbeitsbereiche pro Repository, eine standardmäßig restriktive Sandbox mit passender Genehmigungsstrategie sowie einen nachweisbaren Test für Dateien, Netzwerk, Zugangsdaten, Xcode und Wiederanlauf. Wenn Sie diese Grenzen nicht belegen können, bleibt nur ein einzelnes temporäres Repository oder ein getrennter Testknoten.

Für diese Entscheidung ist Codex CLI auf einem Remote Mac mit mehreren Repositories sicher abzunehmen keine Installationsaufgabe, sondern eine kontrollierte Freigabeprüfung.

Diese Woche: Erstellen Sie zunächst ein nicht produktives Test-Repository, frieren Sie die erwarteten Verzeichnisse und Zugangsdaten ein und dokumentieren Sie je Messgröße Prüfmethode, Beleg, Freigabekriterium und Abbruchbedingung.

Für wen diese Checkliste gedacht ist:
Professionelle Entwicklerinnen und Entwickler, die Codex CLI auf einem Remote Mac mehrere Repositorys bearbeiten, bauen oder testen lassen möchten, aber die Arbeitsbereichsgrenzen nicht zuverlässig einschätzen können.
DevOps- und Plattformteams, die dauerhaft laufende Mac-Knoten, Kontoberechtigungen, Bereinigung und Wiederanlauf verantworten.
Sicherheitsverantwortliche, die den tatsächlichen Zugriff auf Quellcode, Netzwerk, Keychain, Signaturmaterial und Xcode-Werkzeuge prüfen müssen.

Freigabestufe und Zeitplan

Die Abnahme sollte nicht mit der Frage „Startet Codex CLI?“ beginnen. Ein Prozess kann starten und trotzdem auf Dateien, Umgebungsvariablen oder Werkzeuge zugreifen, die außerhalb des vorgesehenen Repositorys liegen. Die relevante Einheit ist deshalb die nachweisbare Grenze zwischen Agent, Betriebssystemkonto, Arbeitsbereich und externem Dienst.

Meilenstein: Vorprüfung

Legen Sie vor dem ersten Lauf fest:

  • welches Test-Repository verwendet wird;
  • welche Arbeitsverzeichnisse lesbar sein müssen;
  • welche Verzeichnisse beschreibbar sein dürfen;
  • ob Netzwerkzugriff erforderlich ist;
  • welche Befehle Codex CLI ausführen darf;
  • ob Xcode, Simulator, Build-Skripte oder Signierung überhaupt Teil der Aufgabe sind;
  • welche Zugangsdaten ausdrücklich ausgeschlossen bleiben.

Verwenden Sie ausschließlich Platzhalter wie <TEST_REPOSITORY>, <REMOTE_USER>, <WORKSPACE_PATH>, <TOKEN_PLACEHOLDER>, <CERTIFICATE_PLACEHOLDER> und <TEAM_ID_PLACEHOLDER>. Produktionsschlüssel, reale Tokens und echte Team-IDs gehören nicht in eine Anleitung, ein Log oder einen Testlauf.

Die offizielle Codex-Dokumentation unterscheidet Sandbox, Genehmigungsstrategie und Netzwerkzugriff. Diese Einstellungen müssen Sie anhand der aktuell dokumentierten Konfiguration prüfen, statt aus einem erfolgreichen Lauf auf ausreichende Isolation zu schließen. Die offizielle Beschreibung von Sandbox und Genehmigungen ist dafür der Ausgangspunkt; die Dokumentation zu den Berechtigungen sollte unmittelbar vor der Abnahme gegengeprüft werden.

Meilenstein: Testlauf

Führen Sie denselben Prüfauftrag zunächst mit einem ungefährlichen Repository aus. Lassen Sie absichtlich eine Datei im erlaubten Arbeitsbereich lesen und ändern. Danach platzieren Sie eine eindeutig markierte, aber harmlose Kontroll-Datei außerhalb des Arbeitsbereichs. Der Test darf keinen produktiven Schlüssel und keine vertraulichen Quelldateien enthalten.

Sammeln Sie dabei:

  • die effektive Systembenutzerkennung;
  • den aufgelösten Arbeitsbereich;
  • die verwendeten Sandbox- und Genehmigungseinstellungen;
  • die ausgeführten Befehle;
  • Änderungen im Repository;
  • neue Dateien außerhalb des Arbeitsbereichs;
  • Netzwerk- und Tool-Anfragen;
  • Prozesse nach dem Ende des Auftrags.

Meilenstein: Entscheidung

Freigabe erteilen Sie erst, wenn jede Messgröße einen Beleg und ein reproduzierbares Ergebnis besitzt. Fehlt nur ein Beleg für eine kritische Grenze, wechseln Sie nicht einfach zu einer großzügigeren Genehmigung. Wechseln Sie stattdessen auf Einzel-Repository-Betrieb, einen separaten Knoten oder einen reinen Prüfmodus.

Datei- und Repository-Grenzen

Die zentrale Frage bei mehreren Repositorys lautet nicht, ob Codex CLI den gewünschten Ordner kennt. Sie müssen beweisen, dass der Agent andere Arbeitsbereiche weder unkontrolliert lesen noch verändern kann.

Wie begrenzen Sie Codex CLI auf das aktuelle Repository?
Verwenden Sie ein eigenes Arbeitsverzeichnis pro Auftrag, kontrollieren Sie den Systembenutzer und prüfen Sie die tatsächlich erlaubten Schreibpfade. Eine Anweisung wie „ändere nur dieses Repository“ ist keine Betriebssystemgrenze. Sie kann eine Absicht beschreiben, aber keinen Zugriff verhindern.

Prüfen Sie folgende Objekte getrennt:

  • Arbeitsverzeichnis und darüberliegende Verzeichnisse;
  • Git-Metadaten und alternative Git-Arbeitsbäume;
  • Projektdateien, lokale Konfigurationsdateien und Build-Skripte;
  • temporäre Verzeichnisse;
  • Cache- und Derived-Data-Verzeichnisse;
  • benachbarte Repositorys desselben Benutzers;
  • SSH-Konfigurationen und Umgebungsdateien.

Die Prüfmethode besteht aus einem kontrollierten Querzugriff. Lassen Sie Codex CLI im Test-Repository arbeiten, während ein zweites Repository eine unverwechselbare Kontroll-Datei enthält. Prüfen Sie anschließend Logs, Dateisystem und Git-Differenzen des zweiten Repositorys. Wiederholen Sie die Prüfung mit einem absichtlich angeforderten relativen Pfad außerhalb des Arbeitsbereichs.

Der Beleg besteht aus einem Vorher-Nachher-Dateibaum, dem Git-Diff des Test-Repositorys und dem Prozessprotokoll. Bestanden ist die Messgröße nur, wenn die erlaubten Änderungen im erwarteten Arbeitsbereich bleiben und der Zugriff auf das Kontroll-Repository entweder verweigert oder nachweisbar genehmigungspflichtig wird.

Abbruch ist erforderlich, sobald ein fremdes Repository gelesen oder verändert wird, ein temporäres Artefakt außerhalb der freigegebenen Zone verbleibt oder die tatsächliche Schreibgrenze von der dokumentierten Konfiguration abweicht. Verwenden Sie dann nicht einfach eine strengere Formulierung im Prompt. Isolieren Sie den Systembenutzer oder den Knoten.

Achtung: Eine lokale Codex-Sandbox, die Berechtigungen des macOS-Systemkontos und ein SSH-Agent sind unterschiedliche Kontrollschichten. Ein bestandener Test in einer Schicht ersetzt keinen Test der anderen.

Netzwerk- und Toolpfade

Netzwerkzugriff ist nicht dasselbe wie die Möglichkeit, einen externen Befehl auszuführen. Trennen Sie mindestens die Modellkommunikation, das Herunterladen von Abhängigkeiten, Git-Zugriffe, API-Aufrufe und externe Tool- oder MCP-Ausführung.

Ist ein deaktivierter Genehmigungsdialog ein Netzwerkbeweis?
Nein. Eine Genehmigungsstrategie entscheidet, wie Aktionen bestätigt oder blockiert werden. Sie beweist nicht, dass Netzwerkverkehr erlaubt ist. Die Netzwerkregel muss separat geprüft und dokumentiert werden.

Ihre Prüfung sollte in abgestuften Läufen erfolgen:

  • ein Lauf ohne erforderlichen externen Zugriff;
  • ein Lauf mit einem ausdrücklich erlaubten Ziel;
  • ein Lauf mit einem nicht erlaubten Ziel;
  • ein Git-Vorgang gegen ein Testziel;
  • ein Abhängigkeits- oder API-Aufruf mit Platzhalterdaten;
  • ein Versuch, ein nicht freigegebenes externes Werkzeug zu starten.

Dokumentieren Sie Ziel, Richtung, Ergebnis, Genehmigungsstatus und die verantwortliche Konfigurationsquelle. Die Codex-Dokumentation beschreibt Netzwerkoptionen und deren Verhältnis zur Sandbox; zusätzlich sollten Sie die offizielle Netzwerkbeschreibung im Codex-Repository mit der aktuell eingesetzten Konfiguration abgleichen.

Die Konfigurationsdefinition im offiziellen Quellcode ist bei konkreten Feldern hilfreicher als ein Blogbeitrag. Prüfen Sie vor der Freigabe, ob ein Feld in der verwendeten Version tatsächlich existiert und welche Standardwirkung dokumentiert ist. Schreiben Sie keine Konfigurationsschlüssel aus älteren Beispielen ungeprüft in Ihre Produktionsautomation.

Bestanden ist die Messgröße, wenn ein erforderlicher Zugriff funktioniert, ein nicht freigegebener Zugriff blockiert oder eindeutig zur Genehmigung vorgelegt wird und die Entscheidung im Log nachvollziehbar ist. Abbruch erfolgt bei unklaren Netzwerkpfaden, unerwarteten Domains, stillen Ausweichverbindungen oder einem Tool-Proxy, der die lokale Einschränkung umgehen kann.

MCP- und externe Ausführungswege behandeln Sie als eigene Angriffsfläche. Ein Community-Bericht darf dabei nur ein Prüfsignal sein. Der verlinkte GitHub-Issue ist kein Beleg für eine allgemeine Sicherheitslücke, sondern ein Fall, dessen Status und Übertragbarkeit Sie vor einer Freigabe selbst bewerten müssen.

Konten, SSH und Keychain

Kann Codex CLI auf einem Remote Mac SSH-Schlüssel oder die macOS Keychain sehen?
Das hängt nicht allein von Codex CLI ab. Entscheidend sind das verwendete macOS-Konto, die laufenden Agent-Prozesse, Umgebungsvariablen, SSH-Agent-Sockets, Dateirechte, Keychain-Freigaben und die jeweils ausgeführte Aktion.

Prüfen Sie zuerst die Identität des Prozesses. Ein gemeinsames Administratorkonto für interaktive Nutzung, CI/CD und Agent-Aufgaben erschwert jede nachträgliche Zuordnung. Verwenden Sie für die Abnahme ein separates Konto ohne unnötige Administratorrechte. Halten Sie fest, welche Gruppenmitgliedschaften, Home-Verzeichnisse und Login-Dienste dieses Konto besitzt.

Danach testen Sie drei Credential-Zustände:

  • kein Credential verfügbar;
  • ein ausdrücklich lesendes oder auf ein Testziel begrenztes Credential verfügbar;
  • ein kurzlebiges, nach dem Lauf widerrufbares Credential verfügbar.

Für SSH prüfen Sie nicht nur Dateien im Home-Verzeichnis. Kontrollieren Sie auch, ob ein SSH-Agent-Socket sichtbar ist, welche Identitäten angeboten werden und ob ein ungewolltes Weiterreichen an Folgeprozesse stattfindet. Der Nachweis besteht aus der Identitätsprüfung, dem Ergebnis eines Zugriffs auf ein Testziel und dem anschließenden Widerruf.

Für die Keychain verwenden Sie ein Testobjekt ohne Produktionswert. Prüfen Sie, ob das Objekt sichtbar ist, ob eine Freigabe verlangt wird und ob ein nicht interaktiver Prozess dieselbe Berechtigung erhält wie eine lokale Sitzung. Apple beschreibt in der Anleitung zu Zugriffsrechten der Keychain, dass der Zugriff durch Berechtigungen und Freigaben gesteuert wird. Übertragen Sie diese Prüfung nicht pauschal auf jede Xcode- oder Agent-Konstellation.

Xcode-Signaturidentitäten und Veröffentlichungszugänge müssen getrennt betrachtet werden. Ein Build ohne Signierung kann zulässig sein, während ein Upload- oder Release-Prozess absichtlich blockiert bleibt. Produktionssignaturmaterial darf nicht in eine Standard-Agent-Sitzung gelangen. Verwenden Sie für die Prüfung ausschließlich Testzertifikate, Testprofile oder nicht produktive Platzhalter.

Bestanden ist die Messgröße, wenn ein Auftrag ohne Credential keine geschützte Aktion durchführen kann, ein begrenztes Credential nur das erwartete Ziel erreicht und nach dem Lauf widerrufen werden kann. Abbruch erfolgt bei sichtbaren Produktionsschlüsseln, unklarer Keychain-Freigabe, weitergereichten Agent-Sockets oder einer nicht erklärbaren Verbindung zwischen Build-Prozess und Veröffentlichung.

Xcode-Ausführung und Parallelbetrieb

Die Fähigkeit, xcodebuild oder ein Skript zu starten, beweist noch keine reproduzierbare Pipeline. Bei einem Remote Mac müssen Sie auch Arbeitsbereich, Derived Data, Simulatorzustand, Caches, Ports, Logs und Signaturzugriffe prüfen.

Welche Xcode-Prüfung ist vor dem Mehr-Repository-Betrieb nötig?
Führen Sie einen nicht produktiven Build mit einem Testprojekt aus und messen Sie nicht nur den Exit-Status. Sichern Sie die Build-Ausgabe, das Ergebnisartefakt, die verwendeten Pfade und den Zustand des Rechners vor und nach dem Lauf.

Die Prüfschritte lauten:

  • Quelldateien und Build-Skripte aus dem Test-Repository bestimmen;
  • Derived Data und Cache-Verzeichnisse vor dem Lauf erfassen;
  • einen nicht signierten oder mit Testmaterial signierten Build ausführen;
  • Simulator- und Toolzustand nach dem Lauf prüfen;
  • erzeugte Dateien und Logs dem Auftrag zuordnen;
  • denselben Ablauf mit einem zweiten, absichtlich anders markierten Repository wiederholen.

Für Parallelbetrieb starten Sie die Aufträge nicht sofort mit Produktionsdaten. Verwenden Sie getrennte Arbeitsverzeichnisse und eindeutig benannte Artefakte. Kontrollieren Sie, ob ein Auftrag Dateien, Ports, Simulatorzustände, Caches oder Logs des anderen Laufs verändert. Ein gemeinsamer Cache kann zwar technisch funktionieren, aber ungewollte Datenübernahme und schwer nachvollziehbare Fehler verursachen.

Als Beleg benötigen Sie die Build-Logs, die Liste der geänderten Dateien, die Artefaktzuordnung und den Prozessstatus beider Läufe. Bestanden ist die Messgröße, wenn jeder Auftrag sein eigenes Repository und seine erwarteten Ausgabepfade verwendet und die Ergebnisse reproduzierbar zugeordnet werden können. Abbruch erfolgt bei vermischten Artefakten, gemeinsamem Schreibzugriff ohne Begründung, unerwarteten Simulatorzuständen oder Signaturzugriffen außerhalb des Testumfangs.

Codex CLI, Xcode und ein Remote Mac sind daher nicht automatisch ein geeigneter gemeinsamer Pool. Wenn Sie keine belastbare Trennung von Arbeitsbereichen und Artefakten erreichen, wählen Sie einzelne Repositorys nacheinander auf einem bereinigten Knoten oder trennen Sie die Aufgaben auf eigene Knoten auf.

Bereinigung und Wiederanlauf

Ein Agent-Knoten ist erst dann für langfristige Aufgaben geeignet, wenn er auch nach Fehlern kontrolliert in einen bekannten Zustand zurückkehrt. Prüfen Sie nicht nur einen normalen Abschluss, sondern Unterbrechung, SSH-Abbruch, Prozessende, Repository-Wechsel und Neustart des Mac.

Wie werden Arbeitsbereich und Restprozesse nach einem Codex-Auftrag bereinigt?
Definieren Sie vor dem Start einen Sollzustand und vergleichen Sie ihn nach jedem Szenario. Dazu gehören Prozesse, temporäre Dateien, Arbeitskopien, Logs, Zugangsdaten, Keychain-Testobjekte, Simulatoren und Netzwerkverbindungen.

Führen Sie die Wiederanlaufprüfung in dieser Reihenfolge aus:

  • Auftrag normal beenden und den Prozessbaum kontrollieren;
  • die SSH-Sitzung während eines kontrollierten Testlaufs trennen;
  • Codex CLI während einer ungefährlichen Aktion beenden;
  • das Repository wechseln und nach Restprozessen suchen;
  • den Mac neu starten;
  • den Knoten mit demselben Test-Repository erneut prüfen;
  • die entstandenen Unterschiede, Logs und Credentials abgleichen.

Der Beleg besteht aus Prozesslisten vor und nach jedem Szenario, einem Dateisystemvergleich, dem Git-Status, den Logdateien und dem Ergebnis des erneuten Testlaufs. Bestanden ist die Messgröße, wenn keine unerwarteten Prozesse, Tokens, temporären Kopien oder fremden Änderungen zurückbleiben und der Knoten nach dem Neustart seinen dokumentierten Ausgangszustand erreicht.

Abbruch erfolgt, wenn ein abgebrochener Auftrag weiterläuft, ein Credential im Arbeitsbereich verbleibt, ein Repository nach dem Wechsel verändert wird oder der Knoten nach dem Neustart andere Berechtigungen besitzt als vorher. In diesem Fall ist ein automatischer „Cleanup“-Befehl allein kein ausreichender Nachweis. Sie brauchen eine überprüfbare Zustandsdifferenz.

Abnahme-Checkliste und Entscheidungsweg

Nutzen Sie vor der Freigabe die folgende Checkliste. Ein Häkchen bedeutet nicht, dass ein Test lediglich ausgeführt wurde. Es bedeutet, dass ein überprüfbarer Beleg vorliegt und kein Abbruchkriterium ausgelöst wurde.

  • [ ] Ein eigenes, nicht privilegiertes Systemkonto für Codex CLI ist dokumentiert.
  • [ ] Der Arbeitsbereich jedes Repositorys ist eindeutig festgelegt.
  • [ ] Ein Querzugriff auf ein zweites Repository wurde getestet und blockiert oder nachvollziehbar genehmigt.
  • [ ] Schreibzugriffe auf Git-Metadaten, temporäre Verzeichnisse, Caches und Derived Data sind bekannt.
  • [ ] Modellkommunikation, Abhängigkeitsdownloads, Git, API-Aufrufe und externe Tools wurden getrennt geprüft.
  • [ ] Nicht erlaubte Netzwerkziele wurden getestet und blockiert oder eindeutig zur Genehmigung vorgelegt.
  • [ ] MCP- oder Tool-Proxy-Pfade wurden als eigene Ausführungswege bewertet.
  • [ ] SSH-Agent, SSH-Schlüssel und Umgebungsvariablen sind auf sichtbare Credentials geprüft.
  • [ ] Ein Keychain-Testobjekt wurde verwendet; Produktionsgeheimnisse waren nicht verfügbar.
  • [ ] Xcode-Build, Simulator, Skripte und Derived Data wurden mit Testmaterial geprüft.
  • [ ] Parallel laufende Repositorys erzeugen keine fremden Änderungen oder vermischten Artefakte.
  • [ ] Normaler Abschluss, SSH-Abbruch, Prozessende, Repository-Wechsel und Mac-Neustart sind dokumentiert.
  • [ ] Nach jedem Szenario wurden Prozesse, Dateien, Logs und Test-Credentials kontrolliert.

Treffen Sie danach die Entscheidung nach diesen Bedingungen:

  • Wenn alle Kontrollpunkte erfüllt sind und die Belege reproduzierbar sind, dann können Sie den Mehr-Repository-Betrieb kontrolliert freigeben.
  • Wenn die Dateigrenze funktioniert, aber Xcode-Signierung oder Keychain nicht ausreichend isoliert ist, dann beschränken Sie Codex CLI auf Review, Tests oder nicht signierte Builds.
  • Wenn ein Repository sauber läuft, die Rotation oder Parallelität aber nicht nachweisbar ist, dann verwenden Sie einen einzelnen temporären Knoten und bereinigen ihn nach jedem Auftrag.
  • Wenn Netzwerk- oder Toolpfade nicht eindeutig kontrollierbar sind, dann wählen Sie einen getrennten Knoten oder eine Dual-Track-CI mit klar getrennter Freigabestufe.
  • Wenn ein fremdes Repository gelesen, ein Produktionsschlüssel sichtbar oder ein Restprozess nicht zuverlässig entfernt wird, dann bauen Sie den Knoten neu auf oder verschieben die Einführung.

Entscheidung nach der Abnahme

Für einen kurzfristigen isolierten Test kann ein gemieteter Remote Mac sinnvoller sein als der Betrieb eines gemeinsam genutzten Entwicklungsrechners: Sie vermeiden zunächst den Kauf eigener Hardware, müssen aber die Kontentrennung, Zugangsdaten und Bereinigung trotzdem selbst abnehmen. Informationen zu verfügbaren VMSPIN-Remote-Mac-Angeboten und den Mietoptionen sollten Sie erst nach der technischen Entscheidung prüfen, nicht an deren Stelle setzen.

Ein eigener Mac mini ist bei dauerhaftem, planbarem Schwerlastbetrieb oder bei zwingend benötigten physischen Schnittstellen oft die passendere Lösung. Ein gemeinsam verwalteter Linux-Server löst dagegen keine Aufgaben, die macOS, Xcode oder Apple-Signaturwerkzeuge voraussetzen. Ein Remote Mac bleibt ungeeignet, wenn Sie keine Kontrolle über Konto, Arbeitsbereich und Wiederherstellung erhalten.

Wenn Sie nur eine isolierte Testphase oder kurzfristige Codex-CLI-Aufträge benötigen, können Sie einen Remote Mac von VMSPIN für einen begrenzten Einsatz anfordern. Beginnen Sie mit einem nicht produktiven Repository, wiederholen Sie die Prüfungen nach jeder Änderung am Berechtigungsmodell und geben Sie mehrere Repositorys erst frei, wenn jeder Abbruchfall ebenso nachvollziehbar ist wie der erfolgreiche Build.