Remote Coding Runtime

Eine modellneutrale, clientneutrale Remote-Coding-Runtime mit einer stabilen Cloudflare-Control-Plane und ausschließlich ausgehenden lokalen Runnern.

ChatGPT / Claude / Cursor / any MCP client
          │ HTTPS stateless MCP
          ▼
Cloudflare Worker
  Admin UI · RegistryDO · RunnerDO
          │ authenticated outbound WebSocket RPC
          ▼
Local Runner
  filesystem · transactional patch · Git · process · persistent jobs

Cloudflare führt keinen Code aus und ruft kein KI-Modell auf. Der MCP-Client übernimmt das Denken; der Runner übernimmt Dateisystem-, Git- und Prozessarbeit. Das Schließen des Browsers, des Chats, der MCP-Anfrage oder des Runner-WebSockets stoppt keinen bereits gestarteten Job.

Architektur

• Worker: der einzige öffentliche MCP-/Control-Plane-Endpunkt. Er authentifiziert MCP-Client-URLs, bedient die kleine Admin-UI und leitet begrenzte RPC-Nachrichten weiter.

• RegistryDO: SQLite-Metadaten für Runner, Workspaces, historische Jobs, Administrator-Passwort-/Sitzungszustand und MCP-Client-Anmeldeinformationen.

• RunnerDO: ein hibernierbares Durable Object pro Runner. Es besitzt den aktuellen ausgehenden Runner-WebSocket und die korrelierte RPC-Brücke; es führt niemals Codierungsarbeit aus.

• Runner: ein ausschließlich ausgehender Node-Prozess mit vertrauenswürdigen Workspace-Zuordnungen, Pfadbeschränkung, Patch-/Git-Diensten, lokalen Unterprozessen und persistenten Logs/Job-Metadaten.

• Protokoll: packages/protocol bietet strenge TypeScript-Schemas und ein generiertes sprachneutrales JSON-Schema für zukünftige Go/Rust-Runner.

Der Cloudflare-Kern verwendet nur Workers plus SQLite-gestützte Durable Objects. Er verwendet kein OAuth, KV, D1, Queues, R2, Sandbox, Container, Dynamic Workers, Tunnel, eingehendes SSH, GitHub-Actions-Runtime oder KI-Modell-APIs.

Related MCP server: cloud-to-local

Bereitstellung

Anforderungen: Node.js 20+, npm, Git, Wrangler und ein Cloudflare-Konto mit aktivierten SQLite-gestützten Durable Objects.

git clone https://github.com/aloneio/remote-coding-runtime.git
cd remote-coding-runtime
npm install
npm test
npm run typecheck
npm run build
npm run validate:worker

Konfigurieren Sie die drei Produktionsgeheimnisse, die für die Runner-Verwaltung und den internen Steuerkanal verwendet werden:

cd apps/worker
npx wrangler secret put ADMIN_TOKEN
npx wrangler secret put RUNNER_TOKEN_PEPPER
npx wrangler secret put INTERNAL_CONTROL_SECRET

Stellen Sie dann nur bereit, wenn Sie bereit sind:

npx wrangler deploy --config wrangler.jsonc

npm run validate:worker führt Wrangler mit --dry-run aus. Überprüfen Sie, ob die Ausgabe --dry-run: exiting now enthält; es beweist nicht die Kontingente eines bereitgestellten Kontos oder das Produktionsnetzwerkverhalten.

Ersteinrichtung

Öffnen Sie die bereitgestellte Root-URL, zum Beispiel:

https://mcp.aloneio.com/

Ein frisches RegistryDO zeigt:

Welcome to Remote Coding Runtime
Create administrator password

Die erste gültige Einrichtungsanfrage gewinnt atomar. Kein Bootstrap-Passwort ist erforderlich. Setzen Sie das Passwort unmittelbar nach der Bereitstellung. Wenn eine nicht initialisierte öffentliche Instanz von jemand anderem beansprucht wird, löschen/setzen Sie ihren Cloudflare-Zustand zurück und stellen Sie sie erneut bereit.

Passwörter werden nicht im Klartext gespeichert. Die Registry speichert einen versionierten PBKDF2-HMAC-SHA-256-Verifizierer mit einem zufälligen Salt. Der Login erstellt eine zufällige siebentägige undurchsichtige Sitzung; der Browser erhält ein Secure, HttpOnly, SameSite=Strict, Path=/-Cookie, während RegistryDO nur dessen SHA-256-Hash speichert. Passwortänderungen widerrufen jede bestehende Sitzung.

Admin-Zustandsänderungsanfragen verwenden ein sitzungsgebundenes CSRF-Token und Same-Origin-Prüfungen. Einrichtung und Login verwenden ebenfalls kurzlebige Pre-Auth-CSRF-Cookies.

Runner hinzufügen

Die Runner-Authentifizierung bleibt unabhängig vom Admin-Login und den MCP-Client-Anmeldeinformationen. Registrieren oder rotieren Sie einen Runner über die ADMIN_TOKEN-geschützte API:

curl -sS -X POST https://mcp.aloneio.com/admin/runners \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"runner_id":"home-pc"}'

Das Klartext-Runner-Token wird nur bei erfolgreicher Registrierung/Rotation zurückgegeben. Speichern Sie es sicher und starten Sie dann den Runner:

CODING_RUNNER_TOKEN='returned-runner-token' \
  npx tsx apps/runner/src/cli.ts start \
  --server wss://mcp.aloneio.com \
  --runner-id home-pc \
  --workspace zero=/home/me/code/zero\;writable\;noshell

Workspace-Syntax:

--workspace id=path[;readonly|writable][;shell|noshell]

Standardwerte sind readonly;noshell. Produktion erfordert wss://; Klartext ws:// wird nur für Loopback zusammen mit --insecure-local akzeptiert.

Der Runner benötigt nur ausgehenden Internetzugang. Er setzt kein HTTP, MCP, OAuth, SSH oder eingehende Ports frei.

MCP-Clients erstellen

Melden Sie sich unter / an und verwenden Sie dann das /admin-Dashboard:

1. Geben Sie einen Namen wie ChatGPT Web, Claude oder Cursor Desktop ein.

2. Wählen Sie Read, Write und/oder Execute-Berechtigungen.

3. Drücken Sie Erstellen.

4. Kopieren Sie die generierte URL sofort. Sie wird nur einmal angezeigt.

Beispiel:

https://mcp.aloneio.com/fJ3...43-character-base64url-secret...x92/mcp

Konfigurieren Sie nur diese URL im MCP-Client. Kein OAuth-Flow, Callback oder zusätzlicher Bearer-Header ist erforderlich. Jeder Client muss seine eigene URL haben:

ChatGPT → secret A
Claude  → secret B
Cursor  → secret C

Das Dashboard unterstützt:

• Erstellen

• Umbenennen

• Rotieren

• Widerrufen

• Pro-Client-coding:read, coding:write, coding:exec-Berechtigungen

• Anzeige von Erstellt/Zuletzt verwendet/Status/Key-Präfix

Rotation macht die alte URL sofort ungültig und zeigt den Ersatz einmal an. Widerruf lässt die URL denselben 404 Not Found zurückgeben, der für unbekannte Geheimnisse verwendet wird.

Sicherheitsmodell für geheime URLs

/<secret>/mcp ist eine API-Anmeldeinformation. Behandeln Sie die vollständige URL wie ein Passwort:

• Veröffentlichen Sie sie nicht;

• Nehmen Sie sie nicht in Screenshots auf;

• Committen Sie sie nicht in Git;

• Fügen Sie sie nicht in Logs, Issues oder Analysen ein;

• Erstellen Sie für jeden MCP-Client/jedes Gerät eine eigene URL;

• Rotieren Sie sofort, wenn ein Leck vermutet wird.

Die Anwendung protokolliert niemals die eingehende URL/den Pfad und speichert nur einen SHA-256-Verifizierer plus ein kurzes Anzeigepräfix. MCP-/Admin-Antworten verwenden Cache-Control: no-store; HTML verwendet außerdem Referrer-Policy: no-referrer, eine restriktive CSP, nosniff und Frame-Blockierung. Infrastruktur außerhalb der Anwendung kann dennoch Anforderungspfade aufzeichnen. Konfigurieren Sie daher die Cloudflare-Log-Schwärzung und verlassen Sie sich für die Wiederherstellung auf Rotation/Widerruf.

Tool-Katalog

Laufzeit

runner_list
runner_info
workspace_list
env_info

Dateisystem

fs_read
fs_list
fs_search
fs_apply_patch

Ausführung und persistente Jobs

exec_start
exec_run
job_list
job_get
job_logs
job_cancel
job_input

Git

git_status
git_diff

coding:read erlaubt Laufzeit-/Dateisystem-Lesezugriffe, job_list/job_get/Logs und Git-Inspektion. coding:write erlaubt Patchen. coding:exec erlaubt Prozessstart/-lauf/-abbruch/-eingabe. Ein Job wird innerhalb der Einzel-Admin-Instanz geteilt und nicht von einem einzelnen MCP-Client besessen: Claude kann einen früher von ChatGPT erstellten Job entdecken und lesen, wenn es die erforderliche Berechtigung hat.

Persistente Jobs

exec_start gibt schnell eine job_id zurück. Der Runner persistiert lokalen autoritativen Zustand unter:

~/.remote-coding-runner/state/
├── runner.json
└── jobs/<job_id>/
    ├── meta.json
    ├── stdout.log
    └── stderr.log

Der Worker speichert nur begrenzte Metadaten. job_list liest RegistryDO-Snapshots und funktioniert daher, während ein Runner offline ist. Vollständiges stdout/stderr bleibt auf dem Runner und wird über paginierte job_logs gelesen, sobald der Runner online ist.

Runner-Sync upsert aktuelle/aktuelle Jobs, ohne ältere Verläufe zu löschen, nur weil sie aus einem begrenzten Snapshot ausgelassen wurden. Die Registry behält aktive/nicht-terminale Jobs und bis zu 1.000 terminale Jobs pro Runner. Ein Job kann created_by_client_id für die Prüfung aufzeichnen, aber dieses Feld beschränkt den clientübergreifenden Zugriff nicht.

Nach einem Runner-Neustart wird ein Prozess, der weiterhin seiner gespeicherten PID/Fingerabdruck entspricht, zu unknown. Lazy Reconciliation während job_get, job_list und Sync hält ihn unknown, solange er lebt, und ändert ihn nach dem Verschwinden zu interrupted, da das tatsächliche Exit-Ergebnis nicht verfügbar ist. Ein wiederhergestellter Abbruch wird nur dann zu cancelled, wenn dauerhafte Beweise zeigen, dass dieser Runner die Beendigungsanfrage zugestellt hat; es wird kein Exit-Code erfunden.

On-Disk-Logdateien bleiben standardmäßig vollständig und unbegrenzt. Überwachen Sie die Runner-Festplattennutzung.

Dateisystem- und Patch-Sicherheit

MCP-Anfragen liefern nur runner_id, workspace_id und workspace-relative Pfade. Der Runner lehnt ab:

• POSIX-Absolutpfade;

• Windows-Laufwerks-, UNC- und Gerätepfade;

• NUL-Bytes und ..-Traversierung;

• unbekannte Workspace-IDs;

• Symlink/Junction-Vorfahren und -Ausbrüche;

• Write-through-Symlinks;

• Schreibvorgänge auf schreibgeschützte Workspaces.

fs_read und job_logs verwenden UTF-8-sichere Byte-Cursor. Winzige Seiten mit chinesischen Zeichen, Emojis und akzentuierten Zeichen können exakt ohne Ersatzzeichen verkettet werden.

fs_apply_patch unterstützt Add/Update/Delete/Move-Operationen, erwartete SHA-256-Baselines, exaktes Hunk-Matching, Staging/Backups im selben Verzeichnis, Rollback, BOM/Newline/Mode-Erhaltung und begrenzte strukturierte Ergebnisse. Stabile sichere Fehler wie invalid_patch, missing_file, target_exists, baseline_changed, Hunk-Fehler, patch_install_failed und patch_rollback_failed erreichen MCP, ohne Host-Absolutpfade offenzulegen.

Dies ist eine Workspace-/Pfad-Autorisierungsgrenze, keine feindliche Betriebssystem-Sandbox. Führen Sie nicht vertrauenswürdige Repositories oder Befehle in einer externen VM/Container mit eingeschränkten Mounts, Geheimnissen und Netzwerkzugriff aus.

Timeouts und Umgebungserkennung

Gemeinsame Protokollkonstanten halten die Fristen ausgerichtet:

normal Runner operation maximum: 8,000 ms
Worker → Runner bridge timeout: 12,000 ms

Dies lässt eine vier Sekunden Transport-/Antwortmarge. exec_run und Git verwenden das gemeinsame lokale Limit; längere Arbeiten müssen exec_start verwenden.

env_info cacht begrenzte parallele Sonden für Plattform, Architektur, Hostname, Shell, Node, npm, pnpm, Python, Git, Go, rustc, Cargo und Docker. Fehlende oder abgelaufene Tools geben { "available": false } zurück, anstatt die Anfrage fehlschlagen zu lassen.

Tests

npm test
npm run typecheck
npm run build
npm run validate:worker

Die Suite umfasst Protokolltests, Runner-Dateisystem-/Prozess-/Patch-/Git-/Wiederherstellungstests, Worker-Durable-Object- und Admin-/Client-Auth-Tests sowie ein echtes lokales Wrangler + echtes Runner-E2E. Die Abdeckung umfasst:

• atomare Einmal-Einrichtung;

• PBKDF2-Passwort-/Sitzungsverhalten, Ablauf, Abmeldung, Passwort-Invalidierung und CSRF;

• pro Client geheime URL erstellen/rotieren/widerrufen/404/Berechtigungsdurchsetzung;

• echte MCP → Worker → Runner fs_read;

• UTF-8-Datei-/Log-Paginierung;

• persistente Ausführung nach dem Schließen einer MCP-Anfrage;

• Runner-Transporttrennung, lokale Fortsetzung, Wiederverbindung und Synchronisierung;

• Client A startet einen Job und Client B entdeckt ihn mit job_list während offline;

• Traversierungs-, Symlink-, Readonly-, Patch-, Git-, Timeout-, Ausgabe- und Nebenläufigkeitsgrenzen.

Lokale Tests beweisen nicht die Kontingente eines bestimmten Cloudflare-Kontos, die Produktions-Edge-Log-Schwärzung, die Internet-Client-Kompatibilität oder ein bereitgestelltes Neustart-/Hibernation-Ereignis. Die Bereitstellung bleibt ein vom Betreiber durchgeführter Abnahmeschritt.

Bewusst ausgeschlossener Umfang

Das MVP enthält keine MCP-Tasks, PTY/Web-Terminal, Mehrbenutzerkonten, Organisationen, Teams, Abrechnung, KI-Agenten, RAG, Browser-Automatisierung, GitHub-Actions-Runtime, Cloudflare-Sandbox oder Cloudflare-Container.

Danksagungen und Lizenz

Dies ist eine unabhängige Apache-2.0-Implementierung. Die Designforschung berücksichtigte:

• xyTom/coding-tools-mcp, Apache-2.0 + NOTICE;

• volter-ai/volter-tunnel, Apache-2.0 + NOTICE;

• Hiroshimeow/agent-mcp-gateway, MIT;

• Cloudflare Workers, Durable Objects, WebSocket Hibernation, Agents MCP handler und MCP TypeScript SDK-Dokumentation.

Das angeforderte Repository davidlosasgonzalez/codeagent-mcp war während der Forschung unter der öffentlichen URL nicht verfügbar, daher wurde kein Code oder keine Lizenz daraus verwendet.