La connexion SSH aboutit, mais Codex App ne trouve pas le projet ou la compilation iOS s’arrête sur le Mac distant.
Résolution la plus rapide : vérifiez dans cet ordre la connexion SSH, l’accès au bon dossier et l’environnement Xcode ; ne passez aux tests, à la signature ou à l’envoi qu’après avoir identifié et corrigé le premier échec.
Cette procédure s’adresse aux développeurs Windows ou Linux qui confient la compilation iOS à un Mac piloté depuis Codex App, ainsi qu’aux petites équipes qui diagnostiquent un problème d’accès ou d’exécution. Elle convient aussi si vous évaluez la capacité d’un Mac distant à prendre en charge votre chaîne de compilation et de test.
Mise à jour : 7 octobre 2026. Le statut de la connexion SSH dans Codex App doit être vérifié dans la documentation officielle avant chaque mise en production : l’annonce d’OpenAI du 16 avril 2026 sur Codex App et la connexion à des machines distantes présentait cette capacité comme une version alpha, ce qui ne confirme pas à lui seul son état actuel, son périmètre ni les étapes disponibles aujourd’hui.
Isolez le premier maillon qui échoue
Une session SSH ouverte prouve seulement qu’un client a pu atteindre une machine et s’y authentifier. Elle ne prouve pas que Codex App utilise le même compte, que le dépôt est accessible depuis sa session, que la bonne version de Xcode est sélectionnée ou que le Mac peut exécuter un simulateur et signer une application.
Avant de modifier la configuration, relevez les symptômes dans cet ordre :
- Codex App reconnaît-il la machine distante et lance-t-il une session ?
- La connexion SSH fonctionne-t-elle avec le même hôte, le même utilisateur et la même clé ?
- Le processus distant peut-il lire et modifier le répertoire attendu ?
- La commande de compilation démarre-t-elle, et quel est son premier message d’erreur ?
- La compilation seule réussit-elle, ou avez-vous aussi besoin d’un test sur simulateur, d’une signature ou d’un envoi ?
La documentation OpenAI qui présente la connexion SSH de Codex App constitue un point de départ pour vérifier le statut et le périmètre annoncés ; ne reprenez pas une ancienne description comme preuve que votre version dispose encore du même écran ou des mêmes fonctions. Si l’option n’apparaît pas ou si son comportement diffère, vérifiez d’abord l’aide officielle actuelle plutôt que de contourner le contrôle d’accès.
Distinguez un refus SSH d’un échec de Codex App
Comment relier Codex App à un Mac distant par SSH ? Utilisez les paramètres de connexion proposés par la version actuelle de l’application et comparez-les à une connexion SSH indépendante, avec le même nom d’hôte, le même compte et la même méthode d’authentification. L’annonce officielle du produit ne garantit pas à elle seule que chaque compte, version ou configuration réseau dispose de cette fonction.
Dans un terminal séparé, testez la connexion avec les valeurs réellement prévues pour Codex App. Si l’accès indépendant échoue aussi, l’erreur précède l’application : vérifiez le nom d’hôte, la résolution réseau, le port autorisé par votre environnement, le compte distant, la clé choisie et les règles de connexion du serveur. Si le test indépendant réussit mais que Codex App échoue, comparez les identités et les paramètres employés par les deux clients ; une clé chargée dans votre terminal n’est pas nécessairement disponible dans l’application.
Procédez sans élargir les droits par défaut :
- Vérifiez que l’hôte et le compte sont ceux remis pour cette machine, sans copier une adresse ou un nom d’utilisateur provenant d’une ancienne session.
- Confirmez que la clé privée correspond à la clé publique autorisée sur l’hôte et que le client utilise bien cette clé.
- Contrôlez les journaux de connexion côté client et, si vous en avez l’autorisation, les journaux du serveur pour distinguer une erreur réseau d’un refus d’authentification.
- Comparez les résultats avec le même réseau et le même compte que ceux utilisés par Codex App.
- Après correction, relancez un test SSH simple ; ne passez au diagnostic du dépôt que lorsque l’authentification est stable.
Pour tout partage d’erreur ou demande d’assistance, masquez les noms de compte, l’adresse de l’hôte, les chemins personnels et le contenu des clés. Gardez seulement les éléments nécessaires pour comprendre la classe d’erreur ; une capture d’écran peut exposer des données que le texte du message ne révèle pas.
Vérifiez quel projet la session distante utilise réellement
SSH fonctionne, mais Codex App ne trouve pas le projet iOS : que vérifier ? Commencez par établir l’identité macOS de la session lancée par l’application, puis confirmez que le dépôt attendu existe et que cet utilisateur peut le lire et y enregistrer des modifications. La réussite d’une connexion ne signifie pas que l’agent travaille sur la copie locale que vous avez en tête.
Comparez le chemin du dépôt dans votre session SSH indépendante à celui utilisé par Codex App. Les répertoires d’accueil, les variables d’environnement et les volumes montés peuvent différer selon le compte ou le mode de lancement. Vérifiez également si le projet a été cloné sur le Mac distant, si la branche active est celle attendue et si les fichiers nécessaires sont présents. Un chemin relatif, en particulier, peut pointer vers un autre endroit si le répertoire courant n’est pas celui du dépôt.
Appliquez ces contrôles avant de relancer une commande de compilation :
- Affichez l’utilisateur distant et le répertoire courant dans le contexte d’exécution concerné.
- Confirmez le chemin absolu du dépôt, puis vérifiez que le projet contient bien les fichiers d’entrée et de configuration attendus.
- Vérifiez les droits de lecture et d’écriture sur le répertoire, sans rendre toute l’arborescence modifiable par tous les comptes.
- Contrôlez la branche et les changements du dépôt avant et après une tâche ; vous saurez ainsi quelle copie a été consultée ou modifiée.
- Si l’application semble viser une autre copie, arrêtez les modifications et sélectionnez ou ouvrez explicitement le bon répertoire avant de reprendre.
Consignez le chemin du dépôt et la branche sous une forme expurgée si vous transmettez le diagnostic. Ne partagez pas les URL privées du dépôt, les noms de projets confidentiels ni les identifiants de compte. Le contrôle de version doit permettre de confirmer l’emplacement des changements sans divulguer l’historique ou les secrets du projet.
Validez l’installation et la sélection de Xcode
Quand la commande s’exécute mais échoue avant ou pendant la compilation, vérifiez le système installé et le répertoire développeur actif. macOS peut contenir les outils en ligne de commande sans fournir l’installation complète de Xcode attendue par le projet. La documentation Apple distingue l’installation des outils en ligne de commande des fonctionnalités de l’environnement Xcode complet.
Relevez la version de macOS et celle de Xcode, puis comparez-les aux exigences système publiées par Apple pour Xcode. Les exigences évoluent : ne partez pas du principe qu’une version installée convient à toute version de macOS, ni que la configuration d’un autre Mac est reproductible sur celui-ci. Cette vérification porte sur la compatibilité annoncée, pas sur la réussite du projet lui-même.
Examinez ensuite le chemin du répertoire développeur actif et la sélection des outils en ligne de commande. Apple documente ces réglages dans la référence sur la configuration des outils en ligne de commande ; comparez le résultat à l’installation que votre projet doit utiliser. La référence des commandes Xcode aide à confirmer quelles commandes sont disponibles, mais la présence de commandes ne démontre pas que les composants, les SDK ou les ressources nécessaires à votre cible sont installés.
Interprétez les indices dans leur contexte :
- Si la commande de compilation n’existe pas, vérifiez l’installation et le chemin des outils avant d’examiner les réglages du projet.
- Si Xcode démarre mais indique un SDK ou une destination indisponible, contrôlez la sélection de la version et la présence des composants ciblés.
- Si le projet compile avec une version de Xcode mais pas avec celle sélectionnée dans la session distante, comparez les deux environnements et les exigences du projet avant de changer de version.
- Si l’erreur concerne une dépendance ou un script du projet, conservez le diagnostic Xcode exact ; ne concluez pas automatiquement à une installation Xcode défectueuse.
Séparez compilation, simulateur, signature et envoi
Une compilation en ligne de commande ne valide pas toutes les étapes de livraison. L’Archive, l’exécution sur un simulateur, les essais sur appareil, la signature et l’envoi à App Store Connect répondent à des conditions différentes. La documentation Apple sur l’exécution sur simulateur ou appareil physique permet de vérifier la cible choisie, sans pour autant garantir qu’une session distante dispose d’un environnement graphique utilisable.
Un projet peut-il compiler sans pouvoir lancer le simulateur ? Oui : une compilation réussie ne prouve pas que le runtime correspondant est installé ni que la session dispose des conditions nécessaires pour démarrer et observer le simulateur. Si votre besoin est seulement de produire un artefact, validez cette étape séparément ; si vous devez exécuter des tests d’interface ou inspecter l’affichage, effectuez un essai distinct dans les conditions de session prévues.
Pour les essais sur appareil, vérifiez que l’appareil requis peut être associé au Mac et que la méthode d’accès permet de mener le test. La documentation Apple sur la distribution aux appareils enregistrés décrit les exigences de cette voie de distribution ; elle ne signifie pas qu’un appareil physique est automatiquement accessible depuis une machine distante. Un besoin de branchement local, d’interaction graphique ou de validation sur matériel réel doit être testé sur le chemin exact que vous comptez exploiter.
Quelles conditions de signature faut-il contrôler pour une compilation distante ? Vérifiez que la cible, l’équipe, le profil de provisionnement et l’identité de signature correspondent au type de livraison visé, puis confirmez que la session utilisée peut accéder aux éléments nécessaires. Ne copiez pas un certificat privé, un mot de passe ou une clé d’API dans un journal ou une conversation. Si l’équipe partage des certificats, suivez les indications Apple sur le partage des certificats de signature et faites confirmer les droits par la personne qui gère la signature.
Enfin, distinguez un Archive valide d’un transfert terminé et d’un traitement achevé. Pour l’envoi, consultez les exigences Apple relatives au téléversement de versions dans App Store Connect, puis observez séparément le résultat de l’envoi et l’état du traitement. Si la compilation et la signature sont acceptées mais que l’envoi échoue, reprenez le diagnostic à cette étape ; ne recommencez pas la configuration SSH sans élément indiquant que la connexion est en cause.
Choisissez la bonne suite selon les preuves recueillies
La liste suivante sert à décider où poursuivre, plutôt qu’à relancer toute la chaîne à chaque échec :
- Si le test SSH indépendant échoue, traitez d’abord le réseau, le compte ou la clé ; ne modifiez pas le projet ni Xcode.
- Si SSH fonctionne mais que le répertoire est absent ou non modifiable, corrigez le chemin, la copie du dépôt ou les autorisations limitées ; ne lancez pas de compilation tant que la destination des fichiers n’est pas certaine.
- Si le dépôt est accessible mais que les outils sélectionnés sont absents ou incompatibles, faites valider l’installation et le répertoire développeur avec les références Apple ; reprenez ensuite la commande sur le même commit.
- Si la compilation passe mais que le simulateur échoue, traitez le runtime, la destination et les contraintes de session comme un problème de test distinct.
- Si l’Archive passe mais que la signature ou l’envoi échoue, vérifiez les profils, les identités et les autorisations de compte sans exposer les secrets.
- Si le besoin inclut un appareil physique ou une interaction graphique, ne considérez pas la seule réussite en ligne de commande comme une validation suffisante : testez cet usage sur le Mac et dans la session concernés.
Comparez les options avant de déplacer votre chaîne de compilation
Les tableaux suivants servent à juger la portée réelle du test et la suite adaptée. Les appréciations décrivent les preuves à recueillir ; elles ne sont ni des mesures de performance ni une garantie qu’une version de Codex App prend en charge chaque étape. Pour une présentation de l’accès à un Mac distant, vous pouvez consulter les solutions Mac de MACGPU et examiner les informations de l’offre Mac présentée par MACGPU avant de vérifier l’adéquation à votre usage.
| Besoin | Preuve à obtenir | Évaluation du résultat | Suite si la preuve manque |
|---|---|---|---|
| Connexion distante | Codex App et un client SSH indépendant atteignent le même hôte avec l’identité prévue | Validé si les deux essais aboutissent sans relâcher les contrôles de sécurité | Reprendre l’authentification, le réseau ou le périmètre d’accès |
| Accès au dépôt | Le compte distant lit et écrit dans la copie attendue ; l’état du dépôt confirme les changements | Validé si la bonne branche et le bon chemin sont observés | Corriger la copie, le chemin ou les droits limités |
| Compilation Xcode | Les outils sélectionnés correspondent au projet et la commande cible produit le résultat attendu | Validé pour la compilation seulement | Corriger l’installation, la sélection Xcode ou l’erreur du projet |
| Test sur simulateur ou appareil | La destination réelle démarre et le test prévu s’exécute dans la session cible | Validé uniquement pour la destination testée | Vérifier le runtime, l’accès graphique ou l’appareil |
| Livraison signée | L’Archive est signée avec les éléments et les accès appropriés | Validé pour l’Archive signée, pas automatiquement pour l’envoi | Revoir la configuration de signature et les permissions |
| Envoi | App Store Connect reçoit le fichier et affiche le résultat du traitement | Validé après confirmation dans le service | Traiter l’envoi ou le traitement séparément de Xcode |
| Solution | Ce qu’elle permet de valider | Limite à examiner avant de choisir |
|---|---|---|
| Compilation locale sur Windows ou Linux | Le code et les tâches compatibles avec votre environnement local | Les outils macOS et Xcode ne sont pas remplacés par une connexion SSH |
| Mac déjà disponible dans l’équipe | Les tâches Xcode, avec contrôle direct des accès et des périphériques présents | Disponibilité de la machine, configuration partagée et maintenance à organiser |
| Mac distant accessible par SSH | Les commandes exécutées dans un environnement macOS, sous réserve d’un dépôt et d’outils correctement configurés | Une session SSH ne garantit ni simulateur utilisable, ni appareil physique, ni signature ni envoi |
| Mac loué pour un besoin temporaire | Un environnement distant à évaluer pour une campagne de compilation ou de test | Vérifiez les accès nécessaires, le mode de contrôle, la durée utile et les dépendances à votre matériel local |