clawk

Un agent de codage n'est utile que si vous le laissez réellement faire des choses : installer des paquets, exécuter le code qu'il écrit, démarrer des serveurs, utiliser le réseau. Sur votre propre machine, cela laisse deux mauvaises options. Vous approuvez chaque commande (et surveillez une invite toutes les quelques secondes), ou vous lancez --dangerously-skip-permissions et espérez que rien d'important ne se trouve à un rm -rf ou à un jeton divulgué près.

clawk est une troisième option. cd dans un dépôt, tapez clawk, et Claude Code (ou Codex, ou pi, ou un shell) travaille à l'intérieur d'une VM Linux jetable (votre code monté dedans, root dans l'invité, aucune invite de permission) pendant que vos fichiers, votre trousseau, et le reste de votre machine restent hors de portée. L'agent obtient sa propre machine au lieu de la vôtre.

_{Une commande pour un agent opérationnel ; une tentative d'envoyer des données à un serveur inconnu, bloquée par la liste d'autorisation réseau ; clawk attach reprend la session plus tard.}

La frontière n'est pas une règle dans une invite dont on pourrait convaincre l'agent de sortir. C'est une machine séparée, et les seules ouvertures sont celles que vous avez montées. Depuis un shell à l'intérieur d'un 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.

Pour être honnête sur les limites, la liste d'autorisation bloque les connexions vers des serveurs *inconnus*, pas vers ceux que vous avez autorisés : github.com est pré-autorisé et l'agent ssh transféré peut pousser, donc considérez tout ce que l'agent peut lire comme quelque chose qu'il pourrait publier. Le [modèle de sécurité](#security-model-and-its-limits) détaille cela.

Et si l'agent casse la VM, lancez `clawk destroy && clawk` : une nouvelle VM, le même dépôt, et `--resume` restaure la conversation.

> [!IMPORTANT]
> **Avant la 1.0 et en évolution rapide.** Attendez-vous à des changements cassants entre les versions et à quelques aspérités occasionnelles ; les choses peuvent et vont casser. Veuillez signaler les problèmes ; ces retours façonnent la 1.0.

## Points forts

- **Laissez l'agent faire n'importe quoi.** Il s'exécute dans une VM jetable avec un réseau restreint, donc `rm -rf`, les installations de paquets et le code non fiable ne peuvent pas atteindre votre hôte, vos fichiers ou quoi que ce soit que vous n'avez pas explicitement partagé.
- **Travail en une seule commande.** `cd` dans un dépôt et lancez `clawk`. Pas de Dockerfile, devcontainer ou fichier de configuration. Le premier démarrage construit un rootfs à partir de votre image ; chaque démarrage suivant ne prend que quelques secondes.
- **Cassez-le sans rien perdre.** Détruisez et recréez librement ; votre code et les conversations de l'agent vivent sur l'hôte. Seul le disque de la VM jetable est perdu.
- **Une vraie machine Linux, votre chaîne d'outils.** Toute image OCI est le rootfs : un système d'exploitation complet avec exactement les outils dont votre projet a besoin. Aucun démon Docker requis.
- **Les secrets restent sur votre machine.** Le trafic sortant est sur liste d'autorisation et votre agent ssh est transféré, donc `git push` fonctionne sans que les clés entrent dans la VM.
- **Un bac à sable par projet ou ticket.** Lancez-en plusieurs à la fois ; les tickets multi-dépôts obtiennent un worktree git par dépôt avec des PR coordonnées. Les VM inactives libèrent automatiquement la mémoire et se suspendent sur disque, donc un bac à sable oublié ne coûte (presque) rien.

## Pourquoi une VM ?

clawk est un environnement local polyvalent pour les agents de codage autonomes. La VM est le point central : c'est une machine entière que l'agent peut posséder, pas un processus enveloppé dans une politique sur celle que vous utilisez.

- **Un noyau séparé.** L'invité exécute son propre noyau Linux, donc le système de fichiers de l'hôte n'est pas caché derrière des règles de refus ; il n'a jamais été monté.
- **Un environnement Linux conventionnel.** Noyau standard, userland standard, attentes en forme de `/dev/kvm`, donc les outils se comportent comme le disent leurs docs, sans surprise de filtre d'appels système.
- **Root dans l'invité.** Installez des paquets système, modifiez `/etc`, chargez un module, liez un port privilégié. C'est la machine de l'agent à reconfigurer.
- **Un cycle de vie jetable.** Peu coûteux à casser et rapide à recréer ; une VM détruite est à un `clawk destroy && clawk` près, avec votre dépôt et vos conversations intacts sur l'hôte.
- **Une séparation plus forte de l'hôte.** L'isolation repose sur la frontière de l'hyperviseur plutôt que sur l'obtention d'une politique de bac à sable de processus parfaitement réglée.

Cette combinaison exécute des charges de travail qu'un bac à sable de processus restreint a tendance à vous compliquer :

- installer des paquets et des dépendances natives ;
- exécuter des services en arrière-plan (bases de données, files d'attente, serveurs de développement) ;
- exécuter des builds et des tests non fiables à pleine vitesse ;
- utiliser des outils Linux au niveau système qui attendent une vraie machine ;
- et, avec un noyau invité compatible KVM sur du matériel pris en charge, des flux de travail de développement conteneur et Kubernetes tels que Docker ou Kind s'exécutant *à l'intérieur* du bac à sable. C'est optionnel et limité par le matériel ; voir [Images](https://github.com/clawkwork/clawk/blob/main/docs/images.md#guest-kernel-override) pour les exigences exactes.

Rien de tout cela n'est le *produit* ; clawk est destiné au travail d'agent local en général. Docker et Kubernetes ne sont que l'exemple le plus frappant de « a besoin d'une vraie machine, pas d'un processus en bac à sable ».

## Installation