Wenn der Quellcode eines kommerziellen Projekts nicht an ein Cloud-Modell gesendet werden darf: Was kann ich dann mit ChatGPT im Web noch tun? Kann es den lokalen Projektstatus prüfen oder eine kontrollierte SSH-Prüfung anfordern? Und wenn der Quellcode gehostet werden darf, warum überhaupt ein lokales MCP verwenden?

Entscheidend ist nicht ein bestimmtes Werkzeug, sondern was das Werkzeug sehen kann, wo die Arbeit ausgeführt wird und wohin das Ergebnis zurückgeht.

Kurz gesagt: Die Web-App liest deinen Mac nicht automatisch aus. Wenn du dem Modell keinen Quellcode übergibst, kann es anhand ausdrücklich geteilter Zusammenfassungen oder Statuswerte beraten, aber keinen Code unabhängig prüfen oder debuggen, den es nicht gesehen hat.

Codex lokal auszuführen bedeutet nicht, dass auch die Inferenz lokal stattfindet. Codex Cloud ist keine Verbindung zu deinem Mac. Ein MCP-Tunnel leitet Anfragen weiter, begrenzt aber nicht selbst die Berechtigungen der Tools. GitHub Private steuert den Zugriff auf ein Repository; es macht ein gehostetes Repository nicht lokal. Wenn Quellcode an ein Cloud-Modell übergeben wird, gelangt dieser Kontext in dessen Verarbeitungsbereich. Im Folgenden vergleiche ich die Optionen und zwei öffentliche Beispiele: VXI Local-First MCP und VXI SSH Ops Bridge. Das erste teilt nur den lokalen Projektstatus, das zweite erlaubt ausschließlich eine fest definierte schreibgeschützte SSH-Operation.

Die Wege vergleichen: Wo liegt der Arbeitsbereich, und was sieht das Modell?

Weg	Arbeitsbereich und Ausführungsort	Was das Cloud-Modell sehen kann	Geeignet für
Codex Local environment in der Desktop-App + lokales MCP	Projekt/worktree, Terminal und MCP-Prozess auf dem Mac	Abhängig vom tatsächlich an das Modell gesendeten Kontext; lokale Ausführung ist keine lokale Inferenz	Dateien innerhalb der Berechtigungen lesen/schreiben, Befehle ausführen und Diffs prüfen, wenn die Datengrenze des Modells geklärt ist
Codex Cloud / Cloud-Aufgabe im Web	Ausgewähltes GitHub-Repository in einem isolierten Cloud-Arbeitsbereich	Quellcode und Dateien, auf die die Aufgabe zugreifen kann	Code ändern, Prüfungen ausführen und Branch oder Ergebnis liefern, wenn GitHub- und Cloud-Verarbeitung erlaubt sind
GitHub Cloud Coding Agent	Repository und temporäre Cloud-Agent-Umgebung	Repository-Dateien, Aufgaben-Kontext und während der Ausführung erreichbare Inhalte	Zusammenarbeit über Branches, PRs und Checks
ChatGPT Web + Secure MCP Tunnel + Local-First MCP	MCP läuft lokal; das Gerät baut den ausgehenden Tunnel auf	Nur Zählwerte und Status-Enums, die das MCP ausdrücklich zurückgibt	Begrenzte Projektmetadaten teilen, ohne Quellcode-Lese- oder Shell-Rechte zu vergeben
ChatGPT Web + Secure MCP Tunnel + SSH Ops Bridge	Lokale MCP-Brücke und SSH-Client verbinden sich mit einem konfigurierten Host	Zielalias und gefiltertes Ergebnis einer festen Gesundheitsprüfung	Eine erlaubte schreibgeschützte Prüfung auf einem Nicht-Produktionsziel anfordern
Web-Modell + lokaler coding-agent relay (separat zu bauen)	Ein lokaler Adapter delegiert an Codex oder einen anderen lokalen Coding-Agent	Abhängig vom Inferenzort und den vom Adapter zurückgegebenen Daten	Mögliches zukünftiges Design, das eigene Kontrollen für Tools, Ausgabe, Schreibzugriffe, Timeouts und Freigaben benötigt

Eine wichtige Einschränkung vorweg: Die folgende Tunnel-Konfiguration basiert auf der offiziellen OpenAI-Dokumentation, aber die Ende-zu-Ende-Verbindung zwischen ChatGPT Web und dem lokalen MCP wurde auf dem echten Mac des Autors noch nicht getestet. Die Anleitung ist eine Konfigurationshilfe, kein verifiziertes Ein-Klick-Tutorial.

Erst den Weg wählen, dann konfigurieren

• Quellcode darf niemals an ein Cloud-Modell gehen: Code-Arbeit bleibt bei lokaler Inferenz oder einem anderen vertrauenswürdigen lokalen Ablauf. Ein Metadaten-MCP kann freigegebene Statuswerte teilen, aber ein Cloud-Modell ohne Quellcode kann ihn nicht unabhängig prüfen.
• ChatGPT im Web soll nur den lokalen Status sehen: Nutze eine feste Feldprojektion wie Local-First MCP. Sie braucht weder Quellcode-Lesezugriff noch Shell-Rechte.
• Du möchtest aus dem Web eine feste SSH-Gesundheitsprüfung anfordern: Nutze eine benannte Operation wie SSH Ops Bridge und halte Host-Identität, private Schlüssel und Ziel-Allowlist lokal.
• Der Quellcode darf gehostet werden und die KI soll ihn lesen und ändern: Nutze GitHub-first, Codex Cloud oder einen anderen freigegebenen Cloud-Agent und halte Branches, PRs, Commits und CI als überprüfbare Nachweise fest.
• Web-KI soll Code-Arbeit an lokales Codex delegieren: Dafür muss ein separater lokaler Agent-Relay gebaut und geprüft werden. Metadaten-MCP und SSH-Brücke bieten diese Fähigkeit nicht.
• Projekte haben unterschiedliche Datenklassen: Wähle den Weg pro Projekt. Die Erlaubnis, ein Blog-Repository zu hosten, bedeutet nicht, dass kommerzieller Quellcode denselben Weg nehmen darf.

Web-Tools anderer Anbieter müssen einzeln geprüft werden: Unterstützten Remote-MCP- oder lokalen-Agent-Weg, Authentifizierung, lokale Agent-Fähigkeiten sowie die tatsächlichen Eingaben und Tool-Ergebnisse kontrollieren, die das Modell erhält. MCP-Unterstützung allein bedeutet nicht, dass OpenAI Secure MCP Tunnel unverändert wiederverwendet werden kann.

Offizielle Referenzen: Codex Local environments, Codex Cloud environments, Codex MCP, OpenAI Secure MCP Tunnel und GitHub Copilot cloud agent.

Drei Datenflüsse

A. Web-KI liest den lokalen Projektstatus

ChatGPT Web
    |
OpenAI Secure MCP Tunnel endpoint
    ^ lokaler tunnel-client startet ausgehendes HTTPS
    |
lokales vxi-local-first-mcp (stdio MCP)
    |
lokales Projektverzeichnis: Einträge zählen, Quellcode nicht lesen

Zurückgegeben: Zählwerte + PASS / FAIL / UNKNOWN
Nicht zurückgegeben: Quellcode, Pfade, Diffs, Logs, Befehle

B. Web-KI fordert eine feste SSH-Prüfung an

ChatGPT Web
    |
OpenAI Secure MCP Tunnel endpoint
    ^ lokaler tunnel-client startet ausgehendes HTTPS
    |
lokales vxi-ssh-ops-bridge (stdio MCP)
    |
lokaler SSH-Client + privater Schlüssel + pinned known_hosts
    |
SSH-Ziel außerhalb der Produktion: festes Read-only-Prüfskript
    |
gefilterte health / service / storage Statuswerte
    |
zurück zur Web-App

C. GitHub-first-Cloud-Entwicklung

GitHub-Repository, dessen Hosting erlaubt ist
    |
Codex Cloud / GitHub Cloud-Agent
    |
Cloud-Arbeitsbereich liest Quellcode, ändert Dateien und führt Checks aus
    |
Branch + PR + Commit + CI
    |
menschliche Prüfung und Freigabe

Das sind unterschiedliche Betriebsmodelle. Die ersten beiden begrenzen, was ein Web-Tool sehen oder anfordern kann. Der dritte Weg erlaubt einer KI, in einem freigegebenen Cloud-Arbeitsbereich vollständige Quellcode-Arbeit zu leisten.

Codex Local, Codex Cloud und MCP nicht verwechseln

Codex Local environment in der Desktop-App konfiguriert Vorbereitungsschritte und häufige Aktionen für ein lokales Projekt oder einen worktree. Das integrierte Terminal führt Befehle lokal aus; Git-Werkzeuge können Diffs prüfen, Dateien stagen, committen, pushen und PRs erstellen. Ein lokaler Codex-Client kann auch einen lokalen stdio-MCP-Server starten. Dabei startet ein lokaler MCP-Host einen lokalen Server; ein Web-Tunnel ist dafür nicht nötig.

„Lokale Ausführung“ sagt jedoch nur, wo Dateien und Befehle laufen. Wenn das Modell gehostet wird, kann der für die Analyse verwendete Quellcode-Kontext trotzdem in die Cloud gesendet werden. Um Quellcode-Abfluss strikt zu verhindern, braucht es lokale Inferenz oder einen verifizierten vertrauenswürdigen lokalen Ablauf sowie eine separate Prüfung anderer Prozesse und Netzwerkwege auf dem Gerät.

Codex Cloud legt das ausgewählte GitHub-Repository dagegen in einen isolierten Cloud-Arbeitsbereich, bereitet Abhängigkeiten vor und führt dort Aufgaben aus. GitHub Cloud-Agents können Quellcode in Cloud-Umgebungen ebenfalls lesen, Branches ändern, Checks ausführen und PRs erstellen. Das ist für Projekte geeignet, die diese Cloud-Grenze überschreiten dürfen, nicht als Ersatz für lokal zu haltenden Quellcode.

MCP-Host und MCP-Server

• Desktop-ChatGPT, Codex CLI und IDE-Erweiterungen als MCP-Hosts: Sie können lokale stdio-Server nach der jeweiligen Client-Konfiguration starten. Das dokumentierte CLI-Format lautet:

codex mcp add vxi-local-status \
  --env "VXI_WORKSPACE=/absolute/path/to/project" \
  -- /absolute/path/to/node /absolute/path/to/vxi-local-first-mcp/bin/vxi-local.mjs mcp

codex mcp list

Für SSH Ops Bridge wird dieselbe Befehlsform verwendet, aber VXI_OPS_CONFIG auf den lokalen Pfad von ops.config.json gesetzt und der Serverbefehl auf vxi-ssh-ops-bridge/bin/vxi-ops.mjs geändert. Hostnamen, Konten, private Schlüsselpfade und ops.config.json bleiben lokal. Laufzeitgeheimnisse gehören weder in den Chat noch in Git. Desktop-App, Codex CLI und unterstützte IDE-Erweiterungen können die Codex-Host-MCP-Konfiguration nutzen; die Berechtigungen hängen trotzdem von den jeweiligen Workspace-Einstellungen ab.

• ChatGPT Web als Aufrufer: Die Web-App liest weder die lokale ~/.codex/config.toml noch übernimmt sie automatisch die lokale Codex-Befehlsliste. Sie braucht einen unterstützten Remote-MCP-Weg. Secure MCP Tunnel ermöglicht einem lokalen Tunnel-Client, ausgehend einen OpenAI-gehosteten Endpunkt zu erreichen und Anfragen an einen lokalen stdio- oder HTTP-MCP-Server weiterzuleiten.

Das Web-Tool mit einem lokalen MCP verbinden und SSH anfordern

Die Secure-MCP-Tunnel-Dokumentation von OpenAI beschreibt einen tunnel-client in einem Netzwerk, das den privaten MCP-Dienst erreichen kann. Der Client baut ausgehendes HTTPS auf, empfängt Anfragen vom gehosteten Endpunkt, leitet sie an den lokalen stdio- oder HTTP-MCP-Server weiter und sendet die Antwort über denselben Tunnel zurück. Auf dem Mac muss kein öffentlicher eingehender Port geöffnet werden.

Pfade und Tunnel-IDs unten sind Platzhalter. Laufzeit-Zugangsdaten gehören ausschließlich in lokale Umgebungsvariablen.

1. Erstelle oder wähle einen Tunnel in OpenAI Platform. Prüfe die Zuordnung zwischen dem Ziel-ChatGPT-Workspace und der Platform-Organisation sowie die erforderliche Tunnel-Berechtigung.
2. Lade den aktuellen tunnel-client aus den Tunnel-Einstellungen herunter. Prüfe dessen aktuelle Hilfe/Quickstart-Ausgabe und richte pro MCP-Server ein eigenes Profil ein.
3. Teste jeden MCP-Server offline, bevor du den Tunnel konfigurierst. Für Local-First MCP:

cd /path/to/vxi-local-first-mcp
node --version  # >= 22
npm test
npm run demo

Wenn die Checks erfolgreich sind, richte das Local-First-Profil ein:

export CONTROL_PLANE_API_KEY="<runtime-key kept in the local terminal>"

tunnel-client init \
  --sample sample_mcp_stdio_local \
  --profile vxi-local-status \
  --tunnel-id "<your-tunnel-id>" \
  --mcp-command "/usr/bin/env VXI_WORKSPACE=/absolute/path/to/project /absolute/path/to/node /absolute/path/to/vxi-local-first-mcp/bin/vxi-local.mjs mcp"

tunnel-client doctor --profile vxi-local-status --explain
tunnel-client run --profile vxi-local-status

Absolute Pfade vermeiden, dass sich Arbeitsverzeichnis oder PATH eines Hintergrundprozesses vom interaktiven Terminal unterscheiden.

Für SSH Ops Bridge führe zuerst npm test und npm run demo aus. Erstelle aus ops.config.example.json eine lokale ops.config.json und ändere mode von disabled auf read_only. Konfiguriere nur ein unabhängig geprüftes Nicht-Produktionsziel, ein Konto mit niedrigen Rechten, einen lokalen privaten Schlüsselpfad und eine festgelegte known_hosts-Datei. Installiere laut README das Read-only-Skript auf dem Testhost unter /usr/local/bin/vxi-health-check. Richte danach ein separates Profil ein:

tunnel-client init \
  --sample sample_mcp_stdio_local \
  --profile vxi-ssh-readonly \
  --tunnel-id "<your-ssh-tunnel-id>" \
  --mcp-command "/usr/bin/env VXI_OPS_CONFIG=/absolute/path/to/ops.config.json /absolute/path/to/node /absolute/path/to/vxi-ssh-ops-bridge/bin/vxi-ops.mjs mcp"

tunnel-client doctor --profile vxi-ssh-readonly --explain
tunnel-client run --profile vxi-ssh-readonly

Platform-Oberflächen und Client-Versionen können sich ändern. Verwende für genaue Optionen die Hilfe der installierten Version.

4. Lass tunnel-client run aktiv. Wähle im unterstützten benutzerdefinierten MCP-Einstieg in ChatGPT Add custom MCP server → Tunnel, wähle den verfügbaren Tunnel, authentifiziere dich und prüfe die Berechtigungsabfrage. Wenn kein Tunnel angezeigt wird, prüfe Workspace-/Organisationszuordnung und Berechtigungen, statt das lokale MCP öffentlich erreichbar zu machen.
5. Rufe zuerst das Read-only-Tool vxi_project_status oder vxi_ops_policy auf, um die Tool-Erkennung zu bestätigen, und fordere vxi_ssh_health nur bei Bedarf an. Nicht gegen einen Produktionshost testen; den SSH-Hostschlüssel über einen unabhängigen Kanal prüfen.

Was die SSH-Brücke lokal macht

Der lokale Administrator speichert Host, Benutzername, Port, privaten Schlüsselpfad und unabhängig verifiziertes known_hosts in ops.config.json. Das MCP akzeptiert nur Aliase aus der lokalen Allowlist, etwa lab, keine vom Modell erzeugten Befehlszeichenfolgen. Die Brücke ignoriert persönliche SSH-Konfiguration, deaktiviert Agent-Forwarding und interaktive Passwortabfragen, ruft das feste Skript /usr/local/bin/vxi-health-check auf und reduziert die Antwort auf drei Status-Enums.

Die Web-App erhält nicht deinen privaten Schlüssel und meldet sich nicht direkt am Server an; sie fordert eine feste Operation an. Der Tunnel transportiert die Anfrage. Tool-Liste, Eingabevalidierung, lokale Konfiguration, Host-Key-Bindung und Remote-Skript bestimmen gemeinsam die Berechtigungsgrenze.

Wenn hinter einem MCP ein lokaler Agent mit Code-Schreibrechten sitzt, müssen Tools, Eingaben, Ausgaben, Dateischreibvorgänge, Befehlsausführung, Timeouts und menschliche Freigaben separat geprüft werden. Eine Sicherheitsbewertung für ein eingeschränktes SSH-MCP lässt sich nicht automatisch auf einen schreibfähigen coding-agent relay übertragen.

Die Rollen der beiden öffentlichen Repositories

VXI Local-First MCP: nur lokale Projektmetadaten teilen

Repository öffnen

Das lokale stdio-MCP stellt zwei Read-only-Tools bereit:

• vxi_project_status: Dateikategorien-Zählwerte, Anzahl übersprungener Symlinks und manuell erfasste Statuswerte für lint/test/build (PASS / FAIL / UNKNOWN; Standard ist UNKNOWN). Das MCP führt keine Tests aus. Der begrenzte Scan überspringt Punktverzeichnisse und übliche Build-/Cache-Verzeichnisse wie .git, node_modules und dist. Er verarbeitet höchstens 20.000 Verzeichniseinträge; bei Überschreitung wird ein Fehler ausgelöst statt eine Teilmenge zurückgegeben. Es ist also kein vollständiges Inventar aller möglichen Projektdateien.
• vxi_security_contract: Beschreibt erlaubte und verbotene Antwortfelder.

Der Scanner klassifiziert Verzeichniseinträge, ohne Quelldateien zu lesen. Die feste Projektion enthält keinen Quellcode, keine Pfade, Diffs, Logs, Umgebungsvariablen oder Shell-Schnittstelle. So erhält ein Cloud-Modell begrenzte Statusinformationen; der Quellcode wird nicht verschlüsselt hochgeladen.

record ist ein lokaler CLI-Befehl, kein MCP-Tool, und führt keine Tests aus. Beispiel:

node bin/vxi-local.mjs record --workspace /path/to/project --kind test --status PASS

kind kann lint, test oder build sein; der Status wird vom Operator eingetragen. Das ist nur dafür gedacht, einem Web-Modell groben lokalen Prüfkontext zu geben, ohne Quellcode oder Rohprotokolle hochzuladen. Es diagnostiziert keine Fehler und ist kein signierter, an einen Commit gebundener Testnachweis. Für Debugging die vollständigen Logs lokal prüfen oder eine minimale, manuell ausgewählte und bereinigte Fehlerzusammenfassung teilen.

VXI SSH Ops Bridge: nur feste Read-only-SSH-Operationen

Repository öffnen

Die Brücke ist standardmäßig deaktiviert und stellt nur vxi_ops_policy und vxi_ssh_health bereit. Letzteres akzeptiert einen Alias aus der lokalen Allowlist, ruft ein festes Remote-Skript auf und filtert das Ergebnis auf die Statuswerte health, service und storage. health: PASS im Beispiels-script beweist nur, dass das feste Skript ausgeführt wurde; service und storage bleiben UNKNOWN, bis anwendungsspezifische Checks installiert und geprüft sind. Es gibt kein generisches exec(command), keinen Dateitransfer, kein Deployment, keinen Neustart und keinen beliebigen Log-Export.

Die Repositories sind unabhängig. Eines teilt lokalen Projektstatus, das andere erlaubt genau eine feste SSH-Prüfung. Beide haben keine Werkzeuge zum Bearbeiten des Quellcodes und rufen einander nicht auf.

Was beweist ein grüner Testlauf tatsächlich?

Die Zahlen beziehen sich auf unterschiedliche Repositories und Testebenen, nicht auf wiederholt gezählte Tests derselben Suite:

• Local-First MCP: main enthält 6 Unit-Tests (Baseline-CI). PR #3 ergänzt eine Ubuntu/macOS-Matrix, keine neuen Testfälle; dieselben sechs Tests bestehen auf beiden Betriebssystemen jeweils 6/6 (PR #3 CI).
• SSH Ops Bridge: main enthält 7 Unit-Tests (Baseline-CI). PR #3 behält diese sieben Tests bei und ergänzt einen separaten OpenSSH-localhost-Integrationsjob auf einem einmaligen GitHub-hosted Ubuntu Runner. Unit-Tests und Loopback-SSH-Checks bestehen (PR #3 CI).
• SSH Ops Bridge PR #4: ergänzt einen Testfall zu den sieben bestehenden Tests, der fehlende oder falsch typisierte Host-/User-Werte abdeckt, und ergänzt die passende String-Validierung. Auf diesem noch nicht zusammengeführten Draft-Branch bestehen 8/8 Unit-Tests und die Demo (PR #4 CI).

Der Loopback-Testaufbau deckte echte Testdesignprobleme auf: Zunächst passten Runner-Benutzer und PAM-Konfiguration nicht zusammen, sodass die Authentifizierung scheiterte. Später zeigte sich, dass ein serverseitiges ForceCommand die Client-Anfrage überschreiben und einen falschen Erfolg vortäuschen konnte, obwohl der beabsichtigte Befehl nicht ausgeführt wurde. Nach der Korrektur setzt der Testaufbau kein ForceCommand mehr; der echte SSH-Client führt das generierte feste Remote-Skript aus. Die Tests prüfen direkte Aufrufe und MCP-Ergebnisse und weisen einen falschen gepinnten Hostschlüssel sowie beliebige exec-Anfragen zurück.

Diese Ergebnisse gelten nur für die jeweils verlinkten exakten Quellversionen. Zum Zeitpunkt der Prüfung sind alle drei Quell-PRs weiterhin Draft und nicht zusammengeführt. Die Cross-Platform-Matrix und der Loopback-Job aus PR #3 sowie die Eingabevalidierung aus PR #4 sind noch nicht Teil von main.

Fazit: Nach Datengrenze wählen, nicht nach Werkzeugnamen

Wenn Quellcode in die Cloud darf, kann GitHub-first der KI das Lesen und Schreiben von Code ermöglichen und mit Branches, PRs, Commits und CI überprüfbare Entwicklungsnachweise hinterlassen. Wenn Quellcode lokal bleiben muss, kann Local-First MCP Status an ein Web-Modell geben und SSH Ops Bridge eine feste Read-only-Remote-Operation anbieten. Quellcode-Arbeit braucht weiterhin lokale Menschen, lokale Inferenz oder einen separat geprüften lokalen Workflow.

Die Grenze wird nicht dadurch geschützt, dass man „ein lokales Tool“ nutzt oder „MCP verbunden“ hat. Entscheidend ist, was jeder Weg tatsächlich an das Modell sendet, welche Operationen das Modell anfordern kann und wohin die Antwort gelangt.

Beide Repositories sind noch Minimalprototypen. Der Tunnel wurde auf dem echten Mac des Autors nicht verifiziert. Es gab auch keinen Test mit einem externen SSH-Host, kein Audit des gesamten Geräts auf Quellcode-Abfluss, keinen Nachweis wirklich lokaler Modellinferenz und keinen Vergleich von Qualität, Latenz, Tokenverbrauch und Kosten für dieselbe Aufgabe.