GPT Harness

Ein selbst gehosteter MCP-Gateway, der es ChatGPT Web ermöglicht, Shell-Befehle auf einem Server auszuführen, den du kontrollierst.

[!WARNUNG] Dies ist ein persönliches Experiment, kein Produkt. Es übergibt ganze Shell-Befehle an ein Sprachmodell und führt sie auf deinem Server aus. Lies Über das Sicherheitsmodell, bevor du es ausführst.

Warum es das gibt

ChatGPT Web kann gut mit Code argumentieren. Mit dem GitHub-Connector liest und bearbeitet es ein Repository. Was es nicht kann, ist etwas auszuführen, weil seine eigene Umgebung keinen Netzwerkzugriff hat. Es kann keine Abhängigkeit installieren oder eine Testsuite ausführen.

Codex kann beides, aber die agentische Nutzung wird separat von Chat abgerechnet und begrenzt. Chat ist viel später aufgebraucht oder gar nicht.

Der Gateway schließt diese Lücke. ChatGPT entscheidet, was zu tun ist, und dein Server führt es aus. Dein Nachrichtenkontingent wird zur Grenze, anstatt eines Agentenbudgets.

@gpt-harness work this ticket
  git clone, write code, npm ci, npm test, repeat until green

@gpt-harness review this PR <link>
  gh pr checkout, run its tests, report back

Related MCP server: Personal AIVA MCP Bootstrap

Was es bereitstellt

Vier Tools: bash, bash_output, bash_kill und write_file. Die Tool-Referenz dokumentiert die Argumente, Ergebnisse und Grenzen.

Es gibt kein Workspace-Tool und kein Workspace-Konzept. Projekte sind Verzeichnisse unter HARNESS_ROOT, und ChatGPT verwendet ls und mkdir wie jeder andere.

Drei der vier Tools existieren wegen einer Einschränkung. Ein einzelner Tool-Aufruf kann nicht für die mehreren Minuten offen bleiben, die npm ci benötigt, also gibt bash einen Handle zurück, sobald ein Befehl seine 20-Sekunden-Wartezeit überschreitet, bash_output liest von einem Cursor, und bash_kill stoppt einen Befehl, der nicht enden will.

Befehle sind nicht interaktiv. stdin liest sofort das Dateiende, also muss ChatGPT Flags wie npm ci und gh --yes übergeben. Jeder Befehl läuft in seiner eigenen Prozessgruppe, sodass das Stoppen eines Befehls auch alles stoppt, was er gestartet hat.

Anforderungen

• Ein Linux-Server mit systemd, einer Domain und TLS

• Node.js 24

• Ein Auth0-Mandant

• Ein ChatGPT-Konto mit verfügbarem Entwicklermodus

Lokal ausführen

git clone https://github.com/salman-frs/gpt-harness.git
cd gpt-harness
npm ci
cp .env.example .env

Richte HARNESS_ROOT auf ein Verzeichnis, das du wegwerfen kannst, fülle die Auth0-Werte aus ChatGPT mit dem Gateway verbinden aus und starte es dann:

npm run dev
curl -fsS localhost:8787/healthz

/healthz benötigt kein Token. Jede Anfrage an /mcp benötigt ein gültiges Token für den konfigurierten Besitzer, einschließlich initialize.

Das lokale Ausführen des Gateways bietet keine Einschränkung. ProtectSystem=strict und der Rest stammen aus der systemd-Unit, die nur auf dem Server gilt.

Beweisen, dass es funktioniert

npm run build && npm run prove

scripts/prove.mjs startet dist/main.js als eigenen Prozess allein aus Umgebungsvariablen. Es stellt einen echten HTTPS-JWKS-Endpunkt bereit, den der Gateway über das Netzwerk abruft, prägt ein echtes RS256-Token und steuert das Ergebnis mit dem gewöhnlichen MCP-Client. Es schreibt ein Projekt, installiert eine Abhängigkeit aus der Registry, führt die Tests aus und prüft, dass das Beenden eines Befehls auch die Prozesse beendet, die dieser Befehl gestartet hat.

Nichts im Skript importiert src/.

Dokumentation

• ChatGPT mit dem Gateway verbinden behandelt Auth0, die Metadaten-Endpunkte und den Connector.

• Gateway auf einem Server bereitstellen behandelt die systemd-Unit, den Reverse-Proxy, Git-Anmeldedaten und Updates.

• Tool-Referenz behandelt Argumente, Ergebnisse, Grenzen und Fehlercodes.

• Über das Sicherheitsmodell behandelt die Grenzen und was du akzeptierst, wenn du dies ausführst.

Lizenz

MIT