Codex Bildjobs
Führen Sie jeden Projekt- oder Batch-Bildjob über den Runner aus. Rufen Sie codex exec oder codex-imagegen für diese Jobs nicht von Hand auf.
python scripts/codex_image.py "<prompt oder @prompt.txt>" out.png [--ref room.jpg] [--size 1536x1024] [--force]
Es gibt den absoluten Ausgabepfad aus. Geben Sie dem Bash-Aufruf ein Timeout, das über dem eigenen --timeout des Runners liegt (Standard 420 s).
| Exit | Bedeutung | Handlung |
|---|---|---|
| 0 | Gespeichert | Bild ansehen |
| 1 | Nutzungsfehler, z. B. Ausgabe existiert | Aufruf korrigieren; --force ersetzt eine Ausgabe, niemals seine eigene Referenz |
| 2 | Codex endete ohne Bild | Ausgabe lesen, Ursache beheben, dann einmal wiederholen |
| 3 | Der Bildaufruf ließ die Referenz aus, daher wurde nichts gespeichert | Mit demselben Befehl einmal wiederholen |
| 124 | Keine Session oder kein Bild rechtzeitig | codex login status und Netzwerk prüfen |
Regeln
- Jede Ausgabe gegen ihre Vorgabe prüfen. Exit 0 beweist nur, dass ein Bild aus dieser Session stammt, nicht dass es korrekt ist.
- Bearbeitungen einzeln verketten: jede Ausgabe wird zum nächsten
--ref. Bei jedem Schritt in eine neue Datei schreiben. - Den Raum erhalten: angeben, was sich nicht ändern darf (Kamera, Geometrie, Öffnungen) und bei zwei oder mehr Referenzen die Rolle jeder Referenz benennen. Maximal 4 Referenzen.
- Das Kontingent zählen. Ein Durchlauf verbraucht ein Bild, und Durchläufe können parallel laufen, aber die Anzahl vor einem großen Batch angeben und das erste Bild zum Laufen bringen, bevor die restlichen folgen.
- PNG-Referenzen mit Alpha:
--keep-png-refsübergeben, da die JPG-Konvertierung sie flacht.
Warum der Runner existiert
Gemessen mit codex-cli 0.164.0 am 2026-11-04, aus den Session-Logs von 30 Bildläufen.
| Fehler | Ursache | Was der Runner tut |
|---|---|---|
| Hängt bis zum Timeout | codex exec wartet auf eine offene stdin-Pipe: 45 s mit Pipe (durch Timeout gestoppt), 4 s mit geschlossener | Sendet den Prompt auf stdin, schließt es dann |
| Falsches Bild unter einem Namen | Angewiesen zu speichern, durchsuchte Codex das gemeinsame ~/.codex/generated_images, nahm das neueste und kopierte das Bild eines anderen Laufs | Codex speichert nie; der Runner liest nur generated_images/<seine Session-ID>/ |
| Bis zu 7 Bildaufrufe für eine Ausgabe | Codex fand nicht, wie es speichern sollte, also generierte es erneut | Stoppt Codex beim ersten vollständigen Bild |
| Referenz ignoriert, Raum erfunden | Das Bildtool sieht Anhänge nur, wenn der Aufruf num_last_images_to_include setzt | Benennt den Parameter, liest das Session-Log, Exit 3 wenn er ausgelassen wurde |
| Raum bei verketteten Durchläufen verloren | Jeder Möbeldurchlauf fütterte ein PNG, das es verlor; JPG mit benanntem Parameter behielt es (Korrelation, kein bewiesener Grund) | Konvertiert PNG-Referenzen zu JPG, wenn ffmpeg im PATH ist |
Am selben Tag mit dem echten CLI geprüft: drei Bearbeitungen, zwei davon parallel auf einer PNG-Referenz, jede dauerte etwa 25 s und einen Bildaufruf, jede behielt ihre eigene Farbänderung.
Falls Sie das Plugin codex-imagegen verwenden müssen
codex-bridge 1.2.0 hat diese Fehler. Rufen Sie es mit </dev/null, einem Job nach dem anderen, einer JPG-Referenz und „call the image tool exactly once with num_last_images_to_include:1“ im Prompt auf, dann sehen Sie sich das Ergebnis an.