clawk

Ein Coding-Agent ist nur dann nützlich, wenn du ihn tatsächlich Dinge tun lässt: Pakete installieren, den von ihm geschriebenen Code ausführen, Server starten, das Netzwerk nutzen. Auf deinem eigenen Rechner bleiben dir dabei zwei schlechte Optionen. Du genehmigst jeden Befehl (und beaufsichtigst alle paar Sekunden eine Eingabeaufforderung), oder du führst --dangerously-skip-permissions aus und hoffst, dass nichts Wichtiges nur ein rm -rf oder ein geleakter Token entfernt ist.

clawk ist eine dritte Option. cd in ein Repo, tippe clawk, und Claude Code (oder Codex, oder pi, oder eine Shell) arbeitet in einer Wegwerf-Linux-VM (dein Code eingehängt, Root im Gast, keine Berechtigungsabfragen), während deine Dateien, dein Schlüsselbund und der Rest deines Rechners außer Reichweite bleiben. Der Agent bekommt seine eigene Maschine statt deiner.

_{Ein Befehl zu einem funktionierenden Agenten; ein Versuch, Daten an einen unbekannten Server zu senden, blockiert durch die Netzwerk-Allowlist; clawk attach setzt die Sitzung später fort.}

Die Grenze ist keine Regel in einem Prompt, aus der der Agent herausgeredet werden könnte. Es ist eine separate Maschine, und die einzigen Öffnungen sind diejenigen, die du eingehängt hast. Aus einer Shell innerhalb einer Sandbox:```console $ curl https://tracker.evil.example # not on the allow-list: blocked curl: (7) Failed to connect to tracker.evil.example port 443 after 2 ms: Connection refused

$ cat ~/.ssh/id_rsa # your keys never entered the VM cat: /home/agent/.ssh/id_rsa: No such file or directory

$ git push # ...yet this works: ssh-agent is forwarded Enumerating objects: 5, done.

Um ehrlich über die Grenzen zu sein: Die Allow-List blockiert Verbindungen zu *unbekannten*
Servern, nicht zu solchen, die du erlaubt hast: github.com ist vorab erlaubt und der
weitergereichte ssh-agent kann pushen. Behandle also alles, was der Agent lesen kann, als etwas,
das er veröffentlichen könnte. Das
[Sicherheitsmodell](#sicherheitsmodell-und-seine-grenzen) führt das im Detail aus.

Und falls der Agent die VM zerstört, führe `clawk destroy && clawk` aus: eine frische VM, dasselbe
Repo, und `--resume` stellt die Konversation wieder her.

> [!IMPORTANT]
> **Vor 1.0 und schnelle Entwicklung.** Erwarte bahnbrechende Änderungen zwischen Releases und
> gelegentlich raue Kanten; Dinge können und werden kaputtgehen. Bitte melde Issues;
> dieses Feedback formt 1.0.

## Highlights

- **Lass den Agenten alles tun.** Er läuft in einer Wegwerf-VM mit eingeschränktem
  Netzwerk, sodass `rm -rf`, Paketinstallationen und nicht vertrauenswürdiger Code deinen
  Host, deine Dateien oder alles, was du nicht explizit geteilt hast, nicht erreichen können.
- **Arbeiten mit einem Befehl.** `cd` in ein Repo und `clawk` ausführen. Keine
  Dockerfile, kein Devcontainer, keine Setup-Datei. Der erste Start baut ein Rootfs aus
  deinem Image; jeder weitere Start dauert Sekunden.
- **Kaputtmachen, ohne etwas zu verlieren.** Frei zerstören und neu erstellen; dein
  Code und die Konversationen des Agenten leben auf dem Host. Nur die Wegwerf-VM-Festplatte
  geht verloren.
- **Eine echte Linux-Box, deine Toolchain.** Jedes OCI-Image ist das Rootfs: ein vollständiges
  Betriebssystem mit genau den Tools, die dein Projekt braucht. Kein Docker-Daemon erforderlich.
- **Geheimnisse bleiben auf deiner Maschine.** Ausgehender Datenverkehr ist auf eine Allow-List
  beschränkt und dein ssh-agent wird weitergereicht, sodass `git push` funktioniert, ohne dass
  Schlüssel in die VM gelangen.
- **Eine Sandbox pro Projekt oder Ticket.** Mehrere gleichzeitig ausführen; Multi-Repo-
  Tickets erhalten ein Git-Worktree pro Repo mit koordinierten PRs. Leerlaufende VMs
  geben automatisch Speicher frei und suspendieren auf die Festplatte, sodass eine vergessene
  Sandbox (fast) nichts kostet.

## Warum eine VM?

clawk ist eine universelle lokale Umgebung für autonome Coding-Agenten.
Die VM ist der Punkt: Sie ist eine ganze Maschine, die der Agent besitzen kann, kein Prozess,
der in Richtlinien auf der Maschine eingewickelt ist, die du gerade verwendest.

- **Ein separater Kernel.** Der Gast läuft mit seinem eigenen Linux-Kernel, sodass das Host-
  Dateisystem nicht hinter Deny-Regeln versteckt ist; es wurde nie eingehängt.
- **Eine konventionelle Linux-Umgebung.** Standard-Kernel, Standard-Userland,
  `/dev/kvm`-artige Erwartungen, sodass Tools sich so verhalten, wie ihre Dokumentation es sagt,
  ohne eine Syscall-Filter-Überraschung.
- **Root im Gast.** Systempakete installieren, `/etc` bearbeiten, ein Modul laden,
  einen privilegierten Port binden. Es ist die Box des Agenten, die er neu konfigurieren kann.
- **Ein Wegwerf-Lebenszyklus.** Billig zu zerstören und schnell neu zu erstellen; eine zerstörte
  VM ist nur ein `clawk destroy && clawk` entfernt, wobei dein Repo und deine Konversationen
  auf dem Host unberührt bleiben.
- **Stärkere Trennung vom Host.** Die Isolierung beruht auf der Hypervisor-Grenze
  und nicht darauf, eine Prozess-Sandbox-Richtlinie exakt richtig hinzubekommen.

Diese Kombination führt Workloads aus, gegen die eine eingeschränkte Prozess-Sandbox oft
ankämpft:

- Installieren von Paketen und nativen Abhängigkeiten;
- Ausführen von Hintergrunddiensten (Datenbanken, Warteschlangen, Dev-Server);
- Ausführen nicht vertrauenswürdiger Builds und Tests mit voller Geschwindigkeit;
- Verwenden von Linux-System-Tools, die eine echte Maschine erwarten;
- und, mit einem KVM-fähigen Gast-Kernel auf unterstützter Hardware, Container- und
  Kubernetes-Dev-Workflows wie Docker oder Kind, die *innerhalb* der
  Sandbox laufen. Dies ist opt-in und hardwareabhängig; siehe
  [Images](https://github.com/clawkwork/clawk/blob/main/docs/images.md#guest-kernel-override) für die genauen Anforderungen.

Nichts davon ist das *Produkt*; clawk ist allgemein für lokale Agentenarbeit gedacht.
Docker und Kubernetes sind nur das schärfste Beispiel für „braucht eine echte Maschine,
keinen sandboxed Prozess."

## Installation