Cindy est un client open source qui veut transformer Claude Code, Codex et d’autres outils en agent local capable d’agir sur vos projets. Mon verdict court : c’est prometteur, déjà intéressant pour bidouiller des agents de dev, mais pas encore le produit grand public sans friction que son slogan laisse imaginer.
Cindy, c’est quoi ?
Cindy se présente comme un agent IA open source qui tourne sur votre machine, avec une application desktop Electron, une app mobile Expo et des packages partagés. Le dépôt GitHub testé est le client, pas le backend cloud officiel.
L’idée est simple : au lieu d’avoir un outil séparé pour Claude Code, un autre pour Codex, puis des scripts autour, Cindy veut unifier l’expérience. On y retrouve des notions utiles : mémoire, skills, automatisations, MCP, orchestration multi-agent, navigateur, fichiers locaux et intégrations de messagerie.
Dans la pratique, le dépôt est un gros monorepo pnpm. Il installe aussi des binaires de runtime, notamment Claude Code, Codex, ripgrep et pi. C’est important, car Cindy ne réinvente pas tout. Elle assemble des briques d’agents existantes dans une interface et un runtime local.
| Point testé | Résultat |
|---|---|
| Dépôt | makecindy/cindy, commit 6238a82c |
| Stack | Node 22, pnpm 10, Electron, React, Expo |
| Produit lancé | Client desktop dev et runtime Codex embarqué |
| LLM | Proxy OpenAI compatible local, modèle gpt-5.5 pour le test réussi |
| Licence | Apache 2.0 |
Installation de Cindy
La documentation demande Node 22, pnpm 10 et Git LFS. J’ai cloné le dépôt, initialisé le sous-module public cindy-protocol, puis lancé l’installation.
git clone https://github.com/makecindy/cindy.git /tmp/cindy
cd /tmp/cindy
git submodule update --init --recursive cindy-protocol
git lfs pull
pnpm install
Premier point honnête : ce n’est pas une petite installation. Le monorepo pèse lourd, et les binaires téléchargés pendant le postinstall sont costauds. Dans mon conteneur, /tmp était limité à 512 Mo. J’ai donc gardé le clone dans /tmp, comme prévu, puis copié le checkout dans un espace temporaire plus grand pour installer et exécuter le produit.
Deuxième point : j’ai rencontré un bug d’installation sur le runtime pi. Le script essayait d’extraire une archive .tar.gz avec une invocation de tar qui ne passait pas l’option gzip dans cet environnement. J’ai corrigé la copie de travail temporaire pour finir l’installation. Ensuite, Cindy a bien téléchargé et vérifié les runtimes Claude Code, Codex, ripgrep et pi.
Cindy à l’usage
J’ai testé deux chemins, car Cindy est à la fois une app desktop et un emballage autour de runtimes d’agents.
D’abord, j’ai lancé l’app desktop Electron en mode développement, avec sandbox de données isolée. Comme demandé, j’ai exporté les variables du proxy LLM avant lancement :
export OPENAI_BASE_URL=http://172.17.0.1:8790/v1
export OPENAI_API_KEY=sk-proxy
export OPENAI_API_BASE=http://172.17.0.1:8790/v1
export OPENROUTER_BASE_URL=http://172.17.0.1:8790/v1
export OPENROUTER_API_KEY=sk-proxy
Le build Vite et Electron démarre réellement. J’ai vu les bundles main, preload et workers se compiler, l’UI Electron se lancer, TapDB rester désactivé en dev, puis le renderer charger. En Docker root, il faut contourner la sandbox Electron avec --no-sandbox, ce qui n’est pas une posture de prod, mais c’est classique dans ce type de conteneur de test.
Le résultat côté desktop est mitigé : l’UI démarre, mais le renderer a fini par tomber sur une erreur de module dynamique Vite après quelques minutes. Je ne vendrais donc pas le chemin source desktop comme fluide pour un utilisateur lambda sous Linux conteneurisé.
Ensuite, j’ai testé le cas d’usage concret qui m’intéressait vraiment : est-ce que le runtime agent livré avec Cindy peut modifier un petit projet et valider le résultat ?
J’ai créé un mini service JavaScript volontairement vulnérable : une fonction isAllowed(ip) qui ne bloque que 127.*, alors que le test exige de refuser aussi les plages privées 10/8, 172.16/12 et 192.168/16. Puis j’ai lancé le Codex embarqué par Cindy avec le proxy OpenAI compatible.
apps/codex-bin/linux-x64/codex exec \
--dangerously-bypass-approvals-and-sandbox \
--skip-git-repo-check \
--cd /tmp/cindy-usecase \
-m gpt-5.5 \
"Use shell commands to inspect and edit files. Fix service.js so private IPv4 ranges 10/8, 172.16/12 and 192.168/16 are denied, then run node service.test.js."
Le premier essai en sandbox normale a échoué à cause de bubblewrap et des namespaces non privilégiés du conteneur. C’est une limite d’environnement, mais elle compte pour un freelance DevOps : un agent qui dépend d’une sandbox système doit échouer proprement, ou proposer une stratégie claire.
En mode bypass, isolé dans mon conteneur, Codex a fait le travail. Il a lu service.js, lu service.test.js, modifié le fichier, puis exécuté node service.test.js. Le test final a répondu :
tests ok
Le fichier final produit par l’agent était simple et correct :
function isAllowed(ip) {
const parts = ip.split('.').map(Number);
const [a, b] = parts;
return !(
a === 10 ||
(a === 172 && b >= 16 && b <= 31) ||
(a === 192 && b === 168)
);
}
module.exports = { isAllowed };
Ce que j’aime dans Cindy
Ce que j’aime le plus, c’est l’ambition pragmatique. Cindy ne promet pas seulement un chat de plus. Le projet essaie de connecter des agents déjà connus à des fichiers locaux, des sessions, des outils, des crons et des workflows.
J’aime aussi le fait que le dépôt soit auditable. Pour un profil sécu et DevOps, c’est essentiel. Les clés fournisseurs sont pensées comme des secrets locaux, les binaires sont téléchargés avec vérification SHA, et la télémétrie TapDB est désactivée en dev.
Enfin, le runtime Codex livré dans le dépôt a vraiment produit quelque chose dans mon test. Pas une réponse marketing, pas un simple démarrage. Il a modifié un fichier et a fait passer un test.
Les limites de Cindy
La limite principale, c’est la complexité. Installer Cindy depuis la source demande un environnement précis, beaucoup de dépendances, des binaires lourds et un peu de patience.
La deuxième limite, c’est la séparation entre le client open source et le service complet. Le dépôt public ne contient pas le backend. Pour certaines fonctions, il faut un compte Cindy cloud ou accepter de rester dans un mode local plus limité.
La troisième limite est opérationnelle : la sandbox Codex n’a pas fonctionné dans mon conteneur sans bypass, à cause des namespaces. En prod, je veux une sandbox. En test Docker, j’ai accepté le contournement parce que l’environnement était déjà isolé. Ce n’est pas une recommandation générale.
Faut-il adopter Cindy ?
Mon verdict : à essayer si vous construisez ou évaluez des workflows d’agents de dev. À adopter seulement si vous êtes prêt à investir du temps dans l’environnement, les providers et les limites de sandbox.
Pour un freelance sécu ou DevOps, Cindy est intéressant comme laboratoire d’orchestration locale. Pour un utilisateur non technique qui veut juste cliquer et déléguer, je conseillerais plutôt d’attendre une version distribuée stable ou d’utiliser le service officiel.
Est-ce que ça marche vraiment ? Oui, sur le runtime Codex, j’ai obtenu une modification vérifiée par test. Non, pas encore comme expérience source totalement lisse côté desktop dans mon environnement.
FAQ
Cindy est-il gratuit ?
Le client open source est sous licence Apache 2.0. Certaines fonctions peuvent dépendre du service Cindy officiel, de vos abonnements Claude Code ou Codex, ou de vos propres clés API.
Peut-on utiliser Cindy sans compte cloud ?
Le README indique un mode Skip Sign-In pour des agents locaux, avec des fonctions serveur indisponibles. Dans mon test, j’ai surtout validé le lancement desktop dev et le runtime Codex local.
Cindy est-il prêt pour la production ?
Pas depuis le code source, selon mon test. Le projet est solide et ambitieux, mais l’installation, la sandbox et le desktop dev demandent encore un profil technique.