Ce qui s’est passé. Clawk est un outil open source (Apache-2.0) qui lance un coding agent (Claude Code, Codex, ou un shell) à l’intérieur d’une VM Linux isolée. Ton projet est monté, l’agent a accès root dans la VM, mais ne peut pas atteindre le reste de ta machine ni appeler des serveurs externes non explicitement autorisés. Une commande (clawk) démarre la session, clawk destroy supprime tout, et une session cassée se restaure en secondes. Il a récolté 175 stars et 119 points sur Hacker News en quelques heures.

Pourquoi ça te concerne. Les agents de coding sont utiles quand tu les laisses vraiment faire : installer des paquets, exécuter des scripts, démarrer des serveurs. Mais sur ton laptop, tu as deux mauvaises options : approuver chaque commande (et passer du temps à dire oui), ou sauter les contrôles et espérer qu’un rm -rf ou un token volé ne frappent pas quelque chose qui compte. Clawk te donne une troisième option : l’agent travaille dans un environnement séparé où il peut faire ce qu’il veut, tandis que tes fichiers, tes clés SSH et le reste de ta machine restent hors de portée. Le réseau est filtré en amont : une connexion vers un domaine non autorisé est bloquée par le firewall de la VM, pas par une règle dans le prompt. Comme nous l’avons raconté le 12 juillet, le modèle de sécurité est le même que celui de Clodex : traiter la sortie de l’agent comme une entrée non fiable et vérifier localement.

Si tu veux l’essayer. Le README sur GitHub (clawkwork/clawk) montre l’installation et l’utilisation de base. Attention : le projet est déclaré pre-1.0 avec possibles breaking changes entre les versions.

En détail

Le contexte

Les agents de coding (comme pour la réécriture de sqlite-utils, ou la récupération des applets Java de 1999 par Terry Tao) ne fonctionnent que s’ils peuvent vraiment exécuter : lire des fichiers, les modifier, installer des dépendances, tester le code qu’ils ont écrit. Le problème est que tout ce comportement se produit sur ton laptop, avec accès à tes fichiers, tes clés, ton réseau.

Les alternatives existantes sont deux :

• Tu approuves chaque commande. L’agent demande la permission à chaque étape, et tu finiras par répondre à un prompt toutes les quelques secondes. Utile pour des vérifications ponctuelles, insoutenable pour les longues sessions.
• Tu sautes les approbations (--dangerously-skip-permissions dans beaucoup d’outils). L’agent exécute tout seul, mais une erreur ou une demande ambiguë peut supprimer des fichiers importants ou exposer des données sensibles.

Clawk part de l’observation que l’agent n’a pas besoin d’accéder à ton système : il a juste besoin du projet sur lequel il travaille.

Comment ça fonctionne

Quand tu lances clawk dans un dossier, l’outil :

1. Crée une VM Linux isolée (via des technologies de containerisation ou virtualisation, les détails techniques sont dans le repo).
2. Monte le dossier du projet dans la VM.
3. Lance l’agent (Claude Code, OpenCode, ou un shell) dans la VM.
4. Configure un firewall au niveau du réseau qui bloque toutes les connexions sortantes sauf celles vers les domaines explicitement autorisés (GitHub est pré-autorisé, le reste doit être ajouté si besoin).
5. Transfère le ssh-agent de ton système, pour que l’agent puisse faire git push sans que tes clés privées entrent dans la VM.

L’agent peut faire n’importe quoi dans la VM : installer des paquets, modifier des fichiers, supprimer et reconstruire. S’il essaie de se connecter à un serveur non autorisé (exemple : curl https://tracker.evil.example), la connexion échoue au niveau du réseau. Si la session tourne mal, clawk destroy && clawk redémarre de zéro.

Les limites

Le modèle de sécurité est clair : Clawk bloque les connexions vers les serveurs inconnus, pas vers ceux que tu as autorisés. Cela signifie :

• Si tu autorises GitHub, l’agent peut lire les fichiers du projet et faire git push : tout ce que l’agent lit peut être publié.
• Le filtre réseau arrête les connexions directes, mais si l’agent exfiltre les données via un canal autorisé (par exemple en les cachant dans un commit), Clawk ne l’intercepte pas.
• La VM isole le système de fichiers et les identifiants locaux, pas la logique de l’agent : si le prompt contient des instructions malveillantes (injection indirecte), l’agent les exécute.

En d’autres termes : Clawk te protège des erreurs destructrices (l’rm -rf qui supprime tout le disque) et des tentatives d’exfiltration non autorisées, mais ne te protège pas de toi-même si tu donnes à l’agent accès à des ressources sensibles ou si le projet lui-même contient des secrets.

Disponibilité et communauté

Le projet est sur GitHub (clawkwork/clawk), licence Apache-2.0, avec documentation sur l’architecture et le modèle de sécurité. Il est déclaré pre-1.0 : attends-toi à des breaking changes et des rough edges. La discussion sur Hacker News (112 commentaires) couvre les cas d’usage, les comparaisons avec Docker et devcontainer, et les détails d’implémentation.

Implications pratiques

Clawk représente un changement d’approche : au lieu de demander à l’agent de bien se comporter (via des règles dans le prompt), tu construis un environnement où l’agent ne peut pas faire de dégâts même s’il se trompe. C’est le même principe derrière Clodex : traiter la sortie du modèle comme une entrée non fiable et vérifier localement.

Cette approche n’est pas universelle : si ton travail quotidien nécessite que l’agent accède à des services internes ou des bases de données d’entreprise, Clawk ne les remplace pas. Mais pour le développement local sur des projets open source ou des projets internes auto-contenus, il offre un équilibre pratique entre liberté opérationnelle et sécurité.