Symptôme : Codex CLI ne reprend pas les skills d’agent de Xcode, ou vous ne savez pas si leur import suffit pour compiler.
Solution rapide : exportez-les depuis le Xcode effectivement sélectionné, placez-les dans un emplacement reconnu par Codex, puis validez séparément la découverte, les permissions et un build réel.
Cette procédure s’adresse aux développeurs Swift et iOS qui utilisent Codex CLI, aux petites équipes qui configurent les accès d’un agent, et aux personnes qui doivent vérifier un projet sans disposer d’un Mac local. Elle ne migre pas tout votre flux Xcode vers Codex : elle transfère des instructions de travail, puis vérifie ce que l’environnement autorise réellement.
Dernière mise à jour : 10 octobre 2026. Versions et procédures vérifiées à partir des documents de publication et de personnalisation d’Apple ainsi que de la documentation officielle des skills de Codex.
SECTION 01Avant l’export : quel Xcode pilote réellement votre terminal ?
Avant de rechercher des skills ou de déplacer des fichiers, identifiez l’installation de Xcode qui fournit les outils utilisés dans votre session. Une machine peut contenir plusieurs installations, tandis que le terminal et l’interface graphique n’utilisent pas nécessairement la même. Si vous exportez depuis une autre copie que celle qui construit votre projet, vous risquez de tester un ensemble d’instructions qui ne correspond pas à votre environnement de travail.
À la date de vérification indiquée ci-dessus, la page officielle de publication d’Apple date la disponibilité de Xcode 27.1 RC du 5 octobre 2026. Cette référence décrit une publication à cette date ; elle ne signifie pas que cette version restera la plus récente. Consultez la page de publication d’Apple pour Xcode 27.1 RC et les notes de version de Xcode 27 avant de reprendre une indication propre à une préversion.
Dans le terminal que vous comptez utiliser avec Codex CLI, relevez la version et le répertoire des outils :
xcodebuild -version
xcode-select -p
Apple décrit le rôle des outils en ligne de commande et leur installation dans sa documentation sur les outils de ligne de commande et sa note technique consacrée aux outils Xcode en ligne de commande. Si le chemin renvoyé ne correspond pas à l’installation prévue, corrigez d’abord la sélection active selon la configuration de votre machine, puis répétez les contrôles. Ne déduisez pas l’installation active du seul nom visible dans le Dock.
Relevez également le contexte de démarrage de Codex CLI : terminal, compte utilisateur, dépôt ouvert et éventuel environnement isolé. Un skill placé dans le répertoire personnel n’est pas automatiquement disponible à une autre identité système. De même, un terminal distant et une session graphique ouverte sous un autre compte ne partagent pas nécessairement le même contexte de fichiers ou d’autorisations.
| Contrôle | Commande ou emplacement à vérifier | Ce que le résultat permet de conclure |
|---|---|---|
| Version de Xcode | xcodebuild -version |
La version annoncée par l’outil de build utilisé dans ce terminal |
| Sélection des outils | xcode-select -p |
Le répertoire développeur actif pour les commandes Xcode |
| Skill propre au dépôt | .agents/skills/ à la racine du projet |
Un emplacement de projet à comparer aux règles de découverte officielles de Codex |
| Résultat de compilation | Journaux et artefacts du projet | Si le build a effectivement abouti, indépendamment de la visibilité du skill |
SECTION 02Étape 1 : exporter les skills depuis l’environnement choisi
Apple documente l’extension des agents de Xcode et les skills dans son guide officiel de personnalisation des agents. Le but de l’export est de transmettre des instructions réutilisables ; il ne configure pas les droits de Codex sur votre dépôt et ne lui donne pas, à lui seul, la capacité de lancer une compilation.
Depuis l’environnement qui utilise la version voulue de Xcode, lancez la commande d’export documentée :
xcrun agent skills export
Avant de l’intégrer à une procédure d’équipe, vérifiez dans la documentation Apple actuelle la syntaxe exacte, les options disponibles et le comportement de votre installation. Ne recopiez pas une option de destination trouvée pour une autre préversion ou un autre contexte d’installation sans la confirmer. Si la commande affiche une erreur, notez d’abord le résultat de xcode-select -p, vérifiez la version de Xcode active et relisez l’aide ou les instructions associées à cette version.
Une commande qui se termine correctement établit seulement que l’étape d’export a produit le résultat indiqué par Xcode. Elle ne prouve pas que Codex a chargé ces fichiers. Conservez le chemin effectivement annoncé par l’outil, puis inspectez le contenu généré avant de le déplacer. Repérez notamment le fichier d’instructions du skill, habituellement nommé SKILL.md, ainsi que ses ressources éventuelles. Vérifiez que les fichiers sont lisibles et que leur arborescence n’a pas été aplatie ou modifiée par une copie partielle.
Ne confondez pas non plus les consignes d’un skill avec un projet Xcode complet. L’export ne transfère ni les sources, ni les réglages de signature, ni les certificats, ni les simulateurs, ni les secrets d’accès. Ces éléments restent liés à votre dépôt et à la configuration de la machine.
SECTION 03Étape 2 : installer le skill à un emplacement reconnu par Codex
Codex applique ses propres règles de découverte. La documentation officielle décrit les skills et leur organisation dans le guide consacré aux concepts des skills ; les explications sur leur structure et leur découverte sont également précisées dans la présentation technique de l’évaluation des skills. Vérifiez ces références au moment de l’installation, car un chemin donné pour un autre outil ou une ancienne configuration n’est pas une preuve que votre version de Codex le lit.
Pour un besoin limité à un dépôt, placez le skill sous le répertoire de skills du projet, par exemple :
<racine-du-projet>/
└── .agents/
└── skills/
└── <nom-du-skill>/
├── SKILL.md
└── <ressources éventuelles>
Pour un usage partagé entre plusieurs projets, comparez cette option avec les emplacements utilisateur indiqués par la documentation actuelle de Codex. Choisissez le niveau le plus restreint qui répond au besoin : le dépôt facilite la revue et la reproduction par l’équipe ; l’installation utilisateur évite de répéter la copie, mais elle dépend du compte et de l’environnement où Codex démarre.
Après le déplacement, comparez le fichier installé avec celui exporté. Confirmez que le nom du dossier, SKILL.md et les références à d’autres fichiers correspondent à la structure attendue. Si le skill pointe vers une ressource relative qui n’a pas été copiée, Codex peut découvrir son nom sans disposer des instructions complètes.
Fermez puis relancez la session ou appliquez la procédure de rechargement documentée pour votre version de Codex. Il ne faut pas supposer qu’une session déjà ouverte relira automatiquement un dossier modifié. Si vous installez un skill au niveau du dépôt, vérifiez aussi que vous avez lancé Codex depuis le bon projet et non depuis un répertoire parent ou un dépôt voisin.
SECTION 04Étape 3 : vérifier séparément découverte, autorisations et contexte
Commencez par une demande de contrôle sans modification du dépôt. Par exemple :
Inspectez les skills disponibles pour ce dépôt. Indiquez le nom du skill
Xcode que vous utiliseriez pour examiner un problème de compilation,
résumez les consignes pertinentes et ne modifiez aucun fichier.
Ce test vérifie si Codex peut repérer le skill et rendre compte de son contenu. Il ne teste pas la compilation. Si le skill n’est pas mentionné, contrôlez d’abord le chemin, le compte système, la racine du projet et le rechargement de la session. Si le skill est trouvé mais pas retenu pour une tâche, examinez les instructions et la manière dont vous formulez la demande : un fichier visible n’entraîne pas nécessairement son activation pour toutes les requêtes.
Traitez ensuite trois permissions distinctes :
- Accès au projet : Codex doit pouvoir lire les fichiers pertinents ; une restriction de lecture empêche l’analyse même si le skill est chargé.
- Exécution des commandes : l’autorisation de lancer des outils se règle séparément. Accordez uniquement ce qui est nécessaire au test, plutôt que d’ouvrir un accès général au shell.
- Accès à Xcode : la présence d’un skill ne garantit ni la disponibilité de
xcodebuild, ni la sélection des bons outils, ni l’accès aux ressources requises par le projet.
Les changements de permission doivent suivre la politique de votre équipe et l’interface ou la configuration réellement utilisée par votre version de Codex. N’ajoutez pas des privilèges élevés comme remède à une erreur de découverte : un dossier au mauvais endroit ne devient pas correct parce que l’agent reçoit plus de droits.
SECTION 05Ce que les premiers contrôles doivent vous apprendre
Si Codex connaît le nom du skill mais ne l’utilise pas, séparez le diagnostic en petites vérifications. Confirmez d’abord que le fichier est au bon emplacement et que le contenu est lisible. Demandez ensuite explicitement un résumé du skill sans action sur le dépôt. Enfin, comparez la tâche réelle à la portée décrite dans le fichier. Cette séquence distingue une règle de découverte défaillante d’une consigne hors sujet ou d’une demande ambiguë.
Si le skill semble chargé, mais que Codex ne lit pas les fichiers du projet, examinez la session et les autorisations d’accès. Si les fichiers sont lisibles mais qu’une commande Xcode échoue, relevez séparément la commande, son code de sortie et son message d’erreur. L’import ne répare ni une sélection de développeur incorrecte ni un outil absent.
Dans un projet créatif, la différence est particulièrement visible : un skill peut orienter l’analyse d’une application qui génère des aperçus audio, des rendus vidéo ou des écrans de design, sans garantir que les ressources médias soient présentes ni que le simulateur puisse les lire. Vérifiez les chemins d’assets, les réglages du schéma et les dépendances du projet avant de conclure que l’agent a mal suivi le skill.
SECTION 06FAQ : les cas qui bloquent après l’installation
Le skill est visible, mais Codex ne le choisit pas : que vérifier ?
Contrôlez le nom et les consignes du skill, le répertoire depuis lequel Codex a été lancé et le rechargement de la session. Pour isoler le problème, demandez une lecture explicite des instructions sans autoriser de modification. Si Codex sait résumer le fichier mais ne le sélectionne pas pour une tâche, précisez dans votre demande le rôle attendu du skill et vérifiez que cette tâche entre bien dans son périmètre.
Un skill importé peut-il compiler sans réglage supplémentaire ?
Non. La découverte d’instructions ne configure pas l’accès aux sources, l’exécution des commandes ou la chaîne Xcode. Vérifiez séparément ces autorisations, le chemin des outils et la disponibilité des dépendances. Vous devez ensuite lancer une commande de build adaptée à votre projet et inspecter son résultat. Une réponse qui affirme qu’un build devrait fonctionner n’est pas une preuve de compilation.
SECTION 07Étape 4 : valider le projet avant de confier une tâche réelle
Une fois la découverte et les permissions contrôlées, testez le flux sur une branche réversible ou un projet de test. Commencez par demander à Codex d’expliquer les étapes qu’il compte suivre, puis relisez les commandes prévues avant de l’autoriser à les exécuter. Pour une tâche de maintenance, demandez une modification limitée et inspectable plutôt qu’une opération de signature ou de publication dès le premier essai.
Lancez ensuite la commande de compilation pertinente pour le schéma et la destination choisis. La syntaxe exacte dépend du projet ; ne substituez pas une commande générique à sa configuration réelle. Contrôlez dans les journaux le schéma sélectionné, la destination, les éventuels avertissements bloquants et le code de sortie. Vérifiez aussi l’artefact attendu : un journal partiel, une compilation interrompue ou une archive absente ne constitue pas une validation réussie.
Pour décider si le transfert est terminé, cochez chaque contrôle séparément :
- [ ] Le terminal utilise la version et le répertoire développeur de Xcode prévus.
- [ ] L’export a affiché un résultat et un emplacement que vous avez conservés.
- [ ] Le dossier du skill installé contient
SKILL.mdet les ressources nécessaires. - [ ] Codex a été relancé ou rechargé conformément à sa procédure de découverte.
- [ ] Un test sans modification confirme que le skill est lisible et pertinent.
- [ ] L’accès au dépôt et l’autorisation d’exécuter les commandes sont vérifiés séparément.
- [ ] Un build du projet de test ou de la branche réversible a produit les artefacts attendus.
- [ ] Les journaux et le résultat de compilation ont été examinés indépendamment de la réponse de l’agent.
Si vous ne cochez pas les contrôles de permission et de build, ne concluez pas que l’intégration est opérationnelle. Le skill peut être correctement importé tandis que l’environnement reste incapable de compiler.
SECTION 08Choisir le bon environnement pour l’export et le build
Un Mac local est pertinent si vous avez déjà Xcode installé, si vous devez manipuler des périphériques ou des ressources locales, et si vous souhaitez maîtriser directement les sessions et les secrets. En contrepartie, vous devez gérer vous-même l’espace disque, les mises à jour de Xcode, la disponibilité de la machine et l’isolation des tâches de compilation. Un poste de travail partagé peut aussi rendre moins reproductible le contexte dans lequel Codex démarre.
Un Mac distant devient une option à évaluer si vous n’avez pas de machine macOS disponible, si votre poste principal manque d’espace ou si vous avez besoin d’un environnement accessible pour une validation ponctuelle. Il faut néanmoins vérifier avant de migrer le dépôt que l’environnement fourni correspond aux exigences de votre projet et que le mode d’accès vous permet d’utiliser les outils nécessaires. Un service distant ne remplace pas la gestion prudente des identifiants ni la vérification des résultats du build.
Vous pouvez comparer les conditions et les modalités d’accès avant de décider sur la page des offres de MACNOX. Si un environnement distant convient à votre cas, examinez les informations de commande disponibles sur la page de location de Mac. Ces pages ne changent pas les contrôles techniques de ce guide : vous devrez toujours vérifier la sélection de Xcode, l’accès aux fichiers, les autorisations de Codex et les artefacts obtenus.
Pour un test isolé d’import, une nouvelle machine distante peut être superflue : un Mac déjà configuré peut suffire. À l’inverse, si vous devez effectuer régulièrement des builds, valider des changements d’outillage ou travailler depuis un poste sans macOS, un environnement Mac accessible à distance peut éviter de dépendre du matériel personnel d’un développeur. Il n’est pas forcément adapté à un projet qui exige des périphériques physiques locaux ou un environnement durablement disponible sous contrôle exclusif.
En pratique, traitez l’import comme une étape de configuration, pas comme un certificat de bon fonctionnement : exportez depuis le Xcode réellement utilisé, installez le skill selon les règles de découverte actuelles de Codex CLI, puis validez séparément les permissions et la compilation. Si vous n’avez pas de Mac local pour réaliser ces contrôles, évaluez un Mac distant pour l’export et la vérification du projet ; si vous avez seulement besoin d’un test ponctuel déjà couvert par votre poste, inutile d’ajouter une machine à votre flux.