Symptôme : le terminal se connecte au Mac distant, mais Codex n’affiche aucun hôte ou continue d’exécuter le projet localement. Solution la plus rapide : testez d’abord une connexion SSH ordinaire, puis configurez l’hôte SSH, rendez Codex disponible dans le Shell distant et validez l’emplacement du projet avant de demander une modification.

La documentation officielle de Remote connections dans Codex repose sur deux vérifications distinctes : l’hôte doit être découvrable depuis la configuration SSH, et l’environnement distant doit pouvoir exécuter les tâches demandées. Autrement dit, Codex Remote SSH permet bien d’utiliser un Mac distant comme environnement réel de projet, mais vous devez progresser dans cet ordre : SSH de base, découverte de l’hôte, Codex distant, dossier du projet, puis petite tâche réversible.

Dernière mise à jour : 7 septembre 2026. Les règles de connexion et les indications produit ont été vérifiées à partir de la documentation OpenAI Remote connections, des instructions officielles d’utilisation de Codex et de la documentation Apple sur Remote Login. Les intitulés d’interface peuvent évoluer.

À qui s’adresse ce tutoriel ?

Vous pouvez suivre ce guide si vous utilisez uniquement Windows, un ordinateur fourni par votre établissement ou un ancien Mac trop limité pour votre cours. Il convient aussi si vous avez déjà reçu les informations d’un Mac distant, mais que vous ne savez pas comment l’ajouter à Codex.

Si Codex affiche « connecté » alors que les fichiers et les commandes restent sur votre ordinateur, les étapes de vérification finale vous aideront à distinguer une connexion graphique d’un véritable changement d’environnement d’exécution.

Lire le problème comme un parcours de connexion

Un Mac distant n’est pas automatiquement prêt parce que son adresse IP, son identifiant et son mot de passe vous ont été transmis. Il faut distinguer quatre endroits qui sont souvent confondus :

  • votre ordinateur Windows, où vous lancez l’application ou le terminal ;
  • le fichier de configuration SSH, qui joue le rôle d’un carnet d’adresses ;
  • le Mac distant, qui doit accepter la connexion et retrouver les commandes nécessaires ;
  • le dossier du projet, qui détermine où Codex lit et modifie les fichiers.
Imaginez une salle de cours. SSH vous permet d’entrer dans le bâtiment. L’alias SSH correspond au numéro de la salle. Codex est l’assistant présent dans cette salle. Enfin, le dossier du projet est votre bureau. Si vous entrez dans le bâtiment mais restez assis à votre bureau local, la connexion semble réussie alors que le travail se déroule au mauvais endroit.

Le premier piège vient de la différence entre Remote Control et Remote SSH. Une fonction de contrôle à distance d’une session ne signifie pas nécessairement que Codex va découvrir et utiliser un hôte défini dans votre configuration SSH. Pour ce tutoriel, vous devez vous concentrer sur la méthode qui s’appuie sur SSH et sur le système de fichiers distant, comme l’explique la documentation officielle des connexions distantes.

Comparaison des couches à vérifier

<
CoucheCe que vous devez observerÉchec typiqueAction prudente
SSH localLe terminal ouvre une session sur le MacDélai dépassé, refus ou authentification rejetéeIdentifier le type exact d’erreur avant toute modification
Découverte CodexL’hôte apparaît dans la liste proposéeLe terminal fonctionne, mais la liste reste videVérifier l’alias et le fichier SSH réellement lu
Codex distantLa commande peut être trouvée dans le Shell distantSSH fonctionne, mais le service distant ne démarre pasContrôler l’installation officielle et le PATH
ProjetLe chemin et les fichiers appartiennent au MacLes modifications apparaissent dans le dossier localSélectionner explicitement le dossier via l’hôte distant

Première étape : réussir le SSH ordinaire

Avant d’ouvrir Codex, lancez un terminal indépendant sur l’ordinateur qui exécutera l’application. Testez la connexion SSH avec les informations fournies par l’administrateur du Mac distant ou par votre environnement de location. Le but n’est pas encore de lancer un projet : vous cherchez seulement à savoir si vous pouvez entrer dans la salle.

Le Mac distant doit avoir une fonction de connexion à distance autorisée. Apple décrit cette fonction sous le nom de Remote Login dans sa documentation officielle de macOS. L’activation, les comptes autorisés et les restrictions peuvent dépendre de la machine ; ne modifiez donc pas les réglages d’un ordinateur scolaire ou administré sans autorisation.

Observez précisément le résultat :

<
Résultat du testCe que cela signifie probablementVérification à effectuerQuand arrêter
Délai dépasséL’adresse ou le chemin réseau n’est pas joignableConfirmer l’adresse, le port fourni et l’accès réseau autoriséArrêtez si vous devez ouvrir des ports inconnus
Connexion refuséeLe service SSH n’écoute pas ou n’accepte pas votre accèsDemander si Remote Login est actif et si votre compte est autoriséN’installez pas de service réseau supplémentaire
Utilisateur refuséLe compte ou son format est incorrectReprendre le nom d’utilisateur indiqué pour ce MacN’essayez pas des comptes administrateur au hasard
Clé refuséeLa clé n’est pas celle attendue ou n’est pas chargéeVérifier le chemin de la clé et l’agent SSHNe désactivez pas la vérification d’empreinte
Session ouverteLa base réseau et l’authentification fonctionnentAfficher le dossier courant et quitter proprementPassez seulement ensuite à Codex
Une session SSH réussie ne prouve pas encore que Codex pourra travailler à distance. Elle prouve seulement que la porte d’entrée fonctionne. Cette séparation vous évite de perdre du temps à chercher un problème de modèle ou de projet alors que le Mac n’est même pas accessible.

Deuxième étape : donner à Codex un hôte qu’il peut découvrir

Codex ne peut pas deviner de manière fiable quelle machine utiliser à partir d’une simple adresse copiée dans une conversation. Il doit retrouver un hôte SSH déclaré dans la configuration utilisée par votre ordinateur. Cette déclaration donne généralement un alias lisible, une adresse, un compte et parfois une clé ou d’autres paramètres de connexion.

Vous pouvez considérer cet alias comme une plaque sur la porte : l’adresse indique le bâtiment, mais l’alias indique précisément la salle. Si le terminal se connecte uniquement grâce à des options saisies à la main, Codex peut ne rien afficher dans sa liste.

Contrôlez les éléments suivants sans transformer cette étape en cours complet sur SSH :

  • le nom de l’hôte est bien défini dans votre configuration SSH ;
  • l’adresse correspond au Mac distant reçu ;
  • le nom du compte est celui qui fonctionne lors du test manuel ;
  • la méthode d’authentification est disponible dans l’environnement qui lance Codex ;
  • l’alias utilisé par Codex est le même que celui testé dans le terminal.
<
SituationChoix recommandéRésultat attendu
Un alias SSH existe et le test manuel fonctionneUtiliser cet alias pour la découverte CodexLe Mac apparaît comme hôte sélectionnable
Seule une adresse a été copiée dans le terminalCréer ou demander une entrée SSH conforme aux instructions de votre administrateurCodex dispose d’un nom stable à rechercher
Plusieurs fichiers SSH sont présentsIdentifier celui lu par l’application, sans supposer qu’il s’agit du bonL’hôte est découvert dans le contexte réel
La liste reste vide malgré un test réussiRevenir à l’alias, au compte et à l’environnement de lancementVous évitez de modifier inutilement le Mac distant
Ne contournez pas cette vérification en désactivant les contrôles d’identité de l’hôte. Une première connexion peut demander de confirmer une empreinte ; cette empreinte doit être comparée avec une source de confiance, pas acceptée machinalement.

Troisième étape : rendre Codex disponible sur le Mac distant

Lorsque le SSH fonctionne et que l’hôte est visible, le problème suivant est souvent plus discret : vous êtes bien entré sur le Mac, mais le Shell distant ne trouve pas Codex. L’application de bureau peut utiliser SSH pour démarrer un service ou un processus distant ; elle ne transforme pas automatiquement votre ordinateur local en installation distante.

La distinction est importante :

  • Codex installé sur Windows concerne votre environnement local ;
  • Codex installé sur le Mac distant concerne les commandes exécutées dans la session distante ;
  • votre compte et votre autorisation doivent être valides dans le contexte demandé par la documentation officielle ;
  • le Shell ouvert par une connexion distante doit retrouver la commande dans son PATH.
Consultez les [instructions officielles d’utilisation de Codex](https://help.openai.com/en/articles/11369540) pour l’installation et les conditions de compte applicables au moment où vous configurez l’environnement. Les noms exacts des menus, les systèmes pris en charge et la procédure d’autorisation peuvent évoluer ; ne recopiez pas un chemin trouvé dans une ancienne capture d’écran.

Depuis la session SSH, vérifiez d’abord que vous êtes réellement sur le Mac distant, puis contrôlez si la commande attendue est accessible. Si elle fonctionne dans votre session interactive mais pas lorsque Codex ouvre un Shell non interactif, le problème peut venir du chargement différent des fichiers de configuration du Shell et du PATH.

La bonne démarche est limitée :

  1. confirmer l’identité de la machine distante ;
  2. vérifier le dossier courant ;
  3. vérifier que l’installation officielle de Codex est terminée sur cette machine ;
  4. vérifier que le compte utilisé par SSH peut retrouver la commande ;
  5. relancer la détection depuis Codex.
Arrêtez-vous si la procédure vous demande de modifier des répertoires système, d’exécuter un script téléchargé sans source vérifiable ou d’accorder des droits qui ne sont pas nécessaires à votre cours. Un environnement d’apprentissage n’a pas besoin de privilèges supplémentaires pour prouver qu’une connexion fonctionne.

Quatrième étape : sélectionner le bon projet distant

Un indicateur vert ou un hôte affiché ne suffit pas. Vous devez ouvrir le dossier du projet depuis l’hôte SSH sélectionné. C’est ce choix qui indique à Codex où lire les fichiers et où exécuter les commandes.

Commencez par un dossier de démonstration ne contenant ni mot de passe, ni clé privée, ni dépôt de cours confidentiel. Demandez ensuite une vérification descriptive : le chemin courant, la liste limitée des fichiers et l’identification générale du système. Évitez les commandes destructrices et ne donnez pas encore l’autorisation de supprimer ou de déplacer des fichiers.

<
VérificationExécution attendue sur le Mac distantIndice d’erreur locale
Chemin du projetLe chemin correspond au dossier choisi sur le MacLe chemin pointe vers un répertoire Windows ou local
Fichier témoinLe fichier apparaît dans le dossier distant après créationIl n’existe que dans votre explorateur local
Commande d’environnementLa réponse décrit le système ou le dossier du MacLa sortie correspond à votre ordinateur de départ
Modification mineureLe changement apparaît dans le projet distantVotre copie locale est la seule à changer
La [présentation OpenAI du travail avec Codex depuis n’importe où](https://openai.com/index/work-with-codex-from-anywhere/) décrit le principe général d’un travail réalisé dans un environnement distant. Pour votre premier essai, retenez surtout cette règle : le projet doit être ouvert depuis l’hôte SSH, et non depuis le dossier local portant le même nom.

Le test du fichier témoin

Créez un fichier sans donnée sensible dans le projet d’essai, par exemple un fichier texte destiné à être supprimé après la vérification. Demandez à Codex de vous indiquer son chemin exact, puis comparez ce chemin avec l’emplacement attendu sur le Mac distant. Vous pouvez ensuite fermer la connexion et vérifier, lors d’une nouvelle session, que le fichier est toujours présent au même endroit.

Cette étape répond à une question pratique que l’interface ne montre pas toujours clairement : le projet est-il réellement conservé sur le Mac distant, ou avez-vous simplement ouvert une copie locale ?

Cinquième étape : accepter une première tâche réversible

Pour votre première demande, choisissez un petit projet que vous pouvez jeter. Il peut s’agir d’un exercice Python, d’un dossier web ou d’un exemple macOS non confidentiel. Si votre cours utilise Xcode, commencez par la lecture de l’arborescence et une validation légère avant de demander une construction complète.

Demandez à Codex de suivre une séquence contrôlée :

  1. expliquer les principaux dossiers sans les modifier ;
  2. proposer une seule modification ciblée ;
  3. attendre votre validation ;
  4. appliquer cette modification ;
  5. afficher le changement ;
  6. exécuter la vérification fournie par le projet ;
  7. indiquer le chemin du projet et le résultat de la commande.
Contrôlez quatre critères avant d’utiliser votre dépôt de cours :
  • le bon projet est lisible depuis le Mac distant ;
  • la modification est limitée et réversible ;
  • la commande s’exécute sur le Mac, pas sur Windows ;
  • le fichier reste dans le dossier attendu après une reconnexion.
Ne commencez pas par une demande qui supprimerait des fichiers, téléverserait des identifiants, modifierait un répertoire système ou exécuterait une commande provenant d’une source inconnue. Les droits complets dont vous disposez éventuellement sur une machine distante ne rendent pas ces opérations adaptées à un premier test.

Codex Remote SSH et Xcode : où s’arrête la promesse ?

Un Mac distant peut servir d’environnement macOS pour lire un projet Xcode, exécuter certaines commandes et lancer des opérations de construction ou de test lorsque Xcode et les composants nécessaires sont disponibles. Apple décrit également des scénarios de construction d’un projet macOS depuis un autre ordinateur ainsi que l’automatisation des tests Xcode.

Cela ne signifie pas que chaque projet iOS fonctionnera automatiquement. Vous devez encore vérifier la présence de Xcode, les dépendances, les certificats, les simulateurs et, si nécessaire, l’accès à un appareil physique. Codex peut exécuter une tâche dans l’environnement distant ; il ne peut pas créer à votre place une licence, un certificat de signature ou une connexion matérielle absente.

Pour un étudiant, la décision est simple :

  • si le cours demande seulement Python, JavaScript ou Git, Windows peut suffire ;
  • si le cours demande une compilation, un simulateur ou une signature Apple, un Mac distant devient pertinent ;
  • si vous devez brancher régulièrement un iPhone ou un périphérique audio, vérifiez d’abord les limites de l’accès distant ;
  • si vous apprenez surtout l’interface macOS, une session distante peut être plus adaptée qu’une virtualisation instable.

Décider de continuer, de fonctionner en double environnement ou de changer de solution

Utilisez ces conditions après votre premier projet validé :

  • Si SSH ouvre une session, l’hôte est découvert, Codex est disponible et le projet reste sur le Mac après reconnexion, alors vous pouvez continuer avec ce parcours distant.
  • Si le projet macOS fonctionne mais que votre connexion est irrégulière, alors gardez Windows pour le code général et réservez le Mac distant aux compilations, tests et tâches Apple.
  • Si le projet ne peut pas être conservé au même emplacement ou si l’accès est interrompu pendant les tâches importantes, alors ne déplacez pas encore votre dépôt principal ; revenez à un environnement local ou à une autre solution contrôlée.
  • Si votre cours exige un appareil physique, un périphérique audio ou une présence locale permanente, alors vérifiez cette contrainte avant de choisir la location d’un Mac distant.
  • Si vous avez besoin d’un environnement macOS seulement pendant une période de cours, alors une solution temporaire peut être plus rationnelle qu’un achat immédiat.
Pour préparer votre poste Windows sans ouvrir d’accès inutile, vous pouvez consulter ce [guide de première connexion à un Mac depuis Windows](https://macgpu.com/fr/index.html). Si Codex fonctionne mais que vous hésitez encore sur les permissions, la conservation des fichiers et la validation du dépôt, reportez-vous aussi à cette [liste de contrôle pour les outils de programmation et les projets distants](https://macgpu.com/fr/m4-commander.html).

Questions fréquentes

Pourquoi Codex ne trouve-t-il pas l’hôte SSH ?

Un terminal peut se connecter grâce à une commande ou à des paramètres qui ne sont pas visibles par Codex. L’application cherche généralement un hôte défini dans la configuration SSH qu’elle peut lire. Vérifiez donc l’alias, l’adresse, le compte et la clé utilisés, puis comparez le contexte de lancement de Codex avec celui de votre terminal. Ne désactivez pas les contrôles d’identité pour forcer l’apparition de l’hôte.

Le Mac distant doit-il avoir Codex installé ?

Oui, lorsque la méthode utilisée doit démarrer Codex ou un service Codex sur la machine distante. L’installation locale ne se transmet pas automatiquement par SSH. Installez la version officielle sur le Mac distant, vérifiez l’autorisation du compte concerné et assurez-vous que le Shell non interactif retrouve la commande. Si vous ne contrôlez pas la machine, demandez à l’administrateur de confirmer ces éléments.

Codex est connecté, mais le projet s’exécute encore localement : que faire ?

Fermez le dossier local et ouvrez le projet depuis l’hôte SSH sélectionné. Créez un fichier témoin sans contenu sensible, affichez le chemin du projet et lancez une commande d’identification non destructive. Si le chemin correspond à Windows ou à votre ancien Mac, la session distante n’est pas celle qui porte le projet. Recommencez la sélection avant toute modification importante.

Codex Remote SSH peut-il lancer un projet Xcode ?

Il peut utiliser un Mac distant comme environnement macOS pour certaines commandes de projet, de construction et de test, si Xcode et les dépendances nécessaires sont installés. La signature, les certificats, le simulateur et l’accès à un iPhone restent des conditions séparées. Testez d’abord un exemple jetable et vérifiez la sortie de la commande sur le Mac distant avant d’ouvrir votre dépôt de cours.

Le choix entre votre configuration actuelle et un Mac distant dépend finalement de contraintes très concrètes. Windows reste souvent le choix le plus simple pour les exercices généraux, mais il ne fournit pas directement Xcode ni l’environnement macOS requis par certaines étapes Apple. Une machine locale ancienne peut manquer de stockage, de mises à jour ou de stabilité, tandis qu’une virtualisation mal configurée ajoute des problèmes de réseau et de performances. Si votre cours exige un Mac réel seulement pendant quelques jours ou pour des validations ciblées, louer un Mac avec MACGPU peut éviter ces engagements tout en vous laissant vérifier SSH, Codex et votre dépôt dans un environnement réel.

Après la validation du petit projet, comparez cette expérience avec les exigences de votre cours : durée d’utilisation, besoin de Xcode, conservation des fichiers et présence éventuelle d’un appareil physique. Si vous avez seulement besoin d’un environnement macOS temporaire, consultez les possibilités de Mac distant proposé par MACGPU, puis choisissez une formule uniquement après avoir confirmé que vos tâches sont compatibles avec un accès distant.