Exec-Host-Refactor-Plan

Ziele

  • exec.host + exec.security hinzufuegen, um Ausfuehrung ueber Sandbox, Gateway und Node zu routen.
  • Standards sicher halten: keine Host-uebergreifende Ausfuehrung ohne explizite Aktivierung.
  • Ausfuehrung in einen headless Runner-Service mit optionaler UI (macOS-App) via lokales IPC aufteilen.
  • Per-Agent-Policy, Allowlist, Ask-Modus und Node-Binding bereitstellen.
  • Ask-Modi unterstuetzen, die mit oder ohne Allowlists funktionieren.
  • Plattformuebergreifend: Unix-Socket + Token-Auth (macOS/Linux/Windows-Paritaet).

Nicht-Ziele

  • Keine Legacy-Allowlist-Migration oder Legacy-Schema-Unterstuetzung.
  • Kein PTY/Streaming fuer Node-Exec (nur aggregierte Ausgabe).
  • Keine neue Netzwerkschicht jenseits der bestehenden Bridge + Gateway.

Entscheidungen (festgelegt)

  • Config-Keys: exec.host + exec.security (Per-Agent-Override erlaubt).
  • Elevation: /elevated als Alias fuer vollen Gateway-Zugriff behalten.
  • Ask-Standard: on-miss.
  • Approvals-Store: ~/.openclaw/exec-approvals.json (JSON, keine Legacy-Migration).
  • Runner: Headless-System-Service; UI-App hostet Unix-Socket fuer Approvals.

Schluesselkonzepte

Host

  • sandbox: Docker-Exec (aktuelles Verhalten).
  • gateway: Exec auf Gateway-Host.
  • node: Exec auf Node-Runner via Bridge (system.run).

Security-Modus

  • deny: immer blockieren.
  • allowlist: nur Treffer erlauben.
  • full: alles erlauben (entspricht elevated).

Ask-Modus

  • off: nie fragen.
  • on-miss: nur fragen wenn Allowlist nicht trifft.
  • always: jedes Mal fragen.

Implementierungsphasen

Phase 1: Config + Exec-Routing

Phase 2: Approvals-Store + Gateway-Durchsetzung

Phase 3: Node-Runner-Durchsetzung

Phase 4: Events

Phase 5: UI-Polish

Verwandte Docs

Weiter
Overview
arrow_forward