Codex CLI sur Mac distant : sécurité multi-dépôts, liste 2026

La documentation officielle de Codex décrit trois niveaux de bac à sable pour l’exécution des commandes, avec des règles distinctes pour les fichiers et le réseau dans la documentation OpenAI sur le bac à sable. Cela suffit à établir le point de départ : la sécurité de Codex CLI sur Mac distant pour plusieurs dépôts ne se déduit pas du lancement réussi de l’outil. Ne l’exécutez donc pas dans un compte partagé doté de privilèges élevés. Cette semaine, testez un compte système indépendant, un espace de travail par dépôt, des secrets temporaires et cinq familles de contrôles avant toute mise en ligne ; si une frontière ne peut pas être prouvée, revenez à un nœud temporaire limité à un seul dépôt.

Cette procédure s’adresse aux développeurs qui veulent laisser Codex CLI modifier, compiler ou tester plusieurs dépôts sur un Mac distant sans perdre la maîtrise des fichiers voisins. Elle concerne également les ingénieurs DevOps responsables d’un nœud en fonctionnement continu, ainsi que les responsables sécurité ou plateforme qui doivent examiner l’accès aux sources, au réseau, au trousseau macOS, aux identités de signature et aux outils Xcode.

Le bon choix dépend d’abord de la preuve d’isolement

Un Mac distant partagé peut convenir à une phase d’essai, mais il ne doit pas être traité comme une frontière de sécurité par défaut. Trois difficultés se cumulent dans ce scénario.

D’abord, le répertoire de travail n’est pas nécessairement la seule zone utile à un agent. Les fichiers de configuration, les répertoires parents, les métadonnées Git, les caches, les dossiers temporaires et les liens symboliques peuvent modifier ce que la commande peut lire ou écrire.

Ensuite, l’accès au réseau est une question distincte de l’accès aux fichiers. Une tâche peut nécessiter de télécharger une dépendance, de contacter un dépôt Git, d’appeler une API ou de lancer un outil externe. Autoriser une opération ne signifie pas que toutes les autres doivent être ouvertes.

Enfin, le compte macOS peut déjà posséder des privilèges que le bac à sable Codex ne neutralise pas automatiquement. Une clé proposée par SSH_AUTH_SOCK, une autorisation du trousseau, une identité Xcode ou une variable d’environnement peuvent transformer une tâche de modification de code en opération de publication.

Le critère de décision est donc mesurable :

• Choisissez une mise en ligne contrôlée si le compte, les fichiers, le réseau, les secrets et la reprise après incident ont tous une preuve conservée.
• Choisissez un usage limité si le code peut être traité sur un nœud dédié, mais que la signature, le trousseau ou les outils externes restent insuffisamment bornés.
• Revenez à un nœud temporaire à un seul dépôt si vous ne pouvez pas démontrer que les dépôts voisins sont illisibles et non modifiables.
• Reconstruisez le nœud si une interruption laisse des processus, des secrets, des différences ou des autorisations que vous ne pouvez pas expliquer.

Ne confondez pas non plus « bac à sable local » et « isolement d’un agent macOS ». L’isolement d’un agent macOS doit inclure le compte système, les permissions du système de fichiers, les mécanismes de session distante et les outils appelés par l’agent. Une consigne telle que « ne touchez pas au dépôt voisin » reste une intention, pas un contrôle technique.

Première mesure : bornes des fichiers et des dépôts

L’objectif de cette mesure est de répondre à une question précise : Codex CLI peut-il lire ou modifier autre chose que le dépôt attribué à la tâche ?

Objet à vérifier

Préparez un dépôt de test sans secret et deux répertoires voisins portant des marqueurs distincts. Ajoutez également un fichier de configuration de projet, un répertoire Git, un fichier temporaire et, si votre chaîne en utilise, un lien symbolique contrôlé. Ne placez aucune clé privée, aucun certificat de production ni aucun jeton réel dans ce dispositif.

Vérifiez ensuite :

• le répertoire de travail transmis à Codex CLI ;
• les droits de lecture et d’écriture du compte macOS ;
• les répertoires parents et les emplacements temporaires ;
• les fichiers .git, les sous-modules et les liens symboliques ;
• les caches de compilation et les données dérivées ;
• les chemins utilisés par les scripts du dépôt.

Les paramètres de configuration et les champs liés aux permissions doivent être vérifiés dans le code de configuration officiel de Codex, car une clé ou une valeur peut évoluer avec la version installée. Ne copiez pas une configuration trouvée dans un ancien billet sans la confronter à la documentation et au code actuels.

Méthode de test

Commencez par une session en lecture seule. Demandez une inspection du dépôt attribué, puis tentez volontairement une lecture du marqueur voisin avec un chemin absolu et un chemin relatif. Faites ensuite le même test avec une écriture inoffensive dans un fichier témoin.

Répétez l’essai dans un espace de travail autorisé en écriture, puis après création d’un sous-répertoire. Terminez par une rotation de dépôt : arrêtez la première tâche, changez de dépôt et vérifiez que l’ancien répertoire ne reste pas la racine effective de la nouvelle session.

Conservez la commande, le compte utilisé, le chemin courant, le résultat et la différence Git. Un simple message de refus n’est pas suffisant si vous ne savez pas quelle couche l’a produit.

Conditions d’acceptation et d’arrêt

Le contrôle est acceptable si le dépôt voisin reste illisible et non modifiable, si les chemins temporaires sont connus, si les liens symboliques ne permettent pas de sortir de la zone autorisée et si le nettoyage ne laisse pas de changement inexpliqué.

Arrêtez immédiatement l’essai si Codex CLI lit un marqueur voisin, modifie un dépôt non attribué, suit un lien vers une zone sensible ou conserve des fichiers d’une tâche précédente. Ne tentez pas de corriger ce résultat avec une instruction plus précise. Réduisez les droits du compte, recréez l’espace de travail et répétez le test.

Rappel de méthode : un compte qui peut écrire dans tous les dépôts du Mac annule la valeur d’une restriction déclarée uniquement dans le prompt. La séparation doit être vérifiable depuis le système, pas seulement depuis l’interface de l’agent.

Deuxième mesure : réseau, outils externes et MCP

Un réseau « autorisé » ou « refusé » ne décrit pas assez le risque. Séparez au minimum la communication nécessaire au modèle, le téléchargement des dépendances, les opérations Git, les appels d’API et l’exécution d’outils externes.

La documentation officielle sur les permissions explique les rapports entre approbation, exécution et niveau d’accès dans la référence OpenAI consacrée aux permissions. De son côté, la documentation réseau du dépôt Codex décrit les modalités de contrôle des requêtes dans cette note officielle sur le réseau. Utilisez ces références pour vérifier les noms et comportements correspondant à votre version, plutôt que de déduire le comportement d’un ancien fichier de configuration.

Ce qu’il faut observer

Effectuez une première tâche avec le réseau refusé par défaut. Vérifiez que la dépendance manquante, l’appel d’API et l’opération Git distante échouent de manière identifiable. Activez ensuite uniquement l’autorisation nécessaire et confirmez que la demande est visible dans les journaux ou dans le mécanisme d’approbation prévu.

Testez séparément :

• une résolution ou connexion vers une destination autorisée ;
• une destination différente ou inattendue ;
• un téléchargement lancé par un script du dépôt ;
• une commande Git qui pousse ou récupère des données ;
• un outil externe appelé par le projet ;
• un serveur MCP ou un exécuteur qui transmet une commande à un autre processus.

L’outil externe est une frontière importante. Un agent peut être limité dans son propre bac à sable, tandis qu’un exécuteur privilégié reçoit ensuite un chemin, une commande ou un jeton sans appliquer les mêmes restrictions. Examinez le compte de l’exécuteur, son répertoire courant, ses variables d’environnement et les droits du processus enfant.

Ne transformez pas un rapport communautaire en vulnérabilité générale. L’issue GitHub consacrée à un cas de permissions et d’intégration doit être considérée comme une piste à reproduire dans votre environnement, non comme une preuve que tous les nœuds sont affectés.

Décision

Si les requêtes inattendues sont refusées, si chaque exception demande une approbation identifiable et si MCP ou les outils externes héritent de limites équivalentes, vous pouvez poursuivre la validation.

Si le réseau est ouvert globalement, si l’approbation est supprimée sans journal exploitable ou si un outil externe contourne le compte et le bac à sable, limitez l’agent à la revue locale. Pour un besoin de téléchargement ou de publication, utilisez un processus séparé avec des droits temporaires et une liste de destinations connue.

Troisième mesure : comptes, SSH, trousseau et signature

Le prochain contrôle doit établir ce que Codex CLI peut réellement utiliser, et non ce que vous pensez avoir rendu disponible.

Créez un compte macOS indépendant pour l’agent. Vérifiez son groupe, son dossier personnel, ses droits sur les dépôts et la capacité à ouvrir une session SSH. Évitez un compte administrateur partagé avec une session graphique personnelle. Si le nœud appartient à plusieurs utilisateurs, consignez aussi les services qui tournent sous d’autres comptes.

Réalisez trois essais avec des dépôts factices :

1. une session sans clé, sans jeton et sans identité de signature ;
2. une session avec une capacité de lecture seule vers une ressource de test ;
3. une session avec un secret temporaire, révocable après le test.

Dans chaque cas, observez les variables d’environnement, SSH_AUTH_SOCK, les agents SSH, les fichiers de configuration, les trousseaux accessibles et les processus enfants. Pour le trousseau, Apple explique que l’accès aux éléments dépend des autorisations et des demandes d’accès de l’application dans le guide Keychain Access. Une commande qui s’exécute sous le même compte ne doit donc pas être considérée comme isolée simplement parce qu’elle est lancée depuis Codex CLI.

Pour Xcode, séparez la compilation, les tests, la signature et l’envoi. Un projet peut compiler sans posséder l’identité permettant de signer une application. Une tâche d’agent doit pouvoir être autorisée à modifier et construire sans recevoir automatiquement une clé privée de production.

Le seuil d’arrêt est clair : ne transmettez jamais une clé de signature de production à la session par défaut. Si le test révèle une identité inattendue, un trousseau trop ouvert ou un agent SSH réutilisable par plusieurs tâches, révoquez le secret de test, nettoyez le compte et réduisez le périmètre. Une exécution réussie ne prouve pas qu’elle était correctement cloisonnée.

Quatrième mesure : exécution Xcode et concurrence entre dépôts

La présence de Xcode ajoute des chemins, des caches et des processus qui ne sont pas visibles dans un simple test de fichier. Utilisez un projet de démonstration avec une cible de test et une signature non productive. Lancez une compilation avec xcodebuild, un test, un script de projet et une génération de données dérivées, en remplaçant toute valeur sensible par <CHEMIN_TEST>, <COMPTE_TEST>, <TEAM_ID_TEST> ou <JETON_TEMPORAIRE>.

Vérifiez que :

• le projet utilise le répertoire de travail prévu ;
• les données dérivées ne sont pas partagées avec un autre dépôt ;
• le simulateur et les scripts n’exposent pas de fichiers voisins ;
• les journaux ne contiennent pas de secret ;
• une tâche interrompue ne conserve pas un processus Xcode ou un script enfant ;
• une seconde tâche ne réutilise pas le port, le cache ou le répertoire de la première.

Le fait que Codex CLI puisse exécuter une commande ne prouve pas que la chaîne est reproductible. La reproductibilité exige des versions documentées, un environnement propre, des entrées connues et une sortie comparable. Pour les projets audio, vidéo ou design qui génèrent des ressources volumineuses, contrôlez particulièrement les dossiers temporaires et les caches partagés : ils peuvent contenir des éléments d’un projet précédent sans apparaître dans la différence Git.

Pour une exécution parallèle, utilisez des répertoires de travail distincts et des identifiants de tâche distincts. Commencez par deux tâches non sensibles, puis augmentez seulement après avoir comparé les journaux, les ports, les fichiers créés et les processus. Les limites de capacité et les résultats de concurrence doivent être mesurés sur votre propre nœud et à votre propre date ; aucune conclusion de performance ne doit être généralisée sans mesure documentée.

Cinquième mesure : nettoyage, interruption et reprise

Un nœud distant doit être évalué après un échec, pas seulement après une tâche terminée correctement. Préparez une capture de référence contenant le compte, les processus attendus, l’espace de travail vide, les variables autorisées et les journaux disponibles.

Exécutez ensuite plusieurs scénarios :

• fermeture normale de Codex CLI ;
• interruption pendant une modification ;
• déconnexion SSH pendant une commande ;
• arrêt d’un script enfant ;
• changement de dépôt après une tâche incomplète ;
• redémarrage du Mac ;
• reprise d’une tâche après reconnexion.

Après chaque scénario, recherchez les processus persistants, les fichiers temporaires, les différences Git, les sockets, les journaux, les jetons en clair et les données dérivées. Vérifiez aussi que le service de démarrage ne relance pas automatiquement une tâche avec un ancien chemin ou une ancienne variable.

Un résultat acceptable signifie que l’état résiduel est prévisible, documenté et supprimable. Si le nœud revient dans un état différent sans explication, ne le réutilisez pas pour un autre dépôt sensible. La reconstruction complète du répertoire de travail ou du nœud est souvent plus sûre qu’un nettoyage manuel partiel.

Liste de décision à cocher avant la mise en ligne

Utilisez cette liste après les essais, en conservant pour chaque case le journal ou la capture qui prouve le résultat.

Compte et fichiers

• [ ] Le processus Codex CLI utilise un compte système indépendant et non administrateur.
• [ ] Le dépôt attribué possède un espace de travail dédié.
• [ ] Les dépôts voisins restent illisibles et non modifiables.
• [ ] Les répertoires parents, les fichiers temporaires, les sous-modules et les liens symboliques ont été testés.
• [ ] Les différences Git après exécution sont attendues et expliquées.

Si toutes les cases sont cochées, passez à la validation réseau. Sinon, revenez à un nœud temporaire limité à un seul dépôt.

Réseau et outils

• [ ] Le réseau est refusé par défaut lorsque la tâche ne le nécessite pas.
• [ ] Chaque exception est identifiable par une demande d’approbation ou un journal.
• [ ] Les destinations Git, les téléchargements et les API ont été testés séparément.
• [ ] MCP et chaque exécuteur externe utilisent des droits au moins aussi restrictifs que Codex CLI.
• [ ] Une destination inattendue est refusée.

Si toutes les cases sont cochées, passez aux secrets. Sinon, autorisez uniquement la revue locale et reconstruisez le chemin d’exécution externe.

Secrets et Xcode

• [ ] Aucun secret de production n’est présent dans la session standard.
• [ ] SSH_AUTH_SOCK, les variables d’environnement et les fichiers de configuration ont été inspectés.
• [ ] Le trousseau accessible au compte a été vérifié avec un secret de test.
• [ ] La compilation, les tests et la signature sont séparés.
• [ ] Les identités Xcode et les certificats non nécessaires sont absents.

Si toutes les cases sont cochées, testez la concurrence et le redémarrage. Sinon, limitez l’agent à des dépôts non sensibles et révoquez les secrets utilisés pendant l’essai.

Nettoyage et reprise

• [ ] Une fermeture normale ne laisse aucun processus enfant inexpliqué.
• [ ] Une rupture SSH ne laisse pas de tâche active hors contrôle.
• [ ] Un changement de dépôt ne réutilise pas l’ancien répertoire ou ses caches.
• [ ] Un redémarrage restaure un état connu et ne relance pas une ancienne tâche.
• [ ] Les journaux, différences, permissions et résultats de reprise sont archivés.

Si toutes les cases sont cochées, choisissez une mise en ligne progressive avec des dépôts non productifs. Sinon, choisissez un nœud par dépôt, une rotation avec réinitialisation complète ou la reconstruction du poste. Ne classez pas le système comme « sûr » sur la seule base d’une tâche réussie.

La décision de cette semaine

Utilisez cette arborescence avant d’accorder un accès réel :

• Si le compte est indépendant, les dépôts voisins sont inaccessibles, le réseau est refusé par défaut et les secrets sont temporaires, alors choisissez un pilote contrôlé.
• Si les fichiers sont isolés mais que la signature, le trousseau ou MCP ne sont pas séparés, alors limitez Codex CLI à la revue, à la modification non signée ou à la compilation sans publication.
• Si les tests réussissent sur un dépôt mais échouent lors du changement de dépôt, alors utilisez un nœud par dépôt ou une rotation avec réinitialisation complète.
• Si une clé, une identité Xcode, un fichier voisin ou un processus persistant apparaît sans explication, alors révoquez les secrets, arrêtez le nœud et reconstruisez-le.
• Si la reprise après redémarrage est reproductible et que les six familles de preuves sont conservées, alors vous pouvez envisager une mise en ligne progressive, d’abord avec des dépôts non productifs.

Pour documenter le poste, vous pouvez compléter cette validation avec un guide de configuration d’un Mac distant et une procédure de location d’un Mac distant pour un environnement de test. Ces ressources ne remplacent pas les essais : elles servent à choisir un nœud dont le cycle de création, d’accès et de récupération peut être répété.

Un poste Windows ou Linux local reste intéressant pour les outils multiplateformes, mais il ne fournit pas directement Xcode, le simulateur iOS ni les mécanismes de signature macOS. Une machine Mac partagée déjà utilisée par plusieurs équipes ajoute, elle, des comptes, caches, clés et processus difficiles à attribuer ; une machine virtuelle non maîtrisée peut enfin compliquer l’accès aux composants Apple et la reprise après incident. Pour une phase courte d’isolement, louer un Mac auprès de VMSPIN peut donc offrir un environnement réel, réinitialisable et plus simple à affecter à un compte ou à un dépôt précis. En revanche, si vous avez besoin d’une charge lourde permanente, d’un matériel local ou d’un périphérique physique, l’achat et l’administration d’un Mac dédié resteront plus cohérents. Dans tous les cas, commencez par un dépôt sans données de production et répétez la validation avant de confier plusieurs dépôts à Codex CLI.