Présentation du projet

drawgent est un binaire Rust (82,4 % du dépôt) qui lance un éditeur Excalidraw, conserve la scène dans .drawgent/scene.json et interroge un agent Claude Code, Codex ou opencode via le protocole ACP. Le dépôt inclut également du JavaScript (12,5 %), du CSS et un Dockerfile, ce qui montre une architecture hybride : le cœur de l’application est compilé en Rust, tandis que l’interface web repose sur les bibliothèques Excalidraw (socket.io, AES‑GCM) et le rendu visuel utilise Chrome headless.

Architecture et flux de données

Le processus démarre avec drawgent up, qui ouvre le serveur local sur 127.0.0.1:7300 (ou le port suivant disponible). Le serveur expose deux API : une API REST pour le contrôle du canvas et une connexion WebSocket vers le client Excalidraw. Le pont ACP, installé dans ~/.cache/drawgent/adapters (~60 Mo), traduit les appels du binaire Rust vers le CLI de l’agent choisi. Un rendu visuel est produit par Chrome headless, téléchargé automatiquement (≈120 Mo) si aucune installation locale n’est détectée. Le flux complet est : capture d’écran + scène → ACP → agent → réponse → mise à jour du canvas → note DONE affichée.

drawgent up
# Lance l'éditeur, l'API et ouvre le navigateur

Mise en place et dépendances

Le prérequis principal est l’installation et l’authentification d’un des agents : claude, codex ou opencode. Les ponts Claude et Codex nécessitent Node.js ≥ 18 et npm. La commande drawgent setup <agent> vérifie la présence du CLI, crée ~/.config/drawgent/config.toml et télécharge Chrome headless si besoin, en listant les bibliothèques système manquantes (apt, snap, dnf, pacman, zypper, apk, brew ou nix). Un Makefile fournit des builds statiques musl et un Dockerfile permet de déployer uniquement le serveur sans interface graphique. Le projet propose aussi un shell Nix (flake.nix) pour reproduire l’environnement de développement.

Analyse des limites et des risques

Le serveur s’expose uniquement sur l’interface loopback, ce qui limite les vecteurs d’attaque externes, mais la dépendance à Chrome headless introduit une surface d’exposition supplémentaire : toute faille du moteur Chromium pourrait être exploitée via le rendu d’images. Les adapters ACP sont téléchargés depuis le dépôt du projet et exécutés sans vérification de signature, ce qui pose un risque d’injection de code si le cache est compromis. Le stockage de la scène dans un fichier JSON git‑ignored évite les fuites accidentelles, mais aucune chiffrement côté disque n’est appliqué. Enfin, l’absence de métriques de performance (latence de rendu, consommation CPU) empêche d’évaluer l’impact sur des environnements de CI/CD ou sur des machines à ressources limitées.