Utiliser LazyCodex avec Codex : mémoire de projet, planification et validation

Vous modifiez plus d’une dizaine de fichiers pour une fonctionnalité. Codex annonce que le travail est « terminé », vous lui faites confiance, puis la mise en production révèle qu’un chemin d’erreur a été oublié. Le problème est courant dans les bases de code complexes : chaque nouvelle conversation doit reconstruire le contexte du projet, et le modèle résume ce qu’il a fait sans forcément signaler les cas limites qu’il n’a pas traités.

LazyCodex rassemble dans un agent harness léger les capacités d’OmO (oh-my-openagent) adaptées à Codex. Il vise la mémoire de projet, la planification du travail et une boucle de validation fondée sur des preuves. Les sections suivantes expliquent comment $init-deep, $ulw-plan, $start-work et $ulw-loop coopèrent, comment des AGENTS.md hiérarchisés donnent des repères à un grand dépôt et quelles pratiques restent utiles sans installer l’outil.

LazyCodex : la distribution légère d’OmO pour Codex

LazyCodex joue pour Codex un rôle comparable à celui de LazyVim pour Neovim : les fonctions principales viennent de oh-my-openagent (OmO), tandis que LazyCodex distribue dans un environnement existant les composants compatibles avec le système de plugins de Codex. Le projet est publié sur GitHub sous licence MIT. En juillet 2026, la documentation officielle le présente comme l’édition Codex Light d’OmO, et non comme un portage complet d’OmO Ultimate.

Différences essentielles entre Codex seul et LazyCodex

Ce harness ne change pas les capacités fondamentales du modèle Codex. Il normalise la manière de s’en servir : établir une mémoire de projet, planifier, exécuter, puis valider à partir de preuves. L’orchestration complète des agents spécialisés et les outils team_* d’OmO Ultimate ne font cependant pas partie de Codex Light. Les tâches parallèles de LazyCodex dépendent donc de la surface subagent ou team actuellement disponible dans Codex.

Installation : une ligne npx, sans installation globale

La voie d’installation officielle de LazyCodex utilise toujours npx ; npm i -g n’est pas nécessaire :

# Installation standard
npx lazycodex-ai install

# Commande équivalente (paquet OmO et plateforme Codex explicites)
npx --yes --package oh-my-openagent omo install --platform=codex

# Mode entièrement automatique (sans interaction, permissions autonomes explicitement activées)
npx lazycodex-ai install --no-tui --codex-autonomous

# Vérification après installation
npx lazycodex-ai doctor

L’installateur écrit dans le cache des plugins de Codex et dans les configurations associées. L’installation interactive standard demande s’il faut configurer les permissions autonomes. Comme --codex-autonomous modifie cette configuration, ne l’activez qu’après avoir compris les limites de sécurité de la machine. Après une installation ou une mise à niveau, vous devez également approuver les hooks OmO lors du contrôle de démarrage de Codex, puis ouvrir une nouvelle session pour charger le plugin.

Après l’installation, retenez d’abord quatre commandes :

1. $init-deep : générer des AGENTS.md hiérarchisés
2. $ulw-plan : transformer une demande en plan complet à approuver
3. $start-work : exécuter le plan et enregistrer la progression persistante
4. $ulw-loop : poursuivre l’exécution et la validation d’une tâche unique

Pour inspecter d’abord le contenu installé, exécutez npx lazycodex-ai doctor ou consultez le README officiel de LazyCodex et la documentation officielle.

Mémoire de projet : générer des AGENTS.md hiérarchisés avec $init-deep

Le problème typique d’un grand dépôt est simple : une seule conversation ne suffit pas à expliquer tout le projet. Avec des centaines de fichiers et de nombreux modules, un agent qui ouvre une nouvelle session doit soit réexplorer l’ensemble, soit risquer une modification au mauvais endroit faute de contraintes locales.

$init-deep crée des « repères » pour le dépôt. La commande :

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

1. parcourt le dépôt et lit les fichiers qui définissent son fonctionnement réel
2. génère des AGENTS.md hiérarchisés à la racine et dans les sous-répertoires complexes
3. place les consignes locales au plus près du code concerné
4. permet aux agents suivants de lire les règles applicables avant de modifier le code

La hiérarchie compte parce qu’une consigne locale doit rester près du code qui en dépend, au lieu d’être noyée dans un unique fichier à la racine. En entrant dans un module, l’agent voit directement les règles du répertoire et n’a pas à les extraire d’une documentation globale immense.

Cette approche diffère de l’architecture de mémoire à long terme présentée dans Concevoir un système de mémoire pour un agent : AGENTS.md correspond davantage à un contexte de projet versionné qu’à des souvenirs de conversation rappelés automatiquement. Les deux modèles partagent néanmoins la hiérarchie, le contexte local et la persistance. Le rôle ressemble aussi à celui de CLAUDE.md dans Contraindre Claude avec un fichier de configuration : faire lire les règles à l’IA avant toute action.

Les AGENTS.md générés restent de simples fichiers Markdown et doivent être relus par une personne. Après une refonte du dépôt, un changement de responsabilité d’un répertoire ou une mise à jour des commandes, relancez $init-deep ou entretenez les fichiers manuellement. Un contenu généré automatiquement ne constitue pas une source de vérité permanente.

Quatre commandes pour la mémoire, le plan, l’exécution et la validation

Le flux principal de LazyCodex comprend quatre phases : initialiser la mémoire du projet, planifier, exécuter et valider. Pour une tâche de développement concrète, les trois dernières commandes forment la boucle planification–exécution–validation.

$ulw-plan : produire uniquement un plan à approuver

$ulw-plan "what to build"

Cette commande planifie sans écrire le code du produit. Elle :

1. clarifie les besoins par un échange au lieu de transformer directement une formulation vague en spécification
2. explore la base de code et délègue les recherches indépendantes à des subagents parallèles
3. analyse l’écart entre l’état actuel et l’objectif
4. écrit le plan dans plans/<slug>.md avec les références, les critères de validation, la stratégie de QA et les limites des commits
5. définit status: awaiting-approval et attend l’approbation

La contrainte centrale est l’absence de modification du produit pendant la planification. Le périmètre et les critères doivent être clairs avant de transmettre le plan à la phase d’exécution. Décomposer une tâche avec des Subagents décrit un principe proche, mais LazyCodex l’intègre directement au flux de planification.

$start-work : exécuter le plan avec un état persistant

$start-work [plan-name] [--worktree <absolute-path>]

Cette commande exécute un plan approuvé jusqu’à ce que toutes les cases de premier niveau soient terminées. Ses fonctions principales :

1. État Boulder persistant : .omo/boulder.json conserve la progression entre les tours et les sessions
2. Stop hook : si le plan n’est pas terminé, la prochaine étape de travail est réinjectée
3. Subagents parallèles : les sous-tâches indépendantes peuvent être distribuées ; le parallélisme exact dépend de la surface Codex disponible
4. TDD strict et cinq portes de preuve : relecture du plan, validation automatique, QA manuelle, QA contradictoire et nettoyage
5. Registre de progression : enregistre l’exécution et l’état des cases à cocher

À la fin, la commande affiche ORCHESTRATION COMPLETE. Ce signal indique que le flux déclare toutes les cases et portes de preuve terminées. Il reste nécessaire de consulter les tests réels, la QA manuelle et les preuves de modification, plutôt que de croire une seule ligne d’état.

$ulw-loop : valider en continu une tâche unique

$ulw-loop "task" [--completion-promise=TEXT] [--strategy=reset|continue]

Cette commande convient à une tâche unique dont le périmètre est clair, mais qui doit continuer jusqu’à ce que les preuves soient validées. Elle ne remplace pas une planification complète ; pour une tâche floue, exécutez d’abord $ulw-plan.

• Limite d’itérations : 500 au maximum en mode ultrawork, 100 en mode normal
• Stratégie : reset réinitialise le contexte de la boucle à chaque itération, continue conserve l’état courant
• Completion promise : précise les preuves à recueillir, les validations obligatoires et le traitement des informations manquantes
• Condition d’arrêt : l’oracle détermine à partir des preuves si la promesse d’achèvement est satisfaite

Le nombre d’itérations ne garantit pas la qualité. Si les critères d’achèvement restent vagues, la boucle ne fait que répéter plus vite une évaluation vague. Il faut inscrire dans la completion promise les tests, les conditions limites, la QA manuelle et le traitement des échecs.

Pourquoi la validation compte dans une base de code complexe

Dans une base de code complexe, une modification peut toucher plus d’une dizaine de fichiers. Le chemin principal fonctionne, mais un cas d’erreur, un appelant, une configuration ou une documentation n’a pas été mis à jour. Le problème ne vient pas uniquement des capacités du modèle : le critère d’achèvement manque souvent de preuves explicites.

Situations dans lesquelles un modèle oublie facilement les bords :

L’apport de LazyCodex n’est pas de garantir qu’aucun oubli ne surviendra, mais d’inscrire les contrôles dans le flux de travail. Les cinq portes de preuve imposent une relecture du plan, une validation automatique, une QA manuelle, un contrôle contradictoire et un nettoyage. $ulw-loop fait continuer une tâche jusqu’à satisfaction des preuves convenues. On passe ainsi de « le modèle affirme avoir fini » à « les preuves définies à l’avance déterminent l’achèvement ».

Ces portes ont encore besoin des sources de vérité du projet et de critères de validation de qualité. Un changement de signature exige de rechercher tous les appelants ; une suppression de fonction, tous les points d’entrée dépendants ; une modification d’interface, une interaction réelle plutôt que de simples tests unitaires. Le harness apporte une contrainte de processus, mais ne connaît pas automatiquement les risques métier.

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

Agents spécialisés d’OmO et couche de skills de LazyCodex

LazyCodex vient d’OmO, mais leurs périmètres doivent rester distincts. OmO Ultimate fournit l’orchestration complète des agents spécialisés ; Codex Light n’emporte que les composants compatibles avec le système de plugins de Codex et utilise la surface d’agents propre à Codex.

Agents spécialisés : orchestration complète réservée à OmO Ultimate

Il ne faut donc pas compter Team Mode, l’équipe complète d’agents spécialisés ni les outils team_* d’OmO Ultimate parmi les fonctions intégrées de LazyCodex Light. La possibilité de créer plusieurs membres d’équipe en parallèle dépend aussi des capacités de l’application ou de la CLI Codex utilisée.

Couche de skills : transférer les décisions spécialisées dans des flux réutilisables

LazyCodex installe un ensemble de skills et de composants. La documentation officielle actuelle cite notamment :

L’idée rejoint celle de La fonction Skill de Claude : les commandes pilotent le processus, les skills portent les décisions propres au domaine. La liste exacte peut évoluer. Après l’installation, vérifiez l’état actuel dans le menu $ de Codex ou dans la sortie de doctor.

Routage des modèles : adapter les ressources de raisonnement au risque

LazyCodex configure le routage des modèles afin d’affecter à chaque rôle ou tâche un modèle et un niveau de raisonnement adaptés. L’objectif n’est pas de garantir une économie de tokens. La documentation officielle précise au contraire que LazyCodex consacre suffisamment de modèle et de contexte à la planification, à l’exécution et à la validation.

Des principes plus sûrs :

• Utiliser un niveau de raisonnement moyen pour les tâches courantes
• Augmenter ce niveau lorsque le coût d’un échec est élevé ou qu’une relecture est nécessaire
• Réserver le niveau maximal aux tâches réellement lourdes
• Délimiter et découper les longues tâches pour qu’un thread ne sature pas sous trop de contexte

Les noms de modèles et les matrices de routage évoluent. La configuration courante au moment de l’installation fait foi. N’inscrivez pas dans un processus durable un nom de modèle lu dans un README daté, et n’assimilez pas automatiquement le routage multi-modèle à une économie de quota.

Quatre idées d’ingénierie réutilisables sans installer LazyCodex

Même sans LazyCodex, quatre principes peuvent migrer vers d’autres flux d’agents.

Idée 1 : écrire des fichiers de contexte hiérarchisés pour les grands dépôts

Les AGENTS.md générés par $init-deep constituent essentiellement un contexte de dépôt versionné et hiérarchisé. Le principe se reprend directement :

• Écrire des consignes locales pour les répertoires complexes au lieu d’empiler toutes les règles à la racine
• Faire en sorte que l’agent voie les règles applicables dès son entrée dans un répertoire
• Mettre les consignes à jour lorsque la structure ou le processus change
• Relire le contenu généré afin qu’une description obsolète ne devienne pas une nouvelle source d’erreurs

La forme minimale est un AGENTS.md à la racine et quelques AGENTS.md dans les sous-répertoires importants. Contraindre Claude avec un fichier de configuration propose une approche similaire.

Idée 2 : séparer planification et exécution

Demandez d’abord à l’agent d’écrire un plan complet du point de vue des décisions, avec périmètre, dépendances, critères de validation, QA et limites des commits, puis n’exécutez qu’après approbation. Le point essentiel n’est pas le format plans/*.md, mais l’interdiction de commencer discrètement les modifications du produit pendant la planification.

Idée 3 : lier l’achèvement à des preuves

Établissez une liste de contrôles pour les modifications multifichiers : rechercher les appelants après une modification d’interface, les points d’entrée lors d’une suppression, tester une interface par interaction réelle et vérifier le retour arrière d’une migration de données. L’état « terminé » doit dépendre de tests précis, d’une QA manuelle et de preuves sur les cas limites, pas d’un résumé.

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

Idée 4 : affecter modèle et contexte selon le risque de la tâche

Une requête simple n’exige pas le niveau de raisonnement maximal. Les changements d’architecture, migrations et portes de mise en production demandent davantage de raisonnement et de relecture. Les tâches longues doivent aussi être activement découpées : augmenter seulement le budget de tokens ne suffit pas.

Forme minimale à reproduire

Si vous ne voulez pas installer tout le harness, conservez au moins deux types de fichiers versionnés :

1. une liste de planification avec les décisions, les étapes, les critères de validation et les points ouverts
2. des AGENTS.md hiérarchisés avec les règles du dépôt et des répertoires

Ajoutez les commandes de vérification et la liste de QA manuelle correspondant à chaque catégorie de changement. Vous couvrez déjà les idées essentielles de LazyCodex les plus faciles à transférer.

À qui LazyCodex convient-il, et à qui ne convient-il pas ?

LazyCodex ajoute des hooks, des fichiers d’état, des skills et des contraintes de processus. Tous les projets n’en ont pas besoin. Le tableau suivant aide à décider.

Scénarios adaptés

Évaluer le bénéfice

Plus le dépôt est grand, la tâche longue et la validation complexe, plus les contraintes de LazyCodex peuvent être utiles. Les cas typiques sont les refactorisations multifichiers, les travaux sur plusieurs sessions et les changements risqués qui nécessitent tests automatiques et QA manuelle.

Le coût est tout aussi clair : il faut entretenir le contexte hiérarchisé, comprendre les hooks et les permissions, accepter des fichiers d’état comme .omo/boulder.json et relire les plans ainsi que les résultats de validation produits par le harness. L’installation n’élimine pas automatiquement les oublis.

Scénarios peu adaptés

• Petite modification ponctuelle : changer une fonction, un champ ou un texte
• Script simple : travail concentré dans un ou deux fichiers avec une condition d’achèvement claire
• Processus existant mature : AGENTS.md fiable, modèles de plan, CI et portes de validation humaine déjà en place
• Refus d’une configuration supplémentaire : ne pas laisser plugins, hooks, MCP ou permissions autonomes modifier l’environnement Codex actuel

En cas de doute, commencez sans installer l’ensemble : ajoutez manuellement un AGENTS.md hiérarchisé et une liste de preuves. Si le projet souffre réellement de pertes de contexte entre sessions, d’une séparation insuffisante entre plan et exécution ou de validations faibles, évaluez ensuite LazyCodex.

Conclusion

Dans une base de code complexe, la difficulté avec Codex n’est souvent pas de générer du code, mais de permettre à une nouvelle session de comprendre rapidement les règles locales et de prouver qu’une modification multifichier n’a oublié aucune limite importante. LazyCodex associe $init-deep, l’approbation des plans, l’état Boulder et les portes de preuve dans un flux Codex Light.

L’intérêt ne réside pas d’abord dans les noms Sisyphus ou Boulder, mais dans trois apports vérifiables : le contexte est écrit dans des fichiers hiérarchisés, le plan et l’exécution sont clairement séparés, et l’achèvement dépend de tests et d’une QA manuelle. Il faut parallèlement garder en tête que LazyCodex n’est pas OmO Ultimate : l’orchestration complète des agents et Team Mode ne font pas automatiquement partie de Light.

Pour continuer, exécutez npx lazycodex-ai doctor, utilisez $init-deep sur un vrai grand dépôt, puis choisissez une tâche multifichier bien délimitée et parcourez un cycle complet avec $ulw-plan, $start-work et $ulw-loop. Comparez les oublis, la relecture du contexte et le coût de validation avec une utilisation directe de Codex : c’est la seule façon de savoir si ce harness convient au projet.