Travaux d'images Codex
Exécutez chaque projet ou lot d'images via l'exécuteur. N'appelez pas codex exec ou codex-imagegen manuellement pour ces travaux.
python scripts/codex_image.py "<prompt ou @prompt.txt>" out.png [--ref room.jpg] [--size 1536x1024] [--force]
Il imprime le chemin de sortie absolu. Donnez à l'appel Bash un délai d'attente supérieur au --timeout de l'exécuteur (par défaut 420 s).
| Sortie | Signification | Action |
|---|---|---|
| 0 | Enregistrée | Voir l'image |
| 1 | Utilisation, par exemple la sortie existe | Corriger l'appel ; --force remplace une sortie, jamais sa propre référence |
| 2 | Codex s'est terminé sans image | Lire la sortie imprimée, corriger la cause, puis réessayer une fois |
| 3 | L'appel image a omis la référence, donc rien n'a été enregistré | Réessayer une fois avec la même commande |
| 124 | Aucune session ou aucune image dans le délai | Vérifier codex login status et le réseau |
Règles
- Voir chaque sortie par rapport à sa consigne. Le code de sortie 0 prouve qu'une image provient de cette session, mais pas qu'elle est correcte.
- Enchaîner les modifications une par une : chaque sortie devient la prochaine
--ref. Écrire dans un nouveau fichier à chaque étape. - Conserver la pièce : dire ce qui ne doit pas changer (caméra, géométrie, ouvertures) et nommer le rôle de chaque référence quand il y en a deux ou plus. Jusqu'à 4 références.
- Compter le quota. Une exécution dépense une image, et les exécutions peuvent être parallélisées, mais indiquer le nombre avant un grand lot et faire fonctionner la première image avant le reste.
- Références PNG avec transparence : passer
--keep-png-refs, car la conversion JPG les aplatie.
Pourquoi l'exécuteur existe
Mesuré avec codex-cli 0.164.0 le 2026-11-04, à partir des journaux de session de 30 exécutions d'images.
| Échec | Cause | Ce que fait l'exécuteur |
|---|---|---|
| Bloque jusqu'au délai d'attente | codex exec attend sur un tube d'entrée standard ouvert : 45 s avec un tube (arrêté par un délai), 4 s avec le tube fermé | Envoie la consigne sur stdin, puis ferme le tube |
| Image incorrecte sous un nom | Ayant reçu l'ordre d'enregistrer, Codex a cherché dans le dossier partagé ~/.codex/generated_images, a pris la plus récente et a copié l'image d'une autre exécution | Codex n'enregistre jamais ; l'exécuteur lit uniquement generated_images/<id de sa session>/ |
| Jusqu'à 7 appels image pour une sortie | Codex ne trouvait pas comment enregistrer, donc il a généré à nouveau | Arrête Codex à la première image complète |
| Référence ignorée, pièce inventée | L'outil image voit les pièces jointes seulement si l'appel définit num_last_images_to_include | Nomme le paramètre, lit le journal de session, code de sortie 3 s'il a été omis |
| Pièce perdue dans les passages enchaînés | Chaque passage de meubles alimenté par un PNG l'a perdue ; JPG avec le paramètre nommé l'a conservée (corrélation, non une cause prouvée) | Convertit les références PNG en JPG lorsque ffmpeg est dans le PATH |
Vérifié avec la vraie CLI le même jour : trois modifications, dont deux en parallèle sur une référence PNG, ont chacune pris environ 25 s et un appel image, et ont conservé leur propre changement de couleur.
Si vous devez utiliser codex-imagegen du plugin
codex-bridge 1.2.0 présente ces échecs. Appelez-le avec </dev/null, un travail à la fois, une référence JPG, et "appelez l'outil image exactement une fois avec num_last_images_to_include:1" dans la consigne, puis visualisez le résultat.