Vous avez terminé une tâche, mais ses fichiers modifiés semblent introuvables dans votre nouvelle tâche ?
Solution immédiate : rouvrez la tâche d’origine et vérifiez son espace de travail ; chaque tâche Codex Cloud dispose du sien, et une nouvelle tâche ne récupère pas automatiquement les changements non validés d’une autre. Pour protéger un résultat important, contrôlez les différences, lancez les tests pertinents, puis enregistrez le code dans votre système de gestion de versions.
Cet article s’adresse aux développeurs qui suivent des tâches Codex Cloud en voyage et doivent retrouver un travail interrompu.
Il concerne aussi les personnes qui changent souvent d’appareil et veulent pouvoir vérifier leurs modifications.
Si vous développez pour iOS, il vous aidera à distinguer le code produit dans le cloud des validations qui exigent réellement un environnement Mac.
Dernière vérification : 8 novembre 2026, d’après la documentation officielle de Codex Cloud, notamment ses indications sur l’isolation des tâches et la conservation de l’état de la machine virtuelle.
Trois états à ne pas confondre
Une conversation visible ne prouve pas que les fichiers ont été validés dans votre dépôt. Pour comprendre ce qui est récupérable, séparez trois éléments : l’historique de la tâche, son espace de travail et le dépôt Git auquel vous souhaitez conserver le code.
Codex Cloud associe un espace de travail à chaque tâche. Vous pouvez revenir à une tâche existante pour poursuivre son travail. En revanche, lancer une autre tâche crée un autre contexte de travail : les modifications non validées de la première ne sont pas automatiquement transférées dans la seconde. La documentation sur les tâches et les espaces de travail Codex Cloud décrit cette séparation.
| Ce que vous consultez | Ce que cela vous indique | Ce que cela ne garantit pas |
|---|---|---|
| La conversation d’une tâche | Les échanges et les étapes réalisées dans cette tâche | Que toutes les modifications sont présentes dans le dépôt ou qu’elles ont été validées |
| L’espace de travail de la tâche | Les fichiers associés à cette tâche et les changements qu’elle contient encore | Que ces fichiers seront disponibles dans une autre tâche |
| Le dépôt Git | Les modifications enregistrées par des commits et l’historique du projet | Que chaque changement temporaire de l’espace de travail a été commité |
Une situation fréquente en déplacement illustre le piège. Vous demandez une modification depuis votre téléphone, consultez le compte rendu, puis ouvrez une nouvelle tâche sur votre tablette pour ajouter un correctif. Le résultat précédent peut toujours exister dans l’espace de travail de sa tâche d’origine, sans être présent dans le nouvel espace de travail. Ce n’est pas la même chose qu’une disparition de l’historique, ni qu’un commit déjà enregistré dans le dépôt.
Une nouvelle tâche reprend-elle le code non validé de la précédente ? Non. Revenez à la tâche qui a produit ces changements, vérifiez ses fichiers et ses différences, puis décidez si vous devez continuer cette tâche ou transférer le code au moyen de votre flux de gestion de versions. Ne traitez pas une nouvelle tâche comme une reprise automatique.
La distinction est utile aussi pour les créations autres que le code. Si votre tâche produit des ressources pour un projet audio, vidéo ou graphique, un échange qui mentionne les exports ne suffit pas à confirmer que les fichiers attendus sont dans le dépôt. Vérifiez les fichiers eux-mêmes, leur emplacement et leur statut avant de quitter l’environnement.
Choisir la bonne action avant de reprendre
Avant de cliquer sur « nouvelle tâche », choisissez en fonction de ce que vous voulez retrouver. Le tableau ci-dessous résume les chemins les plus sûrs.
| Votre situation | Action à privilégier | Point de contrôle |
|---|---|---|
| La tâche semble inachevée ou les changements ne sont pas validés | Rouvrir la tâche d’origine et poursuivre dans son espace de travail | Vérifier que les fichiers attendus et les différences sont visibles |
| Vous voulez repartir sur un objectif distinct | Créer une nouvelle tâche, sans compter sur les fichiers non validés de l’ancienne | Vérifier que le nouveau contexte dispose du dépôt ou des changements nécessaires |
| Le code doit être conservé et revu ultérieurement | Examiner les différences, tester et commiter les changements importants | Confirmer que le commit figure dans la branche attendue |
| Vous avez besoin d’une validation propre à macOS ou Xcode | Prévoir un environnement Mac après avoir sécurisé les changements | Confirmer les exigences de construction, de test et de livraison du projet |
La première option est généralement la plus directe pour continuer un travail en cours. La seconde convient à un objectif distinct, mais vous devez explicitement apporter au nouveau contexte le code que vous souhaitez réutiliser. La troisième transforme un état de travail en trace consultable dans le dépôt. La dernière concerne les contraintes d’outillage : Codex Cloud ne doit pas être supposé équivalent à un Mac ou à Xcode.
Ces choix ont des avantages et des limites. Continuer l’ancienne tâche conserve le contexte de travail propre à celle-ci, mais ne remplace pas un enregistrement dans Git. Une nouvelle tâche clarifie une demande différente, mais ne rapatrie pas les modifications non validées d’un autre espace de travail. Un commit offre une trace dans le dépôt, mais il faut vérifier qu’il contient bien les fichiers attendus et qu’il respecte les règles de branche du projet.
Comment reprendre une tâche après une interruption ? Ouvrez la tâche d’origine, confirmez son état, puis contrôlez ses fichiers et ses différences avant de demander de nouvelles modifications. Si l’espace de travail n’est pas accessible, ne créez pas d’emblée une nouvelle tâche en supposant que les mêmes fichiers s’y trouveront : vérifiez d’abord l’accès à la tâche et au dépôt.
Reprendre après une pause ou une reconnexion
La documentation officielle précise que l’état enregistré d’une machine virtuelle peut être restauré pendant une fenêtre pouvant aller jusqu’à sept jours après la fin de la tâche. Cette indication concerne l’état de la machine virtuelle associé à la tâche ; elle ne constitue pas une promesse de conservation illimitée de chaque fichier, ni une durée de rétention de l’historique des conversations. Consultez la documentation Codex Cloud sur la reprise et l’état de la machine virtuelle pour vérifier les conditions applicables.
Le point de départ importe : le délai indiqué se compte après la fin de la tâche, et porte sur l’état de sa machine virtuelle enregistrée. Ne l’interprétez pas comme un compte à rebours qui s’appliquerait à tous les comptes, à tous les fichiers locaux ou à chaque message de conversation. La documentation ne permet pas non plus de garantir que tout état sera récupérable dans chaque situation.
Combien de temps l’espace de travail enregistré peut-il être restauré ? Selon l’indication officielle, l’état de machine virtuelle enregistré peut être restauré jusqu’à sept jours après la fin de la tâche. Après cette fenêtre, ou si la tâche ne s’ouvre pas comme prévu, vérifiez ce qui est effectivement visible et appuyez-vous sur les commits déjà présents dans le dépôt plutôt que de présumer que l’environnement temporaire subsiste.
Lors d’un retour tardif, procédez sans modifier l’état à l’aveugle :
- Ouvrez d’abord la tâche qui a produit le changement.
- Notez son état tel qu’il est affiché : terminée, en cours ou en attente.
- Vérifiez que les fichiers concernés sont accessibles et comparez-les au résultat attendu.
- Si l’état de la machine virtuelle n’est pas restauré, recherchez les commits et les fichiers déjà enregistrés dans le dépôt.
- Reprenez le travail dans la tâche d’origine lorsque son espace de travail est disponible ; sinon, fournissez le contexte et le code conservé à une nouvelle tâche.
Un résultat différent après reconnexion ne suffit pas à conclure que le code a été effacé. Il peut s’agir d’une tâche différente, d’un dépôt qui ne contient pas encore les changements, d’un problème d’accès ou d’un état de machine virtuelle qui n’est plus disponible. Ces causes demandent des vérifications différentes.
Vérifier, tester et enregistrer les modifications
Une habitude simple évite de confondre « l’agent a terminé » et « le projet est sauvegardé » : contrôlez les changements avant de quitter le contexte qui les contient. La documentation officielle de Codex Cloud recommande de revoir le travail et d’utiliser le contrôle de versions pour conserver les modifications utiles.
Comment enregistrer les changements d’une tâche dans GitHub ? Vérifiez d’abord le contenu du diff et les fichiers concernés, puis suivez le flux Git prévu par votre dépôt pour créer un commit et, si nécessaire, pousser la branche. La documentation de GitHub sur l’ajout et la validation d’un fichier dans un dépôt décrit l’enregistrement des changements ; les étapes exactes peuvent varier selon votre outil et les règles du projet.
Pour chaque changement que vous comptez conserver, suivez cette procédure :
- Repérez la tâche d’origine. Comparez son objectif avec le résultat recherché. Si vous avez plusieurs tâches ouvertes, utilisez leur contexte et leur état plutôt que la tâche la plus récemment consultée.
- Inspectez les fichiers concernés. Vérifiez le diff, les fichiers nouveaux, modifiés ou supprimés, ainsi que les chemins attendus par le projet.
- Lancez les vérifications adaptées. Exécutez les tests disponibles pour la modification et lisez leur résultat. Un compte rendu de tâche n’est pas un substitut aux tests requis pour votre livraison.
- Enregistrez un changement compréhensible. Créez un commit selon les conventions du dépôt, avec les fichiers voulus. Le commit est une action de votre flux de travail : ne supposez pas que la fin d’une tâche l’a créé automatiquement.
- Vérifiez la branche et la publication. Confirmez que le commit se trouve dans la branche prévue. Si le projet exige une publication distante, contrôlez que le push a abouti.
- Reprenez depuis une trace vérifiable. À votre prochain changement d’appareil, comparez la tâche d’origine et l’état du dépôt. Vous pouvez ainsi distinguer le code enregistré des changements encore présents uniquement dans un espace de travail.
La partie publication mérite une vérification séparée. Un push peut échouer parce que votre compte n’a pas les droits nécessaires, parce que l’authentification n’est pas configurée ou parce qu’une règle de branche bloque l’opération. La documentation GitHub sur l’authentification à GitHub explique le rôle des méthodes d’authentification. La page sur les branches protégées et leurs restrictions permet de vérifier si une règle de dépôt limite les opérations sur une branche.
Distinguez donc deux familles de problèmes. Si le fichier ou le diff n’apparaît pas, commencez par vérifier la tâche et son espace de travail. Si les changements sont visibles mais ne peuvent pas être publiés, examinez plutôt l’accès au dépôt, l’authentification et les protections de branche. Un échec de push ne prouve pas que les fichiers ont disparu ; inversement, des fichiers visibles dans une tâche ne prouvent pas qu’ils sont déjà sur GitHub.
Reprendre depuis un autre appareil sans créer de confusion
En voyage, l’interruption peut venir d’un changement de réseau, d’un appareil perdu ou d’une session fermée. Ces événements ne changent pas la règle de base : retrouvez d’abord la tâche qui contient le travail. L’écran d’un téléphone ou d’une tablette peut rendre l’inspection des différences moins confortable, mais il ne transforme pas la nouvelle tâche en copie de l’ancienne.
Dans un café, par exemple, vous demandez une correction depuis un téléphone, puis la connexion se coupe avant que vous puissiez lire le compte rendu. À votre arrivée, vous ouvrez Codex Cloud sur un ordinateur léger. La reprise prudente consiste à retrouver la tâche initiale, confirmer que les fichiers sont disponibles, puis examiner ce qui a été modifié. Si vous ouvrez une nouvelle tâche pour demander autre chose, indiquez explicitement le contexte et partez du code conservé dans le dépôt lorsque cela est nécessaire.
Si vous ne retrouvez pas l’environnement, séparez le diagnostic :
- La tâche n’est pas accessible : vérifiez que vous consultez le bon compte et le bon contexte, puis réessayez depuis un appareil et un réseau accessibles.
- La tâche s’ouvre, mais les fichiers attendus manquent : confirmez qu’il s’agit bien de la tâche d’origine et vérifiez si les changements sont déjà présents dans le dépôt.
- Les fichiers sont là, mais leur publication échoue : examinez les droits de dépôt, l’authentification et les règles de branche.
- La tâche ou son état paraît différent après la pause : vérifiez la fenêtre de restauration annoncée pour l’état de machine virtuelle et ne l’étendez pas à l’historique ou à tous les fichiers.
Cette séparation évite de corriger le mauvais problème. Réinitialiser des identifiants ne restaurera pas un espace de travail disparu ; créer une nouvelle tâche ne réparera pas un droit d’accès au dépôt. Si un commit existe déjà, il constitue une référence à comparer avec l’état de la tâche, et non une preuve que tous les changements intermédiaires ont été conservés.
Valider séparément un projet iOS
Pour un projet iOS, la présence de modifications dans Codex Cloud répond à une question : le code produit est-il encore accessible et conservé dans le dépôt ? Elle ne répond pas à une autre question : le projet se construit-il et se teste-t-il dans l’environnement de livraison requis ?
Codex Cloud ne doit pas être assimilé à un Mac ou à un environnement Xcode. Après avoir vérifié le diff, les tests possibles et le commit, examinez les exigences réelles du projet : construction avec Xcode, tests qui dépendent des outils Apple, validation d’un comportement propre à iOS ou préparation d’un livrable. La documentation Apple consacrée à Xcode décrit l’environnement de développement et ses outils. Le besoin d’un Mac dépend donc des étapes que votre projet doit effectivement franchir, pas du seul fait que Codex Cloud a produit du code.
Vous pouvez organiser le travail en deux temps : sécuriser d’abord les changements dans le dépôt, puis effectuer les vérifications macOS nécessaires. Cette séparation est particulièrement utile lorsque vous suivez un projet depuis une tablette : le téléphone peut suffire à contrôler l’avancement d’une tâche, mais il ne remplace pas automatiquement l’environnement demandé pour une construction ou un test iOS.
Si cette validation doit être faite sur un Mac accessible à distance, vous pouvez comparer les solutions Mac proposées par MACCOME avec vos contraintes de projet, d’accès et de durée. Un Mac distant n’est pas nécessaire pour chaque tâche Codex Cloud ; il devient pertinent lorsque votre chaîne de construction ou de test exige réellement macOS.
Votre contrôle avant de fermer la tâche
Avant de quitter une tâche susceptible de contenir du travail utile, assurez-vous de pouvoir répondre à ces questions : avez-vous rouvert la bonne tâche ? Les fichiers et les différences attendus sont-ils visibles ? Les tests pertinents ont-ils été examinés ? Les changements à conserver ont-ils un commit dans la branche voulue ? En cas d’échec de publication, avez-vous vérifié les droits, l’authentification et les règles de branche au lieu de supposer que les fichiers ont été perdus ?
Si vous ne pouvez pas confirmer la présence d’un commit, ne comptez pas sur une future tâche pour récupérer des changements non validés. Reprenez la tâche d’origine pendant que son état est accessible et sécurisez le code avant de changer de contexte. La fenêtre annoncée pour l’état de machine virtuelle est limitée ; elle ne remplace ni une sauvegarde versionnée ni une vérification de votre dépôt.
Pour un projet qui exige ensuite une construction, des tests ou une préparation de livraison sous macOS, comparez le coût de cette étape avec vos besoins réels : les solutions locales peuvent être préférables si vous travaillez durablement sur une charge importante ou avez besoin de périphériques physiques. Si vous avez plutôt besoin d’un environnement Mac temporaire pour achever une validation, consulter les options de Mac mini cloud de MACCOME peut vous aider à décider si cette étape distante complète utilement votre flux de travail.