Local MCP ChatGPT Tunnel

Ein lokales Gateway, das stdio-basierte MCP-Server unter Windows über den offiziellen OpenAI Secure MCP Tunnel mit dem ChatGPT Developer Mode verbindet. Es bündelt mehrere stdio-MCPs zu einem einzigen und ermöglicht die Steuerung von Tool-Namensräumen, dem Ausschluss von Tools, Pfadberechtigungen, serieller Ausführung und verzögertem Start über eine Konfigurationsdatei.

Installation

[!IMPORTANT] Die Installationsanleitung für Windows finden Sie in INSTALL.md.

Related MCP server: Windows Local MCP

Sicherheitswarnung

[!WARNING] Dies ist ein persönliches Werkzeug, das nur mit Ihrem eigenen Windows-PC, Ihrer eigenen OpenAI-Platform-Organisation und Ihrem eigenen ChatGPT-Workspace verwendet werden soll. Da MCPs mit Fähigkeit zur Ausführung beliebigen Codes angeschlossen werden können, ist die Weitergabe an Dritte oder der Betrieb als öffentliches Plugin nicht vorgesehen.

Über die Codex-Sandbox

[!IMPORTANT] In der Version vom 11. August 2026 wurde ein Mechanismus implementiert, der die Codex-Sandbox direkt verwendet und den Computer vor Grenzinkonsistenzen und beliebiger Codeausführung schützt. Es werden keine allgemeinen Shells oder die Auswahl beliebiger ausführbarer Dateien bereitgestellt, aber codex-script zum Ausführen vorhandener Skripte mit fester Laufzeitumgebung ist enthalten. codex-script erfordert eine elevated- oder unelevated-Sandbox. Da auch andere enthaltene MCPs und externe stdio-MCPs pro MCP in der Codex-Sandbox gestartet werden können, wird künftig empfohlen, wo möglich die Grenzverstärkung durch den elevated-Modus zu verwenden.

Über die KI-Implementierung

[!CAUTION] Dieses Repository wurde von ChatGPT 5.6 Sol High implementiert. Da es von KI generierten Code enthält, können Fehler oder Schwachstellen vorhanden sein. Überprüfen Sie vor der tatsächlichen Verwendung den Code und die Konfiguration und verwenden Sie ihn auf eigene Verantwortung.

Was möglich ist

• Aufrufen von stdio-MCP-Servern unter Windows über ChatGPT

• Bündeln mehrerer MCPs zu Tool-Namen im Format <prefix>__<tool>

• Hinzufügen beliebiger stdio-MCPs zu config/gateway.toml

• Einschränken der zulässigen Verzeichnisse und Dateien pro MCP

• Nicht-öffentlich machen gefährlicher Tools nach Name oder Teilzeichenfolge

• Serialisieren von MCPs, die nicht gleichzeitig ausgeführt werden sollen, mit serial_group

• Bei Bedarf Deaktivieren eines bestimmten MCP insgesamt

• Bei Bedarf Veröffentlichen eines integrierten Verzeichnisses zum Durchsuchen veröffentlichter Tools nach vollständigem Bezeichner oder Präfix

Was dieses Repository nicht tut

• Aufrufen der OpenAI Responses API oder Chat Completions API

• Implementieren eigener KI-Agenten, eigener Harnesses oder der Modellabrechnung

• Bereitstellen öffentlicher MCP-URLs oder lokaler Empfangsports

• Automatisches Installieren von Node.js, Git, ripgrep, Python oder tunnel-client

• Weiterverteilen von Drittanbieter-MCPs wie Ghidra MCP, Chrome DevTools MCP oder DQ9 MCP

Die Verbindung zum Secure MCP Tunnel übernimmt das offizielle tunnel-client.exe.Dieses Repository stellt ein lokales MCP-Gateway und enthaltene MCPs bereit, die mit dessen Standard-Ein-/Ausgabe verbunden werden.

Unterstützte Umgebungen

Die aktuellen Installationsanweisungen sind für Windows 11 gedacht.Zur Ausführung werden Node.js LTS und das offizielle OpenAI-tunnel-client.exe verwendet.Die enthaltene Dateisuche verwendet ripgrep, und für die GitHub-Actions-Prüfung wird die GitHub CLI verwendet. Das Diagnoseskript prüft node, npm, git, gh, rg und py. Es werden keine Installationsanweisungen für macOS und Linux, keine Docker-Konfiguration und keine Konfiguration zum Öffnen von Empfangsports bereitgestellt.

Erste Schritte

Die Schritte bis zur Nutzung sind in INSTALL.md zusammengefasst. Der grobe Ablauf ist wie folgt:

1. Die erforderliche Software und das offizielle tunnel-client.exe manuell bereitstellen

2. config/gateway.example.toml nach config/gateway.toml kopieren und die absoluten Pfade anpassen

3. Auf der OpenAI Platform einen persönlichen Tunnel und einen Runtime-API-Schlüssel nur für die Ausführung erstellen

4. Tunnel-ID und Runtime-API-Schlüssel in den Windows-Benutzerumgebungsvariablen speichern

5. Mit start.cmd nach der Diagnose den Tunnel starten

6. Im ChatGPT Developer Mode den persönlichen Tunnel auswählen Gehen Sie nicht von Einstellungen oder Berechtigungen aus, sondern prüfen Sie unbedingt INSTALL.md von oben nach unten.

Enthaltene MCPs

Die enthaltenen MCPs haben keine externen npm-Abhängigkeiten. Alle Tools deklarieren outputSchema. Das Gateway veröffentlicht isolated__create, isolated__list und isolated__close und macht eine eindeutige isolatedId für alle Tools der enthaltenen MCPs erforderlich. isolated__create akzeptiert ein oder mehrere absolute Verzeichnisse im workspaces-Array und erfordert außerdem einen purpose, der beschreibt, wofür die KI/Session diese Isolation verwendet. Das Gateway zeichnet createdAt automatisch auf und gibt bei isolated__list auch lastOperationAt für jedes Präfix zurück. Pro ID werden mehrere Workspaces und die relativen Pfadbasen pro MCP gespeichert. Die Prozesse der enthaltenen MCPs selbst werden nicht dupliziert; bei jedem Aufruf werden die Root-Gruppen der Ziel-ID übergeben. Normale gebündelte Tool-Aufrufe werden vom Gateway nicht unnötig serialisiert, sondern die parallele Verarbeitung wird dem untergeordneten MCP überlassen; nur Codespace besitzt eine Warteschlange zur Vermeidung von Konflikten bei derselben codespaceId. Das Gateway generiert beim Start einen zufälligen Schlüssel pro enthaltenem MCP und übergibt isolatedId, normalisierte Basispfade und Root-Gruppen mit HMAC-SHA-256 signiert als private Argumente. Die enthaltenen MCPs lehnen unsignierte, manipulierte oder strukturell ungültige Kontexte ab und lehnen auch Überschreibungen von root, roots, workspace und workspaces aus öffentlichen Argumenten ab. Das Gateway fügt allen gestarteten untergeordneten MCPs <prefix>__get_gateway_access_scope hinzu. Bei enthaltenen MCPs wird es mit isolatedId aufgerufen, um die für diese ID geltenden Basisverzeichnisse, Root-Gruppen, Konfigurationswerte und normalisierten erlaubten/abgelehnten Pfade zu prüfen. Wenn ein Pfad außerhalb des erlaubten Bereichs abgelehnt wird, werden im Fehlertext die aktuell erlaubten Verzeichnisse und Dateien als normalisierte absolute Pfade zurückgegeben. Im gemeinsamen Ausgabeformat der enthaltenen MCPs wird dieselbe Liste auch in structuredContent.result.accessScope zurückgegeben. Nach einer Ablehnung muss die KI nicht raten und ein anderes Arbeitsverzeichnis erneut versuchen.

safe-files

Was safe-files nach außen als „MCP root" bezeichnet, ist das aktuelle Basisverzeichnis, das für die Ziel-isolatedId gespeichert ist. Relative Pfade werden von dieser Basis aus aufgelöst, und set_working_directory ändert die Basis nur innerhalb der Root-Gruppen derselben ID. Der Zustand anderer IDs oder gemeinsamer MCP-Prozesse wird nicht geändert. read_text akzeptiert sowohl relative Pfade vom MCP-Root als auch absolute Pfade, liest jedoch nur, wenn das Ziel nach der Normalisierung und der Auflösung des tatsächlichen Pfads innerhalb der konfigurierten erlaubten Verzeichnisse bleibt. Die Hauptfunktionen sind:

• Rekursive Auflistung mit festem rg --files --hidden

• UTF-8-Textsuche mit festem rg

• Lesen/Schreiben von UTF-8-Text und Ersetzen bei exakter Übereinstimmung

• Größenbegrenzte base64-Dateiübertragung

• Erstellen von Verzeichnissen

• Kopieren und Verschieben normaler Dateien zwischen konfigurierten erlaubten Workspaces

• Patch-Anwendung mit integriertem Parser oder festem git apply copy und move akzeptieren relative Pfade vom aktuellen MCP-Root sowie absolute Pfade und können normale Dateien auch zwischen mehreren allowed_directories übertragen. Auf Quelle und Ziel werden Erlaubnis-/Ablehnungsrichtlinien angewendet; symbolische Links, Verzeichnisse und das Überschreiben vorhandener Ziele werden abgelehnt. Beim Verschieben wird nach erfolgreicher exklusiver Kopie die Quelle gelöscht – auch über verschiedene Laufwerke hinweg – und bei Löschfehlern das Ziel zurückgesetzt. Pfadzeichenfolgen werden nicht an eine Shell übergeben und Symbole nicht als Befehle interpretiert.Bei der rekursiven Auflistung wird das Innere von .git immer ausgeschlossen, und Patches können nicht auf das Innere von .git abzielen. Außerhalb erlaubter Wurzeln, Ausbruch über symbolische Links und Inhalte mit hoher Wahrscheinlichkeit von Anmeldeinformationen werden ebenfalls abgelehnt.Allgemeine Shells, PowerShell und Tools zur Ausführung beliebiger Befehle sind nicht enthalten.

safe-images

safe-images ist schreibgeschützt. Es prüft die Erweiterungen und Magic Bytes von PNG, JPEG und WebP und begrenzt standardmäßig auf 8 MiB und 50 Megapixel. SVG, HEIC, leere Dateien, Pfade außerhalb erlaubter Wurzeln, symbolische Links, UNC-Pfade und NTFS-Alternate Data Streams werden abgelehnt.

safe-download

safe-download ist schreibgeschützt und gibt eine einzelne Datei oder ein Verzeichnis immer als ZIP zurück. Es verwendet ein separates cwd und eine separate Erlaubnisliste als safe-files und veröffentlicht nur Quellen, die an ChatGPT übergeben werden dürfen. Verzeichnisse werden mit festem rg --files --hidden aufgelistet; das Innere von .git, ROMs, Saves, States, private Schlüsselformate, Inhalte mit Anmeldeinformationen, Pfade außerhalb des erlaubten Bereichs und symbolische Links werden abgelehnt. Wenn disallowed_path_globs konfiguriert ist, wird das gesamte Zielverzeichnis geprüft, bevor die vom Benutzer angegebenen globs oder excludePaths angewendet werden; wenn auch nur eine Datei oder ein Ordner mit einem Ablehnungsmuster übereinstimmt, wird die gesamte ZIP-Erstellung abgelehnt. Der Fehler enthält die übereinstimmenden konfigurierten Muster und den Zielpfad.

internet

internet ist ein enthaltenes MCP zum Abrufen einer Datei von einer beliebigen HTTP/HTTPS-URL. Das einzige öffentliche Tool ist download_file, und das Ziel ist auf den Workspace der vom Gateway signierten isolatedId beschränkt. Das Überschreiben vorhandener Dateien, UNC/ADS, Schreiben außerhalb des Workspace sowie das Injizieren beliebiger Header, Cookies oder Anmeldeinformationen werden nicht akzeptiert. Bei einem Fehler während der Übertragung wird die temporäre Datei gelöscht. Dieses MCP wird immer mit sandbox = "onlineworkspace" gestartet. onlineworkspace behält die workspace-write-Dateisystemgrenze von Codex bei und aktiviert nur das Netzwerk dieses Berechtigungsprofils. Es erfolgt kein Fallback auf sandbox = "never".

archive

archive ist ein enthaltenes MCP, das beim Start 7-Zip mit --seven-zip-executable=<absolute-7z.exe-path> festlegt und nur create_zip, create_7z und extract_archive veröffentlicht. Allgemeine Shells, beliebige ausführbare Dateien und beliebige 7-Zip-Argumente werden nicht veröffentlicht. Ein- und Ausgaben sind auf den signierten Workspace beschränkt. extract_archive kann auch dann verwendet werden, wenn Quelle und Ziel in unterschiedlichen erlaubten Wurzeln liegen, sodass beispielsweise ein Archiv aus Downloads direkt in einen Project-Workspace extrahiert werden kann. Das Zielverzeichnis wird erstellt, wenn es nicht existiert; wenn es existiert, werden nur leere normale Verzeichnisse akzeptiert. Pfade werden auch nach der Auflösung auf 1024 Zeichen begrenzt. archive selbst wird ebenfalls in der Codex-Sandbox gestartet, und der 7-Zip-Installationspfad wird über sandbox_read_only_directories als schreibgeschützter Vertrauensinput übergeben.

codespace

codespace ist ein gebündelter MCP, der ausschließlich bereits vorhandene GitHub Codespaces bedient. Der von list_codespaces zurückgegebene name wird als codespaceId für die jeweiligen Tools verwendet. Tools zum Erstellen, Neuerstellen, Ändern der Machine, expliziten Starten oder Löschen von Codespaces sind nicht implementiert. Der Start erfolgt implizit über eine SSH- oder Copy-Verbindung zu einem vorhandenen Codespace; nach Abschluss der Arbeit kann mit stop_codespace ein expliziter Stopp über gh codespace stop -c <name> ausgeführt werden. Vor dem Stopp werden die dieser isolierten Session gehörenden asynchronen SSH-Vorgänge für denselben Codespace abgebrochen und der SSH-Readiness-Cache verworfen. Auch nach dem Stopp werden weder der Codespace selbst noch gespeicherte Änderungen gelöscht. Es gibt keinen Pfad, über den die KI willkürlich Codespaces anlegen kann. Dieselbe codespaceId wird nur von einer einzigen isolierten Session gehalten; greift eine andere neue isolierte Session darauf zu, geht das Eigentum nach dem Prinzip „der Letzte gewinnt“ über. Die alte Session kann es nicht automatisch zurückholen; bei einem Konfliktfehler wird sie angewiesen, über isolated__list den purpose und das lastOperationAt des codespace-Präfixes zu prüfen und den Benutzer um eine Entscheidung zu bitten. Nur Aufrufe mit derselben codespaceId werden im Gateway serialisiert; andere gebündelte MCPs wie files werden nicht unnötig serialisiert. Der MCP selbst startet immer mit sandbox = "onlineworkspace". --gh-executable=<absolute-gh.exe-path> ist erforderlich. Für den Fall, dass die im Windows Credential Manager gespeicherten normalen gh auth login-Anmeldedaten für den Sandbox-Benutzer nicht sichtbar sind, kann optional --token-file=<absolute-file> angegeben werden. Diese Datei wird als fester, schreibgeschützter Trust-Input an das Codex-Berechtigungsprofil übergeben; ihr Inhalt wird nur innerhalb des MCP als GH_TOKEN gesetzt. GH_TOKEN / GITHUB_TOKEN der übergeordneten Umgebung werden nicht geerbt. Benutzer-SSH-Schlüssel werden weder konfiguriert, gelesen noch erlaubt. Die für SSH/cp erforderlichen Schlüssel werden vom Codespace-MCP selbst per ssh-keygen in einem vom Gateway bereitgestellten, nicht versteckten temporären Laufzeitverzeichnis automatisch erzeugt und vom Gateway beim Schließen des untergeordneten MCP gelöscht. Dieses interne Verzeichnis ist nur im Codex-Berechtigungsprofil schreibbar und wird weder zu allowed_directories noch zum normalen Dateizugriffsbereich des Gateways hinzugefügt. gh.exe und die Token-Datei dürfen nicht in schreibbaren allowed_directories liegen. ssh empfängt Remote-Befehle nicht als einzelnen String, sondern als Token-Array und lehnt Shell-Expansion/Metazeichen wie Leerzeichen, Anführungszeichen, !, @, Backticks, $, ;, & und Pipes ab. timeoutMs ist die harte Laufzeit der zugrunde liegenden Operation selbst und getrennt von der Zeit, die auf eine synchrone Antwort gewartet wird. Normalerweise wird nur syncWaitMs lang synchron gewartet, standardmäßig maximal 10.000 ms. Ist die Operation dann nicht abgeschlossen, wird sie ohne Unterbrechung in die gemeinsame asynchrone Registry verschoben und eine asyncId zurückgegeben. syncWaitMs=0..1000 wird sofort als asynchron behandelt; bei async=true wird syncWaitMs ignoriert und von Anfang an sofort eine asyncId zurückgegeben. get_async_status gibt bei Auslassung der asyncId alle in dieser Isolation gehaltenen asynchronen Operationen gesammelt zurück; mit einer einzelnen ID können Details/abgeschlossene Ergebnisse abgerufen werden. get_async_logs dient zum Abrufen des gesamten gehaltenen stdout/stderr von process-backed Jobs. wait_async bleibt als Kompatibilitätsimplementierung erhalten, aber um lange MCP-Antworten und damit Gateway/Tunnel nicht zu belasten, werden normalerweise get_async_status / get_async_logs verwendet. copy_to_codespace sendet lokale Dateien/Verzeichnisse, die unterhalb von sourceDirectory entweder über die Aufzählung paths oder über globs ausgewählt wurden, an ein vom Aufrufer explizit angegebenes remote:-Ziel. Der MCP vermutet remote: nicht und fügt es nicht automatisch hinzu. Beispielsweise wird bei paths=["scripts/a.js"] die Datei unter /workspaces/project/scripts/a.js abgelegt, also unterhalb von remote:/workspaces/project; ein Abflachen auf nur den Basisnamen direkt unter dem Ziel erfolgt nicht. Zur Wahrung der Hierarchie werden nur die erforderlichen übergeordneten Remote-Verzeichnisse mit einem festen Helfer erstellt und jede Auswahl an das entsprechende Ziel kopiert. copy_from_codespace arbeitet in umgekehrter Richtung: Eine vom Aufrufer explizit angegebene Remote-Quelle remote:/workspaces/<workspace>/... wird in ein vorhandenes Zielverzeichnis im signierten lokalen Workspace kopiert. Die Remote-Quelle wird vor dem Kopieren geprüft; Symlinks/Special Entries, eine übermäßige Anzahl von Einträgen und Übertragungen über CODESPACE_MCP_MAX_TRANSFER_BYTES hinaus werden abgelehnt. Existiert der lokale Ziel-Basisname bereits, wird ebenfalls abgelehnt. Bei beiden Kopier-Tools muss nur die Remote-Seite remote: verwenden; die lokale Seite muss ein lokaler Pfad sein. Mehrdeutige Angaben wie fehlendes Remote-Protokoll oder Remote auf beiden Seiten werden abgelehnt. Da gh codespace cp ein bekanntes GitHub-CLI-Problem hat, bei dem auch vorhandene Remote-Pfade ohne -e mit „No such file or directory“ fehlschlagen, wird -e in beiden Richtungen immer gesetzt. remote: selbst wird vom Aufrufer explizit angegeben; der MCP fügt es nicht automatisch hinzu. Die SSH-Readiness wird nur bei Bedarf mit einem festen echo started-Probe geprüft; nur bei einem cp-Fehler während der Cache-Wiederverwendung wird nach dem Probe einmal erneut versucht. Die Remote-Suche listet mit roots nur Workspaces direkt unter /workspaces auf; mit git_root kann das Git-Top-Level eines angegebenen Pfads abgerufen werden. search_text ist eine erstklassige ripgrep-Suche analog zu files__search_text und erfordert bei jedem Aufruf searchBase=/workspaces/<workspace>/.... /, /workspaces, das Home-Verzeichnis, /etc usw. können nicht als Such-Root verwendet werden. searchBase wird auch nach dem Remote-realpath erneut validiert. Query und Glob werden nicht in den SSH-Befehlsstring eingefügt, sondern base64-kodiert und über stdin an ein festes Remote-Skript übergeben. .git ist immer von der Suche ausgeschlossen, eine Datei ist auf 16 MiB begrenzt, und die Ergebnisanzahl ist auf maximal 500 begrenzt. Mit ripgrep_version kann rg --version geprüft werden; install_ripgrep tut nichts, wenn rg bereits vorhanden ist, und installiert es nur bei Bedarf über einen festen Installer mit apt/dnf/yum/apk, bevor die Version erneut geprüft wird. Paketnamen oder beliebige Shell-Strings können nicht über Tool-Argumente übergeben werden. list_temporary_public_deployments ruft die von GitHub bereits erkannten temporären öffentlichen Kandidaten eines Codespace sowie browseUrl / Port / Sichtbarkeit ab. Dies ist kein Tool, das localhost, lauschende Sockets des lokalen PCs, Browser-Tabs oder lokale Entwicklungsserver durchsucht; es findet auch keine automatische Port-Erkennung statt. Wenn GitHub keine Kandidaten liefert, wird kein leeres Array als normales Ergebnis zurückgegeben, sondern ein korrigierender Fehler, der ausdrücklich darauf hinweist, dass „dies kein Fehler der lokalen Port-Autoerkennung ist“ und dass „keine localhost-Suche, kein Port-Scan, keine URL-Vermutung und kein Umweg über gh codespace ports forward“ erfolgt. open_temporary_public_deployment zielt nur auf einen vom Aufrufer explizit angegebenen Codespace-Port, fordert zunächst die Änderung der Sichtbarkeit auf public bei GitHub an und prüft nach Erfolg die vollständige https://...app.github.dev-URL und gibt sie zurück. Ist der genaue Port bekannt, wird dieses Tool direkt aufgerufen; list_temporary_public_deployments ist keine Vorbedingung. Allein aus der Tatsache, dass die Liste 0 Einträge hat, darf nicht geschlossen werden, dass forwardPorts in .devcontainer erforderlich ist. Lehnt GitHub den angegebenen Port ab, wird der tatsächliche Fehler zurückgegeben; es wird nicht localhost durchsucht, um einen alternativen Port zu erraten. close_temporary_public_deployment setzt ebenfalls nur denselben explizit angegebenen Port auf private zurück und schließt die temporäre Veröffentlichung. Keines der Tools erstellt einen localhost-Port-Tunnel und erstellt oder löscht auch keine Forward-Einträge auf GitHub-Seite. Die zurückgegebene browseUrl kann direkt aus Chrome DevTools usw. zur Erreichbarkeitsprüfung der temporären Bereitstellung verwendet werden.

gitmcp

gitmcp führt ausschließlich lokale Operationen an Git-Repositories innerhalb erlaubter Verzeichnisse aus, und zwar nur mit festen Git-Unterbefehlen und -Optionen. Beim Start ist --git-executable=<absolute-path> erforderlich; nur diese ausführbare Datei wird mit shell=false gestartet. Es werden weder eine allgemeine Shell noch beliebige Git-Argumente akzeptiert; direkte Bearbeitung von .git, Hinzufügen von Hooks, Löschen von Branches und Force-Operationen werden nicht unterstützt. add_all, stage_paths, unstage_paths, die den Index umschreiben, sowie commit, push, pull und clone_repository wurden zur Grenztrennung in ein separates git-capability-MCP verschoben. Die alten --disable-push, --disable-pull und --disable-clone werden als No-op akzeptiert, um alte gateway.toml-Dateien nicht unstartbar zu machen; ein Setzen auf false stellt die verschobenen Capabilities jedoch nicht wieder her. Verfügbar sind status, die Auflistung getrackter Dateien, die Prüfung von Branches/Remotes/Verlauf, Arbeitsbaum- oder Staged-Diffs, show eines bestimmten Commits, das Wechseln zu und Auschecken vorhandener Branches, das Erstellen von Branches mit angegebenem Eltern-Commit sowie das Erstellen, Auflisten und normale Löschen von Worktrees innerhalb des erlaubten Roots. Das Löschen von Branches, das Löschen des primären Worktrees und das erzwungene Löschen von dirty oder gelockten Worktrees sind nicht implementiert. Zur Beachtung von .gitignore und der Standard-Ignore-Einstellungen zeigt status keine ignorierten, ungetrackten Dateien an. .gitattributes, .git/info/attributes, globale Attributes, Zeilenumbruch-Konvertierung wie core.autocrlf, Clean/Smudge-Filter aus System-/Global-Konfiguration, externe Diffs und textconv werden wie bei normalem Git respektiert. Ausführbare Konfigurationen in .git/config des Repositories oder in der Worktree-Config werden vorab abgelehnt. Da System-/Global-Filter und Diff-Helfer wie beabsichtigt ausgeführt werden können, wird empfohlen, gitmcp mit Dateizugriffsrechten nach Möglichkeit in der Codex-OS-Sandbox auszuführen. In der Windows-Codex-Sandbox gewährt das :minimal-Read des Berechtigungsprofils System-Read-Roots wie C:\Program Files, sodass das standardmäßige C:\Program Files\Git\cmd\git.exe ohne zusätzliche Read-Einstellungen verwendet werden kann. Nur wenn ein Git außerhalb der System-Read-Roots angegeben wird, z. B. Portable Git, wird dessen Installationsverzeichnis zu sandbox_read_only_directories hinzugefügt. sandbox = "never" ist aus Kompatibilitätsgründen ebenfalls verwendbar. list_worktree_files listet getrackte Dateien und nicht ignorierte, ungetrackte Dateien anhand der eigenen Exclude-Entscheidung von Git auf. check_ignore gibt die auf jeden Pfad angewendeten Ignore-Regeln und die endgültige Entscheidung zurück; check_attributes liefert die effektiven Werte für text, binary, diff, merge, filter, Zeilenumbruch-Attribute usw. get_effective_config schließt credential.*, Autorenname und E-Mail-Adresse von der Abfrage aus und gibt Einstellungen, die das lokale gitmcp-Verhalten betreffen (z. B. core.autocrlf, Filter, Attributes, diff/textconv), mit Scope und Origin zurück. Die Sicherheitsmaßnahme besteht nicht in der vollständigen Deaktivierung der Git-Konfiguration, sondern ausschließlich in der Ablehnung ausführbarer Hooks, Helper, Filter, externer Diffs/textconv, Merge-Driver, Signaturprogramme, Proxys und eigener Transporteinstellungen, die in der .git/config des Repositories selbst oder in der Worktree-Config platziert sind. Hooks, fsmonitor, file- und ext-Protokolle sowie interaktive Credential-Prompts sind deaktiviert. Mit get_policy kann die aktuelle Richtlinie maschinenlesbar geprüft werden. Wird repositoryPath direkt auf ein Submodul oder ein verschachteltes Git-Repository gesetzt, können dessen eigener Status, Diff, Log usw. abgerufen werden. Ein Tool, das das übergeordnete Repository rekursiv durchsucht und automatisch alle verschachtelten Repositories auflistet, ist nicht enthalten.

git-capability

git-capability ist ein gebündelter MCP, das mcp/git-capability/server.mjs mehrfach mit --mode=stage|commit|push|pull|clone registriert und Git-Capabilities nach Verwendungszweck trennt. Da jede Registrierung ein unabhängiges [mcp_servers.<name>] ist, können sandbox, allowed_directories, Timeout und serial_group individuell gewählt werden. sandbox = "never" wird nicht verboten; Nutzer, die Kompatibilität mit dem Git-Index, Signatur-Agents und dem Netzwerk benötigen, können weiterhin den bisherigen Pfad wählen. In allen Modi wird --git-executable=<absolute-path> beim Start festgelegt; Git-Ausführungsdatei, repositoryPath, Umgebungsvariablen und beliebige Git-Argumente können nicht über Tool-Argumente gewählt werden. Über das Gateway ist wie bei normalen gebündelten MCPs ein HMAC-signierter isolierter Workspace erforderlich. Enthält die .git/config des Repositories oder die Worktree-Config ausführbare Hook-/Helper-/Filter-/Diff-/Merge-Driver-/Signaturprogramm-/Proxy-/Transporteinstellungen, werden diese vor der Capability-Ausführung abgelehnt. Der stage-Modus stellt nur add_all, stage_paths und unstage_paths bereit; die Repository-Auswahl wird aus dem signierten Workspace/Base festgelegt. Beim Start des sandboxed Git-MCP durchsucht das Gateway selbst die zum jeweiligen Zeitpunkt unterhalb des schreibbaren Roots vorhandenen .git-Verzeichnisse und fügt dem Codex-Berechtigungsprofil konkrete Git-Metadaten-Schreib-Roots hinzu. Dies basiert darauf, dass is_metadata_write_denied / has_explicit_write_entry_for_metadata_path auf Codex-Seite explizitere Write-Einträge innerhalb geschützter Metadaten erlaubt. .git/hooks, .git/objects/info und .git/modules bleiben schreibgeschützt; auch vorhandene .git/config, config.worktree, commondir und gitdir sind schreibgeschützt. Daher sind Stage- und normale Branch-/Worktree-Metadatenaktualisierungen in der Sandbox verfügbar, Submodul-Hinzufügungen sind jedoch ausgenommen. Neu erstellte .git-Verzeichnisse nach dem Start werden nicht automatisch erlaubt; git init und Sandbox-Clones werden mit diesem Mechanismus nicht behandelt. Auch beim Stage werden Standard-Ignore, Attributes, Zeilenumbruch-Konvertierung und System-/Global-Clean-Filter respektiert; abgelehnte Worktree-Pfade werden zurückgewiesen. Das Tool-Argument des commit-Modus ist nur message; es wird ausschließlich der bereits gestagte Index mit git commit --no-verify -m <message> committet. Stage-Funktionen oder Repository-Auswahl sind nicht vorhanden. Da System-/Global-Commit-Signatureinstellungen beibehalten werden, kann in Konfigurationen, die Zugriff auf den Signatur-Agent benötigen, nur das Commit-MCP auf sandbox = "never" gesetzt werden, während das größere gitmcp in der Sandbox verbleibt. push und pull legen beim Start --remote= und ein oder mehrere --repository=OWNER/REPO fest, normalisieren die Repository-Identität aus der Remote-URL und gleichen sie mit einer der Zulassungslisten ab. Daher werden https://github.com/OWNER/REPO.git und git@github.com:OWNER/REPO.git als dasselbe Repository behandelt; eine teilweise Übereinstimmung des Repository-Namens wird jedoch nicht erlaubt. Sollen mehrere Workspaces für eine Capability erlaubt werden, kann --repository= wiederholt werden. Das alte --expected-remote-url=<exact-url> ist aus Kompatibilitätsgründen ebenfalls verwendbar. Tool-Aufrufe akzeptieren weder Remote, URL noch Refspec. Push sendet nur den aktuellen Branch ohne Force und ändert die Upstream-Konfiguration nicht. Pull holt die feste Remote, wendet die Pfadrichtlinie auf den eingehenden Baum an und führt dann mit --ff-only in den gleichnamigen aktuellen Branch ein. clone stellt das bisherige --url= beim Start ein und akzeptiert auf Tool-Seite url, einen neuen Unterverzeichnisnamen und optional depth. url erlaubt http://, https://, ssh://user@host/path und user@host:path für beliebige Hosts. Eingebettete Anmeldedaten in HTTP(S)-URLs und Passwörter in SSH-URLs werden abgelehnt; normale Authentifizierungspfade wie Git-Credential-Helper, askpass, SSH-Agent/SSH-Konfiguration bleiben erhalten. Nach dem Abrufen mit --no-checkout werden die erlaubten/abgelehnten Pfade des eingehenden Baums geprüft und dann ausgecheckt; bei Fehlschlag wird nur das in diesem Aufruf neu erstellte Clone-Ziel gelöscht. Submodul-Rekursion und beliebige Eltern werden nicht bereitgestellt.

gh-workflow

gh-workflow prüft für GitHub-Repositories, die explizit über das Startargument --repository=OWNER/REPO erlaubt wurden, den Ausführungsstatus von GitHub Actions und bricht explizit angegebene Runs ab. --repository= kann mehrfach angegeben werden; nicht angegebene Repositories können nicht ausgewählt werden. Ist genau ein Repository erlaubt, kann es in jedem Tool weggelassen werden; bei mehreren ist die Angabe des Ziel-Repositories erforderlich. Im Konfigurationsbeispiel wird DaisukeDaisuke/desmume_webassembly angegeben; der MCP selbst ist standardmäßig deaktiviert. Neben Tools, die gh run list --branch main --limit 3, gh run watch RUN_ID --exit-status, gh run cancel RUN_ID und gh run view RUN_ID entsprechen, können Job-Listen, vollständige Logs, Fehler-Logs, Workflow-Listen, Workflow-Übersichten und Workflow-YAML abgerufen werden. cancel_run übergibt nur eine validierte dezimale Run-ID und das erlaubte Repository als feste Argumente. Workflow-Dispatch, Rerun, Delete, Artifact-Download und gh api werden nicht bereitgestellt. gh wird direkt über spawn mit shell=false gestartet; Unterbefehle und Optionen sind festgelegt. Run-ID, Branch und Workflow-Identifikator werden einzeln validiert, stdin wird geschlossen und die Ausgabegröße begrenzt. Das cwd des Unterprozesses muss immer explizit in gateway.toml angegeben werden. Zur Authentifizierung können die lokal über gh auth login gespeicherten GitHub-CLI-Einstellungen verwendet werden.

codex-script

codex-script ist ein gebündelter MCP, das beim MCP-Start mit --runtime=mjs|nodejs|python|php und --runtime-executable=<absolute-path> die Ausführungslaufzeit festlegt und nur Skripte ausführt, die bereits im erlaubten Workspace vorhanden sind. Dasselbe server.mjs kann mehrfach registriert und unter unabhängigen Präfixen wie mjs_script, nodejs_script, python_script und php_script bereitgestellt werden. Im --mode=run wird run_script bereitgestellt, im --mode=check check_file. run_script startet nur die Laufzeit selbst; check_file startet nur die festen Checker: Node.js --check, Python py_compile, PHP -l. check_file kann zusätzlich zur abwärtskompatiblen Einzelangabe filePath mit filePaths bis zu 500 Dateien in einem Aufruf prüfen; die Rückgabe besteht aus pass, fault und messages nur für fehlgeschlagene Dateien. stdout/stderr erfolgreicher Checker werden nicht zurückgegeben. Allgemeine Shells, beliebige ausführbare Dateien, beliebige Umgebungsvariablen-Injektion, npm-Skripte und Package-Manager-Aufrufe werden nicht bereitgestellt. Argumente werden als literale argv übergeben, stdin wird geschlossen, Timeout und Ausgabegröße werden begrenzt. Das Gateway behandelt codex-script als isBundled und wendet die über isolatedId ausgewählten signierten Bases/Roots sowie die normale Pfadrichtlinie an. Zusätzlich wird codex-script beim Laden der Konfiguration abgelehnt, wenn in gateway.toml sandbox = "never" angegeben ist; der MCP-Prozess selbst muss in der Codex-Windows-Sandbox mit elevated oder unelevated gestartet werden. Statt für jeden Skriptaufruf eine separate Sandbox zu erstellen, läuft die feste Laufzeit als Unterprozess des bereits sandboxierten MCP. Da im --mode=run beliebiger Code innerhalb des erlaubten Workspace ausgeführt wird, sollten allowed_directories minimal gehalten und Laufzeit, Codex-CLI und MCP-Ausführungsdatei außerhalb der schreibbaren Roots platziert werden. disallowed_directories und disallowed_files können als exakte deny-Einträge des äußeren Codex-Berechtigungsprofils verwendet werden. disallowed_path_globs können nicht sicher in eine äquivalente Form für die Sandbox beliebigen Codes umgewandelt werden und werden daher sowohl für run als auch check abgelehnt; falls erforderlich, durch exakte Deny-Einträge ersetzen oder allowed_directories selbst einschränken.

Hinzufügen beliebiger stdio-MCPs

Startbefehl und Argumente des zu verbindenden MCP werden nicht im Gateway selbst, sondern in [mcp_servers.<name>] unter config/gateway.toml beschrieben.

private_use_only = true
publish_tool_directory = false
[mcp_servers.example]
command = "py"
args = ['C:\path\to\server.py']
cwd = 'C:\path\to'
enabled = true
prefix = "example"
annotation_config = true
startup_timeout_sec = 30
tool_timeout_sec = 1800
allowed_directories = ['C:\work\project']
allowed_files = ['C:\Users\owner\Downloads\one-upload-file.png']
[mcp_servers.example.env]
EXAMPLE_CONFIG = 'C:\path\to\config.json'

Nur gültige stdio-MCPs werden als Unterprozesse gestartet; der ursprüngliche Tool-Name tool_name wird auf ChatGPT-Seite als example__tool_name bereitgestellt. Einträge mit enabled = false werden nicht gestartet. Aus der Codex-Konfiguration kopierte tool_output_token_limit, tool-spezifische Genehmigungseinstellungen und vom Gateway nicht erkannte Einträge werden ignoriert. Sie haben in diesem Gateway keine Wirkung.

Tool-Annotations externer MCPs

Externe MCPs werden veröffentlicht, wobei die von den untergeordneten MCPs zurückgegebenen annotations als Grundlage dienen und fehlende readOnlyHint-, destructiveHint-, idempotentHint- und openWorldHint-Werte durch explizite Werte ergänzt werden. Wenn ein untergeordneter MCP nur readOnlyHint = true zurückgibt, werden destructiveHint = false und idempotentHint = true ergänzt, sofern keine explizite Angabe vorliegt. Beim Start des Gateways wird die unter tool_annotations_path angegebene TOML-Datei erstellt, falls sie nicht existiert. Wenn für das Präfix eines gültigen externen MCPs kein [tool_annotations.<prefix>] vorhanden ist, wird es am Ende hinzugefügt. Die von den untergeordneten MCPs abgerufenen Tool-Identifikationsnamen werden ebenfalls als UNCLASSIFIED unter [tool_annotations.<prefix>.tools] ergänzt. Vorhandene Präfix-Konfigurationen oder Tool-Zuweisungen werden nicht überschrieben, und verschwundene Tools werden auch nicht automatisch gelöscht. Die mitgelieferten MCPs definieren annotations in ihren jeweiligen server.mjs-Dateien, daher wird in gateway.toml annotation_config = false gesetzt. Für externe MCPs wird bei Auslassung true angenommen. In der automatisch generierten TOML-Datei werden die Bedeutung der folgenden Kurznamen und der vier Hints als Kommentare festgehalten. open_world_hint überschreibt den openWorldHint für das gesamte Präfix, open_world_tools für einzelne Tools.

[tool_annotations.chrome-devtools]
default = "LOCAL_STATE_ANNOTATIONS"
open_world_hint = true
[tool_annotations.chrome-devtools.tools]
take_snapshot = "READ_ONLY_ANNOTATIONS"
click = "UNCLASSIFIED"
[tool_annotations.chrome-devtools.open_world_tools]
take_snapshot = false
click = true

UNCLASSIFIED ist ein unklassifizierter Marker, der die vorhandenen Werte der vom untergeordneten MCP zurückgegebenen annotations beibehält und nur fehlende Hints ergänzt. Bei der Klassifizierung wird der Wert jedes Tool-Identifikationsnamens in einen der folgenden Werte geändert: READ_ONLY_ANNOTATIONS, LOCAL_STATE_ANNOTATIONS, LOCAL_DESTRUCTIVE_IDEMPOTENT_ANNOTATIONS, LOCAL_DESTRUCTIVE_NON_IDEMPOTENT_ANNOTATIONS, LOCAL_ADDITIVE_IDEMPOTENT_ANNOTATIONS.

Gateway-Konfiguration

Die Entscheidungen des Benutzers werden respektiert

Das Verhalten des Gateways wird durch die Konfiguration bestimmt, die der Benutzer explizit in config/gateway.toml festgelegt hat. Das Gateway erkennt MCPs nicht automatisch und registriert sie nicht eigenmächtig, und es schreibt Konfigurationsdateien auch nicht automatisch um. Eine Ausnahme bilden die Tool-annotations externer MCPs: Hier werden nicht registrierte Präfixe und neu entdeckte Tool-Identifikationsnamen in die unter tool_annotations_path angegebene separate TOML-Datei ergänzt. Neue Tools werden als UNCLASSIFIED eingestuft, während gateway.toml, vorhandene Präfixe und vorhandene Tool-Konfigurationen unverändert bleiben. Die zu verbindenden MCPs, deren Startbefehle, Argumente, Arbeitsverzeichnisse, Umgebungsvariablen, Aktivierung/Deaktivierung, der Codex-Sandbox-Modus, die schreibgeschützten Pfade für die Sandbox, nicht zu veröffentlichende Tools, der erlaubte bzw. verweigerte Pfadbereich, die serielle Ausführung und der verzögerte Start werden alle vom Benutzer gewählt. Das Gateway liest diese Konfiguration, validiert und wendet sie an, fügt aber keine Einstellungen hinzu, die Sicherheit oder Verwendungszwecke anstelle des Benutzers vermuten, und erweitert auch nicht den erlaubten Bereich. config/gateway.example.toml ist ein Konfigurationsbeispiel und kein „magisches Skript", das direkt angewendet wird. Es ist so aufgebaut, dass der Benutzer nur die erforderlichen Einträge prüft, sie in config/gateway.toml einträgt und selbst überblicken kann, welche Programme tatsächlich gestartet und welche Funktionen veröffentlicht werden.

Es wird keine allgemeine Befehlsausführung bereitgestellt

Dieses Repository enthält keinen allgemeinen Befehls-Runner, der allgemeine Shells, PowerShell, die Eingabeaufforderung, die Auswahl beliebiger ausführbarer Dateien oder die Injektion beliebiger Umgebungsvariablen direkt mit Windows-Benutzerrechten veröffentlicht. Die Ausnahme ist das oben genannte codex-script, das die Ausführungslaufzeit beim Start des MCPs festlegt und nur vorhandene Skripte innerhalb des erlaubten Workspace in der Codex-Windows-Sandbox ausführt. Dies ist kein Mechanismus, der beliebigen Code allein durch Pfadfreigaben absichert, sondern ein eingeschränkter Skript-Runner, der ein OS-Sandbox zwingend voraussetzt. Wenn allgemeine beliebige Codeausführung direkt veröffentlicht würde, könnten Verbindungsinformationen wie Tunnel-ID oder Runtime-API-Schlüssel unbeabsichtigt nach außen gelangen. Im Falle eines Missbrauchs könnte ein Angreifer beliebige Operationen mit Windows-Benutzerrechten ausführen. Daher sollte auch beim Hinzufügen externer MCPs für beliebige Codeausführung sandbox = "elevated" oder "unelevated" verwendet und das beschreibbare Root-Verzeichnis auf das notwendige Minimum begrenzt werden. Für Aufgaben, die keine lokale Ausführung erfordern, wie Codegenerierung oder -konvertierung, sollte weiterhin die Sandbox auf der ChatGPT-Seite bevorzugt werden. Wenn nur lokale Quellen übergeben werden sollen, können mit safe-download nur die freigegebenen Dateien als ZIP gepackt werden.

Schutz des Gateway-Ausführungscodes

Wenn protect_gateway_app = true gesetzt ist, wird das app-Verzeichnis des Gateways selbst auch dann als schreibgeschützt für untergeordnete MCPs behandelt, wenn es sich mit dem erlaubten Workspace überschneidet. Der Standardwert im Gateway-Code ist false, im mitgelieferten Konfigurationsbeispiel jedoch true. Bei sandboxed MCPs werden dem Codex-Berechtigungsprofil spezifischere Lese-Einträge hinzugefügt, und bei safe-files werden Schreib-, Ersetzungs-, Move-Quell-Lösch-, Patch- und Unterverzeichniserstellungsvorgänge verweigert, während Lesen und file_info erhalten bleiben. Bei file_info werden geschützte Objekte mit prohibited=true angezeigt. Diese Einstellung stellt keine OS-Grenze dar, falls ein untergeordneter Prozess mit sandbox = "never" bis zur beliebigen Codeausführung kompromittiert wird. Bei never kann das untergeordnete Element selbst die Gateway-Pfadrichtlinie ignorieren. Für Anwendungsfälle, in denen ein erzwungenes Schreibverbot für ausgeführten Code erforderlich ist, verwenden Sie die Codex-OS-Sandbox.

Pfadfreigaben

allowed_directories erlaubt die angegebenen Verzeichnisse und deren Unterverzeichnisse, allowed_files erlaubt nur die angegebenen Dateien mit exakter Übereinstimmung. Das Gateway prüft rekursiv alle Tool-Argumente aller untergeordneten MCPs und gleicht Schlüssel wie path, filePath, files, directory sowie Zeichenfolgen, die wie absolute Pfade aussehen, mit der Freigabeliste ab. Relative Pfade werden ausgehend vom cwd des jeweiligen MCPs aufgelöst. Das jedem untergeordneten MCP automatisch hinzugefügte <prefix>__get_gateway_access_scope gibt die für diese Prüfung verwendeten Konfigurationswerte und den normalisierten effektiven Geltungsbereich zurück. Es ist ein Tool, mit dem die KI den aktuellen Gateway-Zustand direkt überprüfen kann, anstatt das Arbeitsverzeichnis oder die erlaubten Pfade aus früheren Gesprächen zu erraten.

allowed_directories = ['C:\work\project']
allowed_files = ['C:\Users\owner\Downloads\upload.png']
disallowed_directories = ['C:\work\project\private']
disallowed_files = ['C:\work\project\.env']
disallowed_path_globs = ['**.ssh**']

disallowed_path_globs sind Verweigerungs-Globs, die auf den gesamten normalisierten Pfad angewendet werden und sowohl Dateien als auch Ordner betreffen. * entspricht einer beliebigen Zeichenfolge ohne Pfadtrenner, ** einer beliebigen Zeichenfolge einschließlich Pfadtrenner, ? einem beliebigen einzelnen Zeichen außer Pfadtrenner. Beispielsweise lehnt '**.ssh**' alles einheitlich ab, wenn der Pfad irgendwo .ssh enthält. Unter Windows werden \ und / als derselbe Trenner behandelt, und es wird nicht zwischen Groß- und Kleinschreibung unterschieden. Unter macOS und Linux wird / als Trenner behandelt, und es wird zwischen Groß- und Kleinschreibung unterschieden. Bei einer Verweigerung werden in der Fehlermeldung angezeigt, dass die Verweigerung durch disallowed_path_globs erfolgt ist, der übereinstimmende Glob und der normalisierte Zielpfad. Die Prüfung auf der Gateway-Seite ist ein Schutz für Tool-Argumente, die von ChatGPT an untergeordnete MCPs übergeben werden. Die mitgelieferten safe-files, safe-images, safe-download, gitmcp, git-capability und codex-script verwenden zusätzlich signierte Workspace-Kontexte und die eigene Pfadvalidierung jedes MCPs. Bei Drittanbieter-MCPs kann der interne Dateizugriff nicht allein durch den Argument-Guard des Gateways eingeschränkt werden. Daher werden solche MCP-Prozesse bei Bedarf mit sandbox = "elevated" oder "unelevated" in der Codex-OS-Sandbox gestartet.

Format der MCP-Server-Konfiguration

Das Gateway verwendet – wie die MCP-Konfiguration von Codex – ein Format, bei dem die Konfiguration für jeden MCP in einer [mcp_servers.<name>]-Tabelle zusammengefasst wird. Es handelt sich nicht um eine Kompatibilitätsfunktion, die die Codex-Konfigurationsdatei direkt liest, sondern das Gateway erkennt nur die von ihm implementierten Einträge. Beim Hinzufügen eines MCPs zu config/gateway.toml wird ohne # für Kommentare wie folgt geschrieben. Das Folgende ist eine Vorlage mit allen vom Gateway erkannten Optionen.

private_use_only = true
protect_gateway_app = true
publish_tool_directory = false
tool_annotations_path = "tool-annotations.toml"

[mcp_servers.my_server]
command = 'C:\Program Files\nodejs\node.exe'
args = ['C:\path\to\server.mjs', '--example=value']
cwd = 'C:\work\project'
enabled = true
sandbox = "elevated"
codex_executable = 'C:\Users\owner\AppData\Roaming\npm\codex.cmd'
sandbox_read_only_directories = ['C:\path\to\read-only-data']
prefix = "my_server"
annotation_config = true
dangerous_allow_gateway_config_access = false
startup_timeout_sec = 30
tool_timeout_sec = 1800
serial_group = "my_server"
deferred = true
blocked_tools = ["dangerous_tool"]
blocked_tool_substrings = ["script", "shell", "execute"]
allowed_directories = ['C:\work\project']
allowed_files = ['C:\Users\owner\Downloads\upload.png']
disallowed_directories = []
disallowed_files = []
disallowed_path_globs = []

[mcp_servers.my_server.start_after]
server = "controller"
tool = "prepare_my_server"

[mcp_servers.my_server.stop_after]
server = "controller"
tool = "stop_my_server"

[mcp_servers.my_server.env]
EXAMPLE_CONFIG = 'C:\path\to\config.json'

Normale MCPs werden mit deferred = false oder weggelassenem Wert gestartet. In diesem Fall ist start_after nicht erforderlich. Bei sandbox = "elevated" oder "unelevated" ist das Netzwerk des Codex-Berechtigungsprofils deaktiviert; nur sandbox = "onlineworkspace" aktiviert das Netzwerk. In jedem Sandbox-Modus werden allowed_directories als Schreibzugriff und allowed_files sowie sandbox_read_only_directories als Lesezugriff konfiguriert. Zusätzlich werden bei Bedarf das Verzeichnis der MCP-Ausführungsdatei, das Entry-Skript-Verzeichnis bekannter Interpreter und bei gebündelten MCPs das app-Verzeichnis des Gateways als Lesezugriff hinzugefügt. codex_executable muss außerhalb des beschreibbaren Root-Verzeichnisses liegen, und bei elevated und onlineworkspace muss auch der command selbst außerhalb des beschreibbaren Root-Verzeichnisses liegen. Auch bei sandboxierten externen MCPs werden disallowed_directories, disallowed_files und die geschützte gateway.toml mit absolutem Pfad als deny an das Codex-Berechtigungsprofil übergeben, sodass exakte Deny-Löcher innerhalb des Schreib-Root-Verzeichnisses genutzt werden können. Andererseits werden die Gateway-eigenen disallowed_path_globs bei sandboxierten externen MCPs mit Fail-Closed-Verhalten abgelehnt, da keine Garantie für eine äquivalente Umwandlung in die Glob-Semantik von Codex besteht. Gebündelte MCPs sind eine Ausnahme von dieser Kompatibilitätsprüfung, da sie die Glob-Deny-Richtlinie des Gateways selbst validieren. Remote-MCP-Konfigurationen über url werden abgelehnt. Das Codex-spezifische tool_output_token_limit wird zwar gelesen, aber nicht verwendet und hat auf diesem Gateway keine Wirkung. Mit den Umgebungsvariablen LOCAL_MCP_FILES_MAX_RESPONSE_BYTES und LOCAL_MCP_CODESPACE_MAX_RESPONSE_BYTES des Gateways kann das Limit der endgültigen JSONL-Antwort, die files__* bzw. codespace__* an den Tunnel zurückgeben, in Bytes geändert werden. Bei Weglassen beider Werte beträgt das Limit 15 KB (15360 Bytes). Bei Überschreitung des Limits wird die tatsächliche Größe der zurückgegebenen Zeichenkette in KB, MB und GB angegeben, und anstelle des eigentlichen Ergebnisses werden nur die ersten 1024 Bytes (1 KB) des ursprünglichen finalen JSONL als Debug-Vorschau zurückgegeben. Die Warnung „Möglicherweise wurden bereits zerstörerische Vorgänge ausgeführt." wird beibehalten. Bei files__* wird die Verwendung von downloads__download_zip empfohlen, bei codespace__* wird empfohlen, große Ausgaben in einer Datei zu speichern und mit codespace__copy_from_codespace abzurufen oder die Abfrage einzugrenzen. Dieses Gateway-Antwortlimit gilt nur für files__* und codespace__*, nicht für die eigenen Limits von downloads__* oder images__*. Auch innerhalb der Codespace-MCP begrenzt CODESPACE_MCP_MAX_OUTPUT_BYTES die Speichermenge von stdout/stderr; der Standardwert beträgt 15 KB. Auch dieser Wert kann über eine Umgebungsvariable geändert werden.

Integriertes Tool-Verzeichnis

Wenn auf oberster Ebene publish_tool_directory = true angegeben wird, werden gateway__list_available_tools, gateway__get_prefix_list und gateway__get_config veröffentlicht. gateway__get_prefix_list gibt zusätzlich zu den aktuell laufenden Präfixen mit veröffentlichten Tools das integrierte gateway des Gateways und, falls gebündelte MCPs ausgeführt werden, isolated zurück. gateway__list_available_tools und gateway__get_prefix_list greifen nur auf das bereits im Gateway vorhandene Verzeichnis veröffentlichter Tools zu. gateway__get_config gibt aus den beim Start geladenen Einstellungen nur name, prefix, allowed_directories, allowed_files, disallowed_directories, disallowed_files, disallowed_path_globs und die schreibgeschützten Pfade für die Sandbox jeder MCP als JSON zurück. Die Konfigurationsdatei wird nicht neu geladen; der Pfad der Konfigurationsdatei selbst, env, args, command und andere Geheimwerte werden nicht zurückgegeben. MCPs mit enabled = false werden nicht gestartet; bei gateway__list_available_tools wird nur der Name an disabledProxyNames und bei gateway__get_config nur der Name an disabledServerNames zurückgegeben. Wird die Eingabe weggelassen, werden alle derzeit verfügbaren Tools zurückgegeben; wird prefix angegeben, wird ohne Beachtung der Groß-/Kleinschreibung anhand eines Präfixabgleichs des vollständigen Bezeichners gefiltert. Bei null Treffern wird kein Fehler ausgegeben, sondern alle Einträge werden zurückgegeben. Die zurückgegebenen Tool-Informationen bestehen nur aus dem ausgeschriebenen öffentlichen Namen wie chrome-devtools__click und der Beschreibung. Eingabeschema, Ausgabeschema, Startbefehl, Argumente, Pfade, Umgebungsvariablen und abgelehnte Toolnamen werden nicht zurückgegeben. enabledProxyCount ist die Anzahl der konfigurativ aktiven MCPs, rejectedToolCount die Anzahl der Tools, deren Veröffentlichung von gestarteten MCPs abgelehnt wurde. Beim [gateway] INFO-Log bei der Gateway-Initialisierung werden nur die abgelehnten Tools einzeln protokolliert; die Namen der veröffentlichten einzelnen Tools werden nicht aufgelistet. Stattdessen werden die gefundenen/abgelehnten/veröffentlichten Anzahlen pro Präfix, Präfixe mit enabled = false, fehlgeschlagene Startpräfixe und die Gesamtsumme protokolliert.

Ausschluss veröffentlichter Tools

Tools können per exakter Übereinstimmung des Namens mit blocked_tools und per nicht groß-/kleinungsabhängiger Teilstreckenübereinstimmung mit blocked_tool_substrings von der Veröffentlichung ausgeschlossen werden.

blocked_tools = ["dangerous_tool"]
blocked_tool_substrings = ["script", "shell", "execute"]

blocked_tool_substrings ist weder ein Glob-Muster noch ein regulärer Ausdruck. Beispielsweise erfasst "script" alle Vorkommen von evaluate_script, runScript und SCRIPT_debug.

Serielle Ausführung und verzögerter Start

MCPs, die nicht gleichzeitig auf dieselbe Ressource zugreifen sollen, können derselben serial_group zugewiesen werden. MCPs mit deferred = true werden bei der Initialisierung nicht gestartet, sondern können nach erfolgreichem Abschluss eines angegebenen Tools einer anderen MCP mit start_after gestartet werden. Mit stop_after können sie ebenso gestoppt werden.

[mcp_servers.browser]
command = "node"
args = ["browser-server.mjs"]
cwd = ".."
enabled = true
prefix = "browser"
deferred = true
serial_group = "browser"
[mcp_servers.browser.start_after]
server = "controller"
tool = "prepare_browser"
[mcp_servers.browser.stop_after]
server = "controller"
tool = "stop_browser"

Sicherheitsannahmen

[!WARNING] Der command in gateway.toml führt lokale Programme aus. Registrieren Sie nur vertrauenswürdige MCPs. Manche Befehle laden MCP-Programme aus dem Internet herunter und führen sie direkt aus. Der in gateway.toml angegebene Befehl wird nicht in einer Sandbox, sondern auf dem tatsächlichen PC mit den Berechtigungen des Windows-Benutzers ausgeführt. Geben Sie keine nicht vertrauenswürdigen MCPs an.

Das Gateway verweigert den Start mit Administratorrechten und vererbt keine Umgebungsvariablen, die wie Geheimnisse des übergeordneten Prozesses aussehen, unverändert an untergeordnete MCPs. Es isoliert jedoch nicht auf Betriebssystemebene Dateien, die derselbe Windows-Benutzer lesen kann. Es wird empfohlen, den Tunnel nur mit der eigenen Platform-Organisation und dem eigenen ChatGPT-Arbeitsbereich zu verknüpfen und dem Runtime-API-Schlüssel keine anderen Berechtigungen als Tunnels Read + Use zu erteilen. Weitere Einzelheiten finden Sie in SECURITY.md und INSTALL.md.

SDK

Laden Sie das ZIP des main-Zweigs und tunnel-client-source herunter, hängen Sie sie an ChatGPT an und senden Sie die folgende Eingabeaufforderung, um eine signaturfähige gebündelte Stdio-MCP zur Aufnahme in dieses Repository erstellen zu lassen. Wenn Sie die erzeugte MCP nur als normale externe MCP registrieren, wird der signierte isolierte Arbeitsbereich des Gateways nicht gesendet. Legen Sie sie als mcp/<name>/server.mjs ab und wenden Sie auch die Änderung an, um sie in BUNDLED_SERVER_PATHS in app/server-config.mjs zu registrieren. Ersetzen Sie <Describe the MCP tools you need here.> durch eine konkrete Beschreibung der zu erstellenden Tools und der zu bearbeitenden Objekte.

The attached local-mcp-chatgpt-tunnel-main.zip is the SDK and reference implementation. Inspect it before writing code.
Create a new bundled stdio MCP at mcp/<name>/server.mjs for the following purpose:

<Describe the MCP tools you need here.>

Requirements:
- Return the complete mcp/<name>/server.mjs file, the exact app/server-config.mjs BUNDLED_SERVER_PATHS patch required to mark it as bundled, and the minimal config/gateway.toml entry.
- Do not modify the attached archive directly. Return complete replacement content or an exact patch for every required file.
- Use only Node.js built-in modules and the repository's existing local helpers unless I explicitly permit another dependency.
- Follow the repository's MCP protocol handling, JSON Schema conventions, outputSchema declarations, tool annotations, error handling, stdout/stderr separation, timeouts, and bounded-output design.
- Write only JSON-RPC protocol messages to stdout. Write diagnostics and logs to stderr.
- Import createBundledIsolation and environmentWithoutBundledIsolationKey from ../../app/bundled-isolation.mjs. Every tools/call operation must run through createBundledIsolation().run(arguments, operation) before any side effect or path access.
- In Gateway mode, LOCAL_MCP_GATEWAY_ISOLATION_KEY is present. Every call must require and verify the private __localMcpIsolation envelope. Missing, malformed, unsupported-version, unsigned, or incorrectly signed envelopes must fail closed before the public tool executes. Do not implement an unsigned fallback while the key is present.
- The Gateway sends the signature and the paths permitted for that call together in this private argument. This is the envelope shape; the signature placeholder below is not a valid signature:
  {
    "__localMcpIsolation": {
      "version": 1,
      "roots": ["C:\\work\\project"],
      "base": "C:\\work\\project",
      "signature": "<64 hexadecimal HMAC-SHA-256 characters>"
    }
  }
- Verify HMAC-SHA-256 over exactly JSON.stringify({ base, roots }) using LOCAL_MCP_GATEWAY_ISOLATION_KEY, compare signatures in constant time, require one or more absolute roots, and require base to be an absolute path inside at least one root. Prefer the repository helper instead of duplicating the cryptographic code.
- Treat the verified roots and base as the only authoritative path context in Gateway mode. roots are the directories the operation may access; base is the current relative-path base. Never replace them with process.cwd(), a public argument, a cached global root, or a path remembered from another call.
- Reject public arguments named root, roots, workspace, workspaces, or equivalent nested variants. Public tool input must not override the signed path context.
- Never expose LOCAL_MCP_GATEWAY_ISOLATION_KEY or pass it to subprocesses. When spawning a child process, use environmentWithoutBundledIsolationKey() or an equivalent explicit environment filter.
- Shell injection must be impossible under all circumstances. Treat every MCP argument, path, filename, identifier, option, and environment-derived value as untrusted input.
- Never pass a constructed or user-controlled command string to a shell. Do not use child_process.exec, execSync, spawn with shell: true, cmd.exe /c, powershell -Command, bash -c, or sh -c.
- When a native program is genuinely required, invoke a fixed executable directly with spawn or execFile, shell: false, a fixed subcommand, and individually validated arguments. Use an explicit allowlist and a -- separator where the target program supports it.
- Do not expose a general-purpose command runner, arbitrary script execution, arbitrary executable selection, arbitrary environment-variable injection, or unrestricted native-program arguments.
- Implement `roots`, `get_working_directory`, and `set_working_directory` only when the MCP has a real filesystem, repository, workspace, current-directory, input-directory, or output-directory concept. If the capability has no directory concept, do not add these tools and do not invent a meaningless root.
- When those directory tools are applicable, `roots` must return only the verified signed roots and current base, `get_working_directory` must return the verified base, and `set_working_directory` must accept an absolute path or a path relative to the current base, resolve it to an existing directory inside one signed root, apply every deny rule, and return the canonical absolute path. Gateway interception and direct standalone behavior must both remain safe.
- Any stdio MCP that performs filesystem operations must support and enforce these exact configuration arrays:
  `allowed_directories = []`
  `allowed_files = []`
  `disallowed_directories = []`
  `disallowed_files = []`
  `disallowed_path_globs = []`
- Apply the allowlist and denylist to every filesystem operation, including working-directory changes. Deny rules must take precedence over allow rules.
- Resolve relative filesystem paths from the verified base. Absolute paths may be accepted only when they remain inside a verified root and pass the complete configured allow/deny policy.
- Reject parent traversal that escapes a signed root, root-relative ambiguity, drive-relative paths, UNC paths unless explicitly required and safely constrained, NTFS alternate data streams, and any syntax that could reinterpret the target. Canonicalize existing paths and verify the real target remains inside a signed root after symlink resolution.
- Do not require callers to provide redundant absolute paths when the same target can be identified safely relative to the verified base.
- A tool that accepts input files must accept multiple files as an array unless the underlying operation can inherently and safely operate on exactly one file. Validate every file independently and enforce bounded file counts, sizes, and output sizes.
- For build-related tools, require the caller to select a narrow project, target, package, configuration, or input-file set. Do not default to building an entire workspace or repository when a narrower target is possible. Keep the executable, subcommand, and build options fixed or allowlisted.
- This stdio MCP is not executed inside the ChatGPT sandbox. It runs on the user's real Windows PC with the permissions of the current Windows user. Remove unsafe capabilities by design instead of relying on the model to ask for confirmation.
- Do not download, install, update, or access the network unless I explicitly require that behavior. If network access is required, restrict destinations and operations to an explicit allowlist.
- Close child-process stdin, impose timeouts and output limits, handle cancellation and termination, and return structured MCP errors without crashing the process.
- Include clear tool descriptions, strict input schemas, strict output schemas, accurate annotations, and a short security explanation for every capability.
- Prefer a small, auditable implementation. Do not add convenience features that expand the security boundary beyond the stated purpose.

Diagnose und Tests

Es werden die erforderlichen Befehle erkannt und die Versionen überprüft. Es werden keine Installationen oder Konfigurationsänderungen vorgenommen.

node app\doctor.mjs

Die Tests des Repositorys können wie folgt ausgeführt werden:

npm test

Es gibt keine externen npm-Abhängigkeiten.

Lizenz

Dieses Repository selbst steht unter der MIT-Lizenz. Informationen zu Drittanbieterkomponenten wie der offiziellen tunnel-client.exe finden Sie in THIRD_PARTY_NOTICES.md.

Hinweise

Ist die Verbindung von ChatGPT zu einer lokalen MCP ein „grauer Trick"?

https://gist.github.com/DaisukeDaisuke/0d0af93dd8cb376a36879702afb176ee