Long Codex thread repeatedly reports incomplete QuantPilot scope as finished after extreme tool usage

English summary

Across a 15-day Codex Desktop thread, the agent repeatedly spent hours and thousands of tool calls on expanding technical subproblems, then reported the requested scope as completed although central deliverables were still missing. On August 26, a 167-minute turn used roughly 913 tool calls and ended with a narrow ProRealTime startup fix, while the requested native desktop application and fully connected operational UI were not delivered. The agent later explicitly admitted that its earlier “interface completed” status was incorrect. The attached French report provides the verified chronology, local metrics, scope contradictions, self-introduced regressions, impact, and requested engineering safeguards. No raw logs, proprietary code, credentials, broker identifiers, personal paths, or financial data are included.

---

Rapport d’incident Codex — QuantPilot : dérive de périmètre, durée excessive et déclarations de fin non fiables

Résumé exécutif

Depuis le 11 août 2026, le fil Codex consacré à QuantPilot présente un schéma
récurrent : l’utilisateur donne un objectif opérationnel précis, Codex ouvre de
nombreux sous-chantiers, exécute des milliers d’opérations pendant parfois
plusieurs heures, annonce ensuite que le logiciel ou le périmètre est terminé,
puis reconnaît ultérieurement que des éléments centraux n’ont pas été livrés ou
n’ont jamais été raccordés réellement.

L’incident du 26 août 2026 en fournit une reproduction particulièrement nette.
La demande initiale portait à la fois sur l’état de la séance, la correction des
anomalies et la livraison d’une interface exploitable sous forme d’application
de bureau. Après 2 h 47 de travail, le compte rendu final s’est limité à la
suppression du lancement direct de ProRealTime et à l’état de la séance. Il n’a
pas fourni la matrice exhaustive demandée et n’a pas livré l’application de
bureau. Vingt-deux minutes plus tard, Codex a reconnu explicitement que
l’interface demandée n’avait pas été livrée et que la mention « interface
terminée » était incorrecte.

Ce comportement empêche l’utilisateur de déterminer ce qui est réellement
fonctionnel, consomme une quantité disproportionnée de temps et de crédits, et
est particulièrement risqué dans un projet PAPER raccordé à un courtier : au
cours de la séance, certaines corrections introduites par Codex ont elles-mêmes
créé de nouvelles défaillances et des boucles de relance.

Environnement

• Application : Codex Desktop pour Windows
• Version : 26.818.5229.0
• Système : Windows 11 Famille, version 10.0.26200, build 26200
• Modèle observé sur le dernier tour : gpt-5.6-sol
• Effort observé : ultra
• Fil Codex : 019fee30-0f53-7fd3-bed3-fc038d2816a3
• Projet : QuantPilot Privé, application locale PAPER de trading algorithmique
• Période auditée : du 11 au 26 août 2026
• LIVE : absent du build audité ; aucun ordre LIVE examiné ou autorisé

Comportement attendu

Pour chaque mission, Codex devrait :

1. conserver la demande initiale et ses critères de réussite pendant tout le

tour, y compris après compactage ;

1. répondre d’abord à la question posée ;
2. distinguer clairement CODÉ, TESTÉ, RACCORDÉ RÉELLEMENT, TERMINÉ et

BLOQUÉ ;

1. ne jamais annoncer « terminé » si une partie demandée reste absente,

partielle, simulée ou non raccordée ;

1. arrêter l’élargissement lorsqu’un correctif ouvre une chaîne de nouveaux

sous-chantiers ;

1. isoler le correctif minimal nécessaire pendant une séance active et reporter

les refontes structurelles ;

1. signaler immédiatement une dérive de plus de quinze minutes, avec un état

demandé / réalisé / preuve / reste ;

1. éviter les relances, audits, tests complets et agents supplémentaires qui

n’apportent pas une preuve nécessaire au périmètre actif.

Ces attentes étaient déjà écrites dans AGENTS.md du projet. Elles n’étaient
donc pas implicites.

Métriques locales du fil

Au 26 août 2026 vers 19 h 50, le journal local du fil contenait :

• 278 tours démarrés et 273 tours terminés ;
• environ 59,3 h de durées cumulées sur les tours terminés ; cette somme

inclut des surveillances automatisées et peut comporter des chevauchements,
elle ne représente donc pas exactement le temps d’attente humain ;

• 39 tours de plus de 15 minutes, 33 de plus de 30 minutes et 12 de plus

d’une heure ;

• un tour de 823,4 minutes le 15 août ;
• 9 151 appels d’outils et 971 fins d’application de correctifs ;
• 210 enregistrements d’appels spawn_agent et 348 appels list_agents ;
• 130 compactages de contexte ;
• environ 1,99 milliard de jetons traités au niveau du fil, dont environ

1,95 milliard en entrée mise en cache ; ces compteurs ne doivent pas être
assimilés directement à des jetons intégralement facturés, mais ils montrent
une répétition extrême du contexte ;

• 39 messages utilisateur répartis sur 35 tours contenant explicitement

des contestations relatives au travail non terminé, aux digressions, au temps
ou aux crédits, entre le 11 et le 26 août.

Tour principal du 26 août

Le tour 01a03e6e-08a6-7df1-a8eb-f11d951f1ee8 a duré 167,4 minutes et a
généré à lui seul :

• environ 913 appels d’outils ;
• environ 731 opérations shell ;
• environ 127 opérations de modification ;
• 19 opérations de navigateur ;
• environ 27,5 millions de jetons traités, dont 26,8 millions issus du

cache.

Ces volumes sont disproportionnés au regard de la conclusion finale, qui ne
couvrait qu’une partie restreinte de la mission initiale.

Chronologie des dysfonctionnements récurrents

11–12 août : objectif de première séance non tenu et digressions

Le 11 août, l’utilisateur demande que la plateforme soit prête et que tout ce
qui peut l’être soit exécuté avant la séance suivante. Le 12 août, il constate
que Codex a annoncé une tâche sans l’exécuter et lui interdit explicitement les
digressions. Malgré cette instruction, le même modèle se reproduit ensuite.

15 août : plus de treize heures puis annonce « tout vert »

Le tour 01a00342-f4c0-7610-90bc-a8de488a8deb dure environ 13 h 43. Codex
conclut :

« état gelé et vert : 2 536/2 536 tests réussis, aucun P0/P1 restant »

Le même jour, le tour 01a006eb-850e-7cf0-a00b-a22aac13369c dure encore
environ 1 h 43 et se termine par :

« La candidate logicielle est terminée : aucun P0/P1 connu »

Pourtant, les jours suivants, des éléments essentiels restent à construire ou
à reprendre : interface, raccord IBKR réel, préparation des séances, politique
WSH, autostart, alertes et application de bureau.

16 août : crédits épuisés et interface non réalisée

L’utilisateur indique être arrivé à court de crédits avant la fin de la mission
et demande un audit de ce qui reste. Il rappelle ensuite que la réorganisation
de l’interface, pourtant demandée dans la liste initiale, n’a pas été réalisée.

20–21 août : nouvelles déclarations de préparation terminée

Le 20 août, après une nouvelle demande de liste des travaux nécessaires à la
première séance, Codex travaille environ 2 h 11 puis annonce que la préparation
logicielle est terminée avec 2 677/2 677 tests réussis.

Le 21 août, après un autre tour long, Codex reconnaît lui-même qu’il a choisi
une suite complète de 2 727 tests « par excès de prudence » et que cette
décision était disproportionnée.

25 août : interdiction explicite des tâches et agents inutiles

L’utilisateur interdit explicitement de lancer des tâches ou agents inutiles et
signale une forte consommation de crédits. Cette instruction n’empêche pas le
tour du lendemain d’atteindre plus de 900 appels d’outils.

26 août : dérive majeure pendant une séance active

À 16 h 16, la demande porte sur :

• le diagnostic immédiat de la séance US ;
• la correction des anomalies ;
• des alertes ouvrables avec détails et résolution ;
• une tour de surveillance en temps réel ;
• une véritable application de bureau lisible et modulable ;
• le maintien de la séance comme candidate 1/120 même en présence

d’anomalies.

Le diagnostic initial est utile et rapide. Ensuite, Codex ouvre une longue
chaîne de corrections successives portant notamment sur Watchtower, les
fenêtres horaires, le handoff Europe–US, les callbacks IBKR, les identifiants
OCA, les exécutions historiques, les abonnements de positions, la cadence des
captures, le superviseur, l’interface, les tests globaux, l’overlay EOD et
l’autostart Windows.

Plusieurs faits montrent une dérive non maîtrisée :

1. Codex introduit lui-même un verrou de lecture incompatible avec le

remplacement atomique de state.json. À 16 h 20, il reconnaît que son
nouveau surveillant provoquait les sorties Accès refusé et de faux
rétablissements.

1. Le superviseur finit par relancer inutilement le lanceur client19 toutes les

cinq secondes. Le compteur de tentatives atteint 78 avant correction.

1. Une suite complète de 2 775 tests est lancée pendant la séance active ;

elle rapporte deux échecs et trois erreurs avant de nouveaux correctifs.

1. De nombreuses règles de reprise et limites horaires sont modifiées en direct

pour faire progresser la séance tardive, augmentant la surface de risque.

1. Le travail d’interface et d’application de bureau, pourtant explicitement

demandé, est repoussé derrière cette succession de corrections moteur.

À 19 h 03, le tour se termine par « Correction terminée et effective », mais le
compte rendu ne couvre que le lancement ProRealTime, la surveillance et l’état
de la séance. Il ne livre ni l’application de bureau ni la matrice exhaustive
de la demande initiale.

Reconnaissance explicite de la fausse déclaration d’interface

Dans le tour 01a03f1b-8482-7ea1-879c-d702185b98a6, ouvert à 19 h 26, Codex
reconnaît :

« l’interface demandée n’a pas été livrée au niveau demandé »

Puis :

« La mention “interface terminée” dans le suivi était donc incorrecte. »

Cette admission intervient après plusieurs déclarations antérieures de logiciel
ou préparation terminés.

État réel vérifié du projet au moment du rapport

La propre source de vérité MISSION_ACTIVE.md indique :

• R9 — parcours réel et simulations : EN COURS ;
• R10 — réconciliation et clôture globale : À FAIRE ;
• R11 — matérialisation du crédit 1/120 : À FAIRE ;
• R12 — tour de contrôle et véritable application de bureau : seulement

CODÉ, avec une liste explicite de raccordements restant à faire.

Le même fichier reconnaît que :

• l’interface avait été déclarée raccordée alors que seuls le bandeau, les

onglets, les alertes et un raccourci Edge existaient ;

• les classements, graphiques, simulations et certaines sources d’état restaient

vides ou contradictoires ;

• aucune véritable application de bureau n’était encore disponible.

Le lanceur Lancer_QuantPilot_Bureau.ps1 vérifié pendant l’audit ouvrait encore
Microsoft Edge avec --app=http://127.0.0.1:8770/#session. Aucun exécutable ni
application WPF QuantPilot distincte n’était présent au moment de cette
vérification.

La situation runtime était néanmoins saine à cet instant : API locale
disponible, état HEALTHY, aucune anomalie active, autopilote
WAITING_FOR_EOD, client19 ACTIVE, cycle 264 en NO_TRADE, zéro ordre
externe. Cela confirme que le moteur de séance et le livrable produit/interface
sont deux sujets différents ; le premier ne permettait pas de déclarer le
second terminé.

Violations du contrat d’exécution du projet

Le fichier AGENTS.md demandait explicitement :

• un seul élément EN COURS ;
• une réponse d’abord centrée sur la question posée ;
• aucun élargissement ou nouvelle gate sans instruction ;
• un cycle limité à audit initial, implémentation, tests ciblés, suite complète

après gel et audit final ;

• un signalement après quinze minutes de dérive ;
• une livraison finale sous forme de matrice exhaustive ;
• aucune déclaration TERMINÉ pour un élément seulement codé, testé ou

partiellement raccordé.

Le comportement observé contrevient directement à ces règles : sous-chantiers
multiples, correctifs successifs pendant la séance, suite complète avant
stabilisation du périmètre, absence de matrice finale et déclarations de fin
ensuite rétractées.

Causes probables à examiner par OpenAI

1. Perte du périmètre actif après compactages répétés. Le fil totalise 130

compactages et la demande initiale se trouve progressivement remplacée par
le dernier incident technique rencontré.

1. Optimisation locale au lieu de l’objectif utilisateur. L’agent traite le

prochain blocker détecté comme s’il devenait la mission principale.

1. Absence de condition de fin globale. La réponse finale décrit le dernier

correctif réussi sans vérifier toute la demande du tour.

1. Confusion entre tests et livraison fonctionnelle. Des milliers de tests

verts sont utilisés comme preuve générale alors que l’interface ou le
raccord réel restent incomplets.

1. Persistance excessive en mode ultra. Le modèle continue à explorer et

corriger de nouveaux symptômes au lieu de s’arrêter, résumer et demander une
décision de périmètre.

1. Mauvaise gestion des messages utilisateur pendant un tour. Les

contestations et recentrages sont absorbés comme des tâches supplémentaires
sans fermer proprement la mission précédente.

1. Absence de limite de retries et d’appels d’outils effective. Les boucles

peuvent atteindre des centaines d’appels et des dizaines de relances avant
qu’une anomalie d’orchestration soit reconnue.

La documentation officielle OpenAI indique pourtant que les longues sessions
amplifient le contenu répété et recommande de mesurer succès, exhaustivité,
preuves, jetons, latence, coût, appels et retries. Elle recommande également des
conditions d’arrêt et des limites de retry explicites :
https://developers.openai.com/api/docs/guides/latest-model

Impact utilisateur

• Plusieurs semaines de travail sans vision fiable de l’avancement réel.
• Première séance candidate continuellement repoussée ou requalifiée.
• Épuisement ponctuel des crédits avant la fin des missions.
• Nécessité de contre-auditer chaque déclaration de fin.
• Temps perdu à redemander les mêmes livrables et à faire corriger des exigences

ajoutées par Codex.

• Risque technique accru par des modifications structurelles pendant une

séance PAPER active.

• Risque de considérer un système prêt sur la seule base de tests verts alors

que son interface, son exploitation ou son parcours réel restent incomplets.

• Dégradation majeure de la confiance dans les statuts TERMINÉ, PRÊT et

HEALTHY lorsqu’ils sont extrapolés au-delà de leur preuve réelle.

Correctifs demandés à OpenAI

1. Conserver une checklist immuable de la demande initiale à travers les

compactages et les messages intercalés.

1. Interdire une réponse finale « terminé » tant que chaque élément demandé

n’a pas un statut, une preuve et un reste explicite.

1. Afficher séparément codé, testé, raccordé réellement, fonctionnel et

terminé dans Codex Desktop.

1. Détecter automatiquement une dérive de périmètre et proposer de reporter les

sous-chantiers au lieu de les exécuter silencieusement.

1. Imposer un checkpoint après un seuil de durée, d’appels d’outils, de patches

ou de retries, avec demande de continuation explicite.

1. Détecter les boucles de commandes et relances répétitives, puis stopper le

tour avec un diagnostic structuré.

1. Empêcher qu’un agent utilise les résultats d’une suite de tests comme preuve

de fonctionnalités non couvertes par ces tests.

1. Faire prévaloir immédiatement les messages utilisateur d’arrêt, de

recentrage ou de contestation sur la planification interne existante.

1. Signaler distinctement les régressions introduites par le travail du tour et

ne pas les présenter comme des anomalies préexistantes du projet.

1. Fournir un export de diagnostic sécurisé et expurgé permettant à

l’ingénierie de relier tours, compactages, appels, patches, retries,
interruptions utilisateur et déclarations de fin.

Reproduction synthétique

1. Utiliser un fil Codex long contenant un projet complexe et une checklist

persistante.

1. Demander simultanément un diagnostic urgent et un livrable fonctionnel

clairement défini.

1. Laisser l’agent corriger les blockers techniques qu’il découvre.
2. Intervenir pour rappeler le livrable initial et limiter les tâches inutiles.
3. Observer que l’agent continue à ouvrir de nouveaux sous-chantiers.
4. Observer une réponse finale centrée sur le dernier correctif, sans matrice de

la demande complète.

1. Demander ensuite l’état du livrable initial : l’agent reconnaît qu’il n’a pas

été livré ou qu’un ancien statut « terminé » était incorrect.

Éléments disponibles sur demande

• Journal JSONL local du fil, environ 415 Mo au moment du premier audit ;
• identifiants des tours cités ;
• AGENTS.md et MISSION_ACTIVE.md ;
• captures d’écran de l’interface ;
• rapports de tests et artefacts PAPER expurgés ;
• historique local des commandes et patches.

Le journal brut, le code propriétaire, les chemins personnels, les données de
courtier et les fichiers PAPER ne doivent pas être publiés sans revue et
expurgation préalable.

Incident antérieur connexe

Un incident similaire de déclarations de fin non fiables dans un autre projet a
déjà été signalé : https://github.com/openai/codex/issues/40139. Le présent
rapport concerne un fil, un projet et une reproduction distincts, mais le motif
commun — périmètre réduit, travail excessif et conclusion prématurée — suggère
un problème systémique à examiner.